Re: certain strings both legal and illegal as associative array keys

2015-03-09 Thread vampyrebat
> these two array subscripts, while > they appear identical, are not exactly the same: > > foo["a'b"]=two > unset foo["a'b"] > > The first does not undergo any word expansions before the array > assignment code runs, so that code performs the appropriate word > expansions (everything except word

Re: How to deal with errors in <()?

2015-03-09 Thread Peng Yu
On Mon, Mar 9, 2015 at 2:07 PM, Chet Ramey wrote: > On 3/8/15 6:05 PM, Stephane Chazelas wrote: > >> Are bash questions no longer on topic here? bash-bug used to be >> the place to discuss bash (before help-bash was created). It maps to the >> gnu.bash.bug newsgroup. I don't think help-bash maps t

Re: How to deal with errors in <()?

2015-03-09 Thread Chet Ramey
On 3/8/15 6:05 PM, Stephane Chazelas wrote: > Are bash questions no longer on topic here? bash-bug used to be > the place to discuss bash (before help-bash was created). It maps to the > gnu.bash.bug newsgroup. I don't think help-bash maps to usenet > (though you can access it over NNTP on gmane).

Re: The correct way to use "for" without polluting the environment

2015-03-09 Thread Chet Ramey
On 3/8/15 5:44 PM, Stephane Chazelas wrote: > BTW, to get back on topic: > > $ bash --norc -o posix > bash-4.3$ unset zzz > bash-4.3$ zzz=x eval > bash-4.3$ env | grep zzz > zzz=x > > ksh93, zsh (in sh emulation), dash, mksh, the Bourne shell (the > port of opensolaris' to Linux at least) do ret

Re: IFS=: & splitting paths -- (maybe fixed in 4.3?)

2015-03-09 Thread Greg Wooledge
On Sun, Mar 08, 2015 at 11:21:41AM -0600, Eduardo A. Bustamante López wrote: > > alias rs="IFS=\ $'\x09'$'\x0a'" > > The fuck? Just use > alias rs="IFS=\$' \t\n'" or even better, alias rs='unset IFS' rs() { IFS=$' \t\n'; } Aliases... my god, why? > > echo "1st try to split pth:" > > IFS=: ech

Re: How to deal with errors in <()?

2015-03-09 Thread Allodoxaphobia
On Sun, 8 Mar 2015 22:05:29 +, Stephane Chazelas wrote: > 2015-03-07 18:01:18 -0600, Eduardo A. Bustamante López: >> > But I am wondering if there is a walkaround to deal with errors in >> > <(). The ideal behavior should be that if there is a error in <(), >> > then we should not consider comm