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

[Torka Noda]

On Tue, 28 Mar 2017 19:13:55 +0200
Torka Noda <kanito.tasoga@gmail.com> wrote:

> On Mon, 27 Mar 2017 10:04:16 -0400
> Daniel Mills <danielmills1@gmail.com> wrote:
> >
> > Because you want the positional parameters set with bash -s
> > to take precedence over anything set in the startup files.
> > Otherwise anything in .bashrc would simply override what you
> > set with bash -s.
> >  
> 
> 
> They could simply be copied.
> 
> Modifying positional parameters with `set --` isn't supposed
> to modify the shell's behavior live, anyway. The command line
> is already parsed and options already set. So Bash should
> always use the original arguments specified on the command
> line, to pass them to the possible commands fed to its stdin,
> regardless of whether position parameters which could be made
> available to Bash initialization files are modified.
>


Alright, so I misunderstood things a bit...

`bash -s foo bar` is supposed to set Bash's positional
parameters, not the ones of the commands fed to its stdin, and
by stdin, it can well mean commands fed to its prompt, in an
interactive shell, after initialization...

In this case, yes, we could discuss the matter of priority,
because modifying the positional parameters with `set -- foo
bar` would override Bash's positional parameters, before they
are used by the commands fed to its stdin...


However, that is actually already the case. You can use `set --
foo2 bar2` in your ~/.bashrc, and you get:

========================================
$ bash -s foo1 bar1
$ echo $1 $2
foo2 bar2
========================================


You will get "foo1 bar1" if you run:

`echo 'echo $1 $2' | bash -s foo1 bar1`

... but that's only because in this case, the shell is not
interactive (and exits immediately after running the `echo`
command), so ~/.bashrc is not read.


Philosophically, ~/.bashrc is an active initialization file, so
I'm not sure it shouldn't get the priority over command-line
arguments... It's a different situation from passive
configuration files, which sure should be overridden by
command-line arguments... Active initialization files are a
more integral part of the program, and thus should be able to
process them in various ways for the remaining of the
program's execution, including, in practice, replacing them
completely...

Anyway, currently, ~/.bashrc does get the priority over
command-line arguments, for positional parameters.

Plus, if just running `bash -s foo bar`, the positional
parameters from the command-line, if unmodified in ~/.bashrc,
aren't used until you are in an interactive shell, in which you
could very well run `set -- something something`, anytime you
want... So why shouldn't it be possible from ~/.bashrc?


My problem is that the positional parameters can be modified
from ~/.bashrc all we want, but the original ones, from a `bash
-s foo bar` cannot be accessed from the same file, even
though they are, in this case, never used for anything else...

It really seems like a simple code-ordering situation, from
my perspective...