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

On Wed, 29 Mar 2017 10:26:14 -0400 Greg Wooledge wrote: > On Wed, Mar 29, 2017 at 04:10:14PM +0200, Torka Noda wrote: > > Well, sorry for the confusion, I'll stop here. I think it's > > weird for Bash's positional parameters, and the whole > > argument l

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

On Tue, 28 Mar 2017 19:13:55 +0200 Torka Noda wrote: > On Mon, 27 Mar 2017 10:04:16 -0400 > Daniel Mills wrote: > > > > Because you want the positional parameters set with bash -s > > to take precedence over anything set in the startup files. > > Otherwise an

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

On Tue, 28 Mar 2017 16:43:17 -0400 Chet Ramey wrote: > > On 3/28/17 12:43 PM, Torka Noda wrote: > > > Actually, shouldn't `bash -s`, without any command fed to > > its stdin, exit immediately, anyway...? > > No. Why? It reads and executes commands from its st

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

On Mon, 27 Mar 2017 10:04:16 -0400 Daniel Mills 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. M

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

On Tue, 28 Mar 2017 10:29:57 -0400 Chet Ramey wrote: > On 3/27/17 8:32 AM, Torka Noda wrote: > > On Sat, 25 Mar 2017 15:33:47 -0400 > > Chet Ramey wrote: > >>> > >>> Is it normal for Bash positional parameters not to be > >>> available from

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

On Sat, 25 Mar 2017 15:33:47 -0400 Chet Ramey 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. > Fo

Re: Parameter operator P should probably strip \[ and \] characters

On Sat, 25 Mar 2017 15:16:31 -0400, Chet Ramey wrote: > > On 3/24/17 11:57 PM, Torka Noda wrote: > > From what I understand, \[ and \] characters are only > > useful for the prompts, right? > > Yes, but one of the primary motivations for including the @P > modifier

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

On Sat, 25 Mar 2017 05:40:18 +0100 Torka Noda wrote: > > The problem is that while PS1=foo is available once Bash has > finished initializing (i.e., from the command line), it is not > available from my ~/.bashrc, during initialization. > I meant 1=foo, here and in the title..

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

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/sha

Bash aliases erroneously expanded in 'case' patterns in some conditions

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/sha

Parameter operator P should probably strip \[ and \] characters

Hi, (Currently using Bash-4.4_p12 on Gentoo GNU/Linux). My PS1 contains colors, and thus \[ ... \] sequences around colors, for proper line wrapping on the command-line. I want to fake this prompt from my ~/.bashrc, because OCD, before I execute some commands printing stuffs in the shell. The p