Messages in this thread | | | Date | Mon, 05 Mar 2001 19:54:08 +0000 | From | Paul Flinders <> | Subject | Re: binfmt_script and ^M |
| |
Andreas Schwab wrote:
> This [isspace('\r') == 1] has no significance here. The right thing to
> look at is $IFS, which does not contain \r by default. The shell only splits
> words by "IFS whitespace", and the kernel should be consistent with it: > > $ echo -e 'ls foo\r' | sh > ls: foo: No such file or directory
The problem with that argument is that #!<interpreter> can be applied to more than just shells which understand $IFS, so which environment variable does the kernel pick?
It's a difficult one - logically white space should terminate the interpreter name but the definition of what is, or isn't, white space is quite definately a user space issue. Unfortunately if you do use the user's locale to decide you then open the possibility that whether a scipt works or not depends on the locale - and that, surely, is equally unacceptable and deferring to a user-space "script launcher" app is going to open yet more problems.
In the end I suspect that the only practical way out _is_ to say that the kernel uses space (0x20) and tab (0x8) as white space and no other character.
This does miss the point though - whatever the rules are used to parse the interpreter name it is still confusing when the error reported by the shell is "No such file or directory". Especially when the file is sitting in front of you. Would it be so bad to add an ENOINTERP error?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |