2017-09-10 14:56:50 -0400, Chet Ramey:
> On 9/10/17 11:11 AM, Stephane Chazelas wrote:
> > When running bash as:
> >
> > bash -s foo bar
> >
> > "$@" is not available inside .bashrc. Same for $ENV (POSIX
> > conformance issue?), $BASH_ENV, or ~/.bash_profile (with bash
> > --login -s).
> >
> > In the case of bash -c, that also affects $0.
>
> Bash has always behaved like this, and it's not a Posix conformance
> issue. Is there a compelling reason to change it other than compatibility
> with other shells?
[...]
I would say it would also be more useful and the behaviour less
surprising, and I would think aligning with other shells would
be very unlikely to break backward compatibility as I can't
think of any reason why anyone would rely on the current
behaviour.
In any case, I can't see anything in the POSIX spec allowing
the bash behaviour. printf '%s\n' "$1" should output the content
of the first positional parameter, there's no specific provision
for that not to be the case when that's done while interpreting
the content of $ENV.
It came up today when somebody was looking for some way to be
able to have the user interact with a shell interpreting a
script midway through the script. I would have expected the
script below to work:
#! /bin/sh -
[ "$0" = bash ] || exec bash --rcfile "$0" -s "$@" || exit 1
trap 'after "$@"' EXIT
before() {
echo something to do before $*
}
after() {
echo something to do after $*
}
before "$@"
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
--
Stephane
