Re: Is it normal for `bash -s foo` not to make 1=foo available from ~/.bashrc?

[Torka Noda]

On Tue, 28 Mar 2017 10:29:57 -0400
Chet Ramey <chet.ramey@case.edu> wrote:
> On 3/27/17 8:32 AM, Torka Noda wrote:
> > On Sat, 25 Mar 2017 15:33:47 -0400
> > Chet Ramey <chet.ramey@case.edu> wrote:  
> >>>
> >>> Is it normal for Bash positional parameters not to be
> >>> available from ~/.bashrc during initialization?    
> >>
> >> Yes. Bash has always worked like this.  The startup files
> >> are read before the positional parameters are assigned.
> >>  
> > 
> > 
> > For any particular reason?  
> 
> I can't remember whether there was any particular rationale;
> the decision was made almost 30 years ago.  Brian and I
> certainly never talked about it. Is there a compelling reason
> to change it now, since there are other ways to accomplish it?
> 


The need certainly isn't strong for my case, it's just OCD
(`bash -s coding` feels 'cleaner' than `env PROFILE=coding
bash`).

Philosophically, `bash -s` isn't meant for what I'm trying to
do anyway, while using `env` (or just setting the variable in
front, when supported by the program executing the command) is
perfectly valid, so I can't really argue more.

Actually, shouldn't `bash -s`, without any command fed to its
stdin, exit immediately, anyway...?

It's just that positional parameters from '-s' are currently
made available to Bash after initialization, so it felt weird
they weren't available from init files too. Plus there is
apparently no way to get the full list of arguments used to
call Bash (although some can be found with `set` or `shopt`),
even after initialization, which seems to me more problematic,
although if this was never the case, the need probably isn't
that strong for it either...