[EMAIL PROTECTED] wrote:
> I've found that if bash scripts (or python and probably many more) use the
> magic shebang trick as in the following example:
> #!/usr/bin/env sh
I believe the above is just an example? Surely for sh it would be
#!/bin/sh, right? You only need the #!/usr/bin/env when invoking
things which might move around such as ruby, perl, python, etc.
> and the file is written in DOS format with CR/LF endings such is as very
> common with bash scripts under Cygwin or Python scripts that originated
> from the DOS world they don't work under the *nix world. It appears that
> the CR becomes part of the name for the interpreter to use as evidenced by
> this output from the attached script:
> $ ./test 2>&1 | od -c
> 0000000 / u s r / b i n / e n v : s h
> 0000020 \r : N o s u c h f i l e
^^ I see it here.
> 0000040 o r d i r e c t o r y \n
> While I certainly would not claim this is a bug, it does seem like it
> could be handled gracefully.
Well, but you are doing something bad. You are trying to encode one
operating systems convention upon another operating system. You are
trying to tell the kernel that you want CRs to be ignored. But under
UN*X like operating systems the end of line convention is a simple
newline and not a CR-NL combination.
Thanks for the report. But really that is not a bug. And even if it
were desireable to change this behavior it would be controlled by the
kernel. Nothing an application program can do about it. The kernel
is what is executing that line not the shell and not the interpreter
on the #! line. The interpreter on the line is reporting about the
parameter it was handed when the kernel parsed the line. The kernel
believes the line ends with a simple newline and any characters before
that are part of the argument to the interpreter.
Just about your only workaround would be to symlink the interpreter
you want to run to the same name with a CR at the end.
ln -s sh "sh$(printf "\r")"
I can't believe I just suggested that! Don't do it! It is too ugly
Bug-sh-utils mailing list