From: Eric Blake <eblake@redhat.com>
To: cygwin@cygwin.com
Subject: Re: cygwin-bash compat/regression bug... startup line prob
Date: Thu, 01 May 2014 06:41:00 -0000 [thread overview]
Message-ID: <5361ECA1.1040302@redhat.com> (raw)
In-Reply-To: <5361E22D.40408@tlinx.org>
[-- Attachment #1: Type: text/plain, Size: 4267 bytes --]
On 04/30/2014 11:57 PM, Linda Walsh wrote:
> Eric Blake wrote:
>> On 04/28/2014 02:43 PM, Linda Walsh wrote:
>>
>> >> cat bin/t.sh
>> > #!/bin/bash -u
> Um... it doesn't work with 1 argument either.
Your context quoting is hard to follow. Here, you are complaining about
a she-bang with only one argument,...
>>
>> This is an invalid shebang line. Historically, you are allowed at most
>> ONE argument to the program that you will be executing.
> ?!? Historically?.. since when? Never encountered that problem on linux
> nor on cygwin. This isn't a case of 2 args, just the "-u" by itself
> doesn't work.
...but here, you are quoting my reply to your original example that
included two arguments, although you managed to snip that original text
[for reference, my comment was about _this_ portion of your mail:
| > cat bin/t.sh
| #!/bin/bash -u -x
which is indeed invalid usage]. I made no comment confirming or denying
whether your use of '-u' by itself works (as I was not on cygwin when I
wrote my first reply, and so had no easy way to confirm or refute if
one-argument -u "works" on cygwin); but was merely pointing out that in
your further investigation of the issue, you were creating an
unsupported 2-argument she-bang line, and thus not testing what you
thought you were testing.
As for history of shebang,
https://en.wikipedia.org/wiki/Shebang_%28Unix%29 states that whether
subsequent arguments are split (Solaris) or provided as one argument
(Linux) has been a long time issue, quoting at least this article from
2008
http://mail-index.netbsd.org/netbsd-users/2008/11/09/msg002388.html,
although I'm sure you could trace it back at least to the 1980s. The
Linux man pages for execve state:
A maximum line length of 127 characters is allowed for the first
line
in a #! executable shell script.
The semantics of the optional-arg argument of an interpreter
script
vary across implementations. On Linux, the entire string
following the
interpreter name is passed as a single argument to the
interpreter, and
this string can include white space. However, behavior differs
on some
other systems. Some systems use the first white space to
terminate
optional-arg. On some systems, an interpreter script can have
multiple
arguments, and white spaces in optional-arg are used to
delimit the
arguments.
Since cygwin emulates Linux, it makes sense that Cygwin likewise accepts
exactly one argument on the shebang line.
>
>> > Also weird -- the interp line says "/bin/bash" not "/usr/bin/bash"
>> > as the shell, so why does the error come from /usr/bin/bash?
>>
>> the answer to this question.
> ---
> ???
> This isn't clear to me. If I am running /bin/bash, why did the error
> message
> say /usr/bin/bash?
>
Because you weren't running /bin/bash at that point in time, but
/usr/bin/bash. Again, you snipped the relevant portion of your original
mail:
| > bash t.sh
but that says to run 't.sh' using the 'bash' interpreter found first in
your PATH (which presumably had /usr/bin before /bin), and not as a
standalone executable. A shebang line is ignored when you run a script
directly as an argument to 'bash' - the only time a shebang line is
honored is when it appears as argv[0] of the execve() family of
functions (your command line had it as argv[1]). To use the shebang,
you have to execute 't.sh', not 'bash t.sh'. Remember, when bash
executes a script, the #! line is a comment that does not further impact
how bash behaves.
(If you look at the bash source code, it does have fallback code to
emulate shebang magic on platforms where execve() fails due to lacking
shebang support. But there are two things to note - this fallback does
NOT kick in on cygwin, since cygwin's execve() DOES have shebang
support; and even with that fallback code in bash, it is still only
triggered in instances where you try to execute a script as argv[0] of
the child process, and NOT when you pass the script name as argv[1] of
the bash process.)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-05-01 6:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-28 20:43 Linda Walsh
2014-04-28 21:18 ` Eric Blake
2014-05-01 5:57 ` Linda Walsh
2014-05-01 6:41 ` Eric Blake [this message]
2014-05-01 18:11 ` Linda Walsh
2014-05-01 20:41 ` two execve() inconsistencies [was: cygwin-bash compat/regression bug... startup line prob] Eric Blake
2014-05-02 21:44 ` two execve() inconsistencies (was cygwin-bash compat/regression bug... startup line prob) Linda Walsh
2014-05-01 22:11 cygwin-bash compat/regression bug... startup line prob Linda Walsh
2014-05-02 1:33 ` Eric Blake
2014-05-03 19:01 ` Linda Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5361ECA1.1040302@redhat.com \
--to=eblake@redhat.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).