[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "$@" not available in rcfile, $ENV, $BASH_ENV...

From: Stephane Chazelas
Subject: Re: "$@" not available in rcfile, $ENV, $BASH_ENV...
Date: Sun, 10 Sep 2017 20:51:22 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]