On Tue, 28 Mar 2017 19:13:55 +0200 Torka Noda <kanito.tas...@gmail.com> wrote:
> On Mon, 27 Mar 2017 10:04:16 -0400 > Daniel Mills <danielmil...@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...
