Re: binfmt_script and ^M

[Erik Hensema]

On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> On 5 Mar 2001, Jan Nieuwenhuizen wrote:

> > Pavel Machek <pavel@suse.cz> writes:

> > > > $ head -1 testscript
> > > > #!/bin/sh
> > > > $ ./testscript bash: ./testscript: No such file or directory

> > > What kernel wants to say is "/usr/bin/perl\r: no such
> > > file". Saying ENOEXEC would be even more confusing.

> > So, why don't we make bash say that, then?  As I guess that we've
> > all been bitten by this before.

> > What are the chances for something like this to be included?

> > Greetings, Jan.

> [SNIPPED...]

> So why would you even consider breaking bash as a work-around for a
> broken script?

Userfriendlyness.

> Somebody must have missed the boat entirely. Unix does not, never
> has, and never will end a text line with '\r'. It's Microsoft junk
> that does that, a throwback to CP/M, a throwback to MDS/200.

Yes, _we_ all know that. However, it's not really intuitive to the user
getting a 'No such file or directory' on a script he just created. Bash
doesn't say:
bash: testscript: Script interpreter not found
but bash says:
bash: testscript: No such file or directory

Maybe we should create a new errno: EINTERPRETER or something like that and
let the kernel return that instead of ENOENT.

Note that this has little to do with the \r\n problem but only with the
_real_ underlying reason: the script interpreter is not found and ENOENT is
returned confusing the user: the user thinks the _script_ is not found,
while its there, for sure.
-- 
Erik Hensema (erik@hensema.xs4all.nl)