Re: compgen -W doesn't split wordlist containing single quotes

On Sat, Mar 17, 2018 at 1:00 AM, wrote: > > It works correctly if the single quote is itself quoted. Our test wordlist > would then be: "foo\'bar aaa bbb" > > paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- a > aaa > paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- b

Re: question on retrieving map(-A) value w/indirect name

On 3/16/18 8:50 PM, L A Walsh wrote: > > I'm a bit confused ... > If I have assoc-array: > >  declare -A foo=([one]=11 [two]=22) > > and am passing name in another var, like "fee" > >  fee=foo > > I tried echoing the val: > >  echo ${!fee[one]} > > but got nothing -- tried a few other

Re: mapfile documentation

On 3/16/18 3:55 PM, Greg Wooledge wrote: >> That >> sounds like quite a 'gotcha' and isn't mentioned in the man page >> documentation for mapfile. Do you think it should be? Should I continue >> this now on-list and ask for it to be mentioned? Each process in a pipeline is run in a subshell

Re: mapfile documentation

Boruch Baum wrote: I'm afraid what prompted me to file the report was something more subtle. Upon trying my test one-liner on a second virtual terminal, the one-liner worked, so I'm now trying to figure out what settings might affect the behavior. My test one-liner is: printf "aa bb\n

Re: ${parameter/pattern/string} behaviour changed

d...@ftb-esv.de wrote: Description: Command: x="a b c"; echo "'${x// /','}'" On old systems the output is: 'a','b','c' In this version the output is: 'a,b,c' This new behavior breaks some scripts. --- The way I'd see it is that the ',' in the replacement

question on retrieving map(-A) value w/indirect name

I'm a bit confused ... If I have assoc-array: declare -A foo=([one]=11 [two]=22) and am passing name in another var, like "fee" fee=foo I tried echoing the val: echo ${!fee[one]} but got nothing -- tried a few other syntaxes. If I ignore the indirect char '!', and do it the old way but

Re: ${parameter/pattern/string} behaviour changed

On Fri, Mar 16, 2018 at 1:18 PM, wrote: [...] > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > Command: x="a b c"; echo "'${x// /','}'" > On old systems the output is: 'a','b','c' > In this version the output is: 'a,b,c'

Re: ${parameter/pattern/string} behaviour changed

On Fri, Mar 16, 2018 at 08:18:53PM +0100, d...@ftb-esv.de wrote: > Command: x="a b c"; echo "'${x// /','}'" > On old systems the output is: 'a','b','c' > In this version the output is: 'a,b,c' So, this LOOKS like an attempt to take a list, and write it out with single quotes

${parameter/pattern/string} behaviour changed

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.3 -L/home/abuild/rpmbuild/BUILD/bash-4.3/../readline-6.3 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu'

Re: mapfile documentation

On Fri, Mar 16, 2018 at 03:45:42PM -0400, Boruch Baum wrote: > On 2018-03-16 14:59, Greg Wooledge wrote: > > wooledg:~$ set +m > > wooledg:~$ echo hello world | readarray; declare -p MAPFILE > > declare -a MAPFILE=([0]=$'hello world\n') > > > > lastpipe will typically work in a script, because job

Re: mapfile documentation

On Fri, Mar 16, 2018 at 02:59:53PM -0400, Greg Wooledge wrote: > On Fri, Mar 16, 2018 at 02:06:09PM -0400, Boruch Baum wrote: > >echo $IFS |xxd > >: 0a > > This command will never reveal any information, period. I was slightly mistaken there. It actually reveals the number of

Re: mapfile documentation

You forgot to Cc: the mailing list. I think this was on bug-bash...? On Fri, Mar 16, 2018 at 02:06:09PM -0400, Boruch Baum wrote: > On 2018-03-16 09:22, Greg Wooledge wrote: > > On Fri, Mar 16, 2018 at 09:14:13AM -0400, Boruch Baum wrote: > > > In GNU bash, version 4.4.18(1)-release

compgen -W doesn't split wordlist containing single quotes

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'

Re: Variables getting silently unset on redeclaration

On 3/15/18 10:30 PM, dtr@home.homenet wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > Variables mistakenly declared as local and then set as global > happen to be unset for the “nounset” option and known > to “declare -p” at

Re: Strange/incorrect behavior of a fake executable file

On Wed, Mar 14, 2018 at 08:43:45AM -0400, Greg Wooledge wrote: > > 1) You do not provide a hash-bang (i.e. #!/bin/bash), which means that > > /bin/sh will be used ( > > No, that's incorrect. When bash tells the operating system to run > this program, the operating system will return ENOEXEC

Re: mapfile documentation

On Fri, Mar 16, 2018 at 09:14:13AM -0400, Boruch Baum wrote: > In GNU bash, version 4.4.18(1)-release (x86_64-pc-linux-gnu), the first > line of the documentation for readarray / mapfile states: > >Read lines from the standard input ... > > However, it doesn't seem to accept input from a

mapfile documentation

In GNU bash, version 4.4.18(1)-release (x86_64-pc-linux-gnu), the first line of the documentation for readarray / mapfile states: Read lines from the standard input ... However, it doesn't seem to accept input from a pipe. It would be helpful to note that. -- hkp://keys.gnupg.net CA45 09B5

Re: autocompletion won't work for file names cotnaining an "@" like /tmp/@world.history

On 3/16/18 5:51 AM, Toralf Förster wrote: > tested at a hardened stable Gentoo Linxu with 4.4_p12. `@' is one of the characters that breaks words for the completer, so you can do hostname completion. The current set of completion word break characters is available as $COMP_WORDBREAKS. > Other

Re: [PATCH] allow file modes up to 7777 instead of 777

On 3/15/18 4:11 PM, Martijn Dekker wrote: > Op 14-03-18 om 16:49 schreef Martijn Dekker: > [...] >> { >>digits++; >>result = (result * 8) + (*string++ - '0'); >> - if (result > 0777) >> + if (result > 0) >> return -1; >> } >> >> By the way, why does

autocompletion won't work for file names cotnaining an "@" like /tmp/@world.history

tested at a hardened stable Gentoo Linxu with 4.4_p12. Other devs reported that autocompeltion won't work too in a construct like "cat $(cat somefil" I'm however unsure if this is a bug or a known feature ? -- Toralf PGP C4EACDDE 0076E94E signature.asc Description: OpenPGP digital

Re: docs incorrectly mention pattern matching works like pathname expansion

On Fri, Mar 16, 2018 at 10:04:07AM +, Stormy wrote: > Thanks for the confirmation regarding the need to write code. and also about > 'cd' 'ls', yeah, it's what I sort of mean, bash does when passing args to > them, but there is no other way to 'access' this type of parsing.. You are still

Re: docs incorrectly mention pattern matching works like pathname expansion

Date:Fri, 16 Mar 2018 10:04:07 + (UTC) From:Stormy Message-ID: <1098519022.1750755.1521194647...@mail.yahoo.com> | however, both paths need to be normalized fully before Yes, you're right, I did not consider that, but skipping empty

Re: docs incorrectly mention pattern matching works like pathname expansion

Date:Thu, 15 Mar 2018 22:52:24 + (UTC) From:Stormy Message-ID: <68229887.1497301.1521154344...@mail.yahoo.com> | but there is no way to make it do pathname matching internally. (cd, ls, will surely do it, No, they surely don't - the

Re: Avoiding file-based constraints for tmp files (ws Re: [minor] umask 400 causes here-{doc, string} failure)

Date:Thu, 15 Mar 2018 08:37:39 -0400 From:Greg Wooledge Message-ID: <20180315123739.vd7zdj37irnt4...@eeg.ccf.org> | That said, I think a lot of scripts *do* bend this rule and rely on | the here-document creating a seekable temp file, because