Re: splitting/whitespace in expansions of ${*} vs ${*/}

2017-03-25 Thread Chet Ramey
On 3/25/17 7:26 AM, Grisha Levit wrote: > It looks like using ${var/pattern} causes some changes in field- > splitting and whitespace-trimming behavior, even in the (presumably) > no-op case of ${*/}: Thanks for the report. Look like more fallout from Posix interp 888. I'll fix these, or at least

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

2017-03-25 Thread Chet Ramey
On 3/24/17 11:34 PM, Torka Noda wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > When sourcing a script (rather than executing it), if > the "in" keyword of a case construct is on its own line > (rather than on the first line of the const

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

2017-03-25 Thread Chet Ramey
On 3/25/17 12:40 AM, Torka Noda wrote: > ~/.bashrc: > == > #!/bin/bash > if [ -n "$1" ]; then > echo "\$1 set ($1)" > else > echo '$1 not set!' > fi > == > > $ bash -s foo > $1 not set! # <= $1 not available in ~/.bashrc. > > $

Re: splitting/whitespace in expansions of ${*} vs ${*/}

2017-03-25 Thread Chet Ramey
On 3/25/17 7:26 AM, Grisha Levit wrote: > It looks like using ${var/pattern} causes some changes in field- > splitting and whitespace-trimming behavior, even in the (presumably) > no-op case of ${*/}: Thanks for the report. I'll take a look. -- ``The lyf so short, the craft so long to lerne.''

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

2017-03-25 Thread Chet Ramey
On 3/24/17 11:57 PM, Torka Noda wrote: > 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 e

Re: pipefail with SIGPIPE/EPIPE

2017-03-25 Thread Chet Ramey
On 3/24/17 7:57 AM, Greg Wooledge wrote: > On Thu, Mar 23, 2017 at 10:14:01PM -0700, Pádraig Brady wrote: >> OK let's not derail this into a discussion specific to errexit. >> Can we please improve things? >> You say to not use errexit, and instead use `|| exit 1` where appropriate. >> In that case

Re: pipefail with SIGPIPE/EPIPE

2017-03-25 Thread Chet Ramey
On 3/23/17 3:27 PM, Jay Freeman (saurik) wrote: > (Potentially of mild interest is this thread on Hacker News from earlier > today, where multiple people are suggesting the usage of "set -e" along with > "set -u" and "set -o pipefile".) > > https://news.ycombinator.com/item?id=13940322 It's us

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

2017-03-25 Thread Torka Noda
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... Sorry for the p

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

2017-03-25 Thread Torka Noda
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

splitting/whitespace in expansions of ${*} vs ${*/}

2017-03-25 Thread Grisha Levit
It looks like using ${var/pattern} causes some changes in field- splitting and whitespace-trimming behavior, even in the (presumably) no-op case of ${*/}: $ set -- ' 1 ' ' 2 ' $ IFS=; printf '<%s>' ${*} ${*/} < 1 >< 2 >< 1 2 > $ IFS=; printf '<%s>' ${@} ${@/} < 1 >< 2 >< 1 2 > $ unset IFS; a=