"$@" eats adjacent quoted nulls when expanding to quoted null

2017-03-30 Thread Grisha Levit
(This is very similar to a fixed issue[1] from 4.4-beta) A quoted null string will fail to generate a field when it is adjacent to a double-quoted expansion of $@ which itself expands to a null string: $ set --; printf '<%s>' foo ''"$@" <> # correct $ set -- ''; printf '<%s>' foo ''"$

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

2017-03-30 Thread Grisha Levit
Sorry if you already noticed this: The latest devel push fixes the reported field-splitting case but there is a regression with the fields getting re-joined with spaces when performing an assignment: $ set -- 1 2; IFS=; a=$* b=${*/}; printf '<%s>' "$a" "$b" <12><1 2> and with the expansion

Symlinks handled inconsistently by cd and wild card expansion

2017-03-30 Thread Topi Mäenpää
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: 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/share/locale' -DPACK

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

2017-03-30 Thread Grisha Levit
Also some expansions, like ${array[*]:num}, have an issue when the first character of IFS is not whitespace: $ IFS=:; A=(1 2); a=${A[*]} b=${A[*]:0}; printf '<%s>' "$a" "$b" <1:2><1 2> I put together a script (attached) to test the invariance of the interp 888 expansion rules under transfor

Re: Symlinks handled inconsistently by cd and wild card expansion

2017-03-30 Thread Chet Ramey
On 3/30/17 3:13 AM, Topi Mäenpää wrote: > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > > The cd command remembers where I came from, and "cd .." from a > symlinked directory comes back to the directory of the link. Wild card > expansion works differently and a

Re: Symlinks handled inconsistently by cd and wild card expansion

2017-03-30 Thread Reuti
Hi, > Am 30.03.2017 um 09:13 schrieb Topi Mäenpää : > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-li

Re: Symlinks handled inconsistently by cd and wild card expansion

2017-03-30 Thread Chet Ramey
On 3/30/17 11:55 AM, Reuti wrote: > There are the options -P and -L to `pwd` and `cd`, i.e. and `cd -P ..` > follows the path up, independent from the symlink, while the default is -L. > > I don't think that changing it in general would be good, but agree that it > might honor -P or -L. But thi

Re: Symlinks handled inconsistently by cd and wild card expansion

2017-03-30 Thread Reuti
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.03.2017 um 20:06 schrieb Chet Ramey: > On 3/30/17 11:55 AM, Reuti wrote: > >> There are the options -P and -L to `pwd` and `cd`, i.e. and `cd -P ..` >> follows the path up, independent from the symlink, while the default is -L. >> >> I don't

``shopt -s extglob'' and ``function @() { true; }''

2017-03-30 Thread Clark Wang
There is a post on stackoverflow: http://stackoverflow.com/questions/43117707/bashs-strange-behavior-on-a-function-named/ The *problem*: bash-4.4# shopt -s extglob bash-4.4# function @() { echo foo; } bash-4.4# @() foo bash-4.4# declare -f @() () { echo foo } bash-4.4# bash-4.4# unset -f '@()

Re: ``shopt -s extglob'' and ``function @() { true; }''

2017-03-30 Thread Pierre Gaston
On Fri, Mar 31, 2017 at 7:00 AM, Clark Wang wrote: > There is a post on stackoverflow: http://stackoverflow.com/ > questions/43117707/bashs-strange-behavior-on-a-function-named/ > > The *problem*: > > bash-4.4# shopt -s extglob > bash-4.4# function @() { echo foo; } > bash-4.4# @() > foo > bash-4