bash 5.2 bad substitution for ${x:+${x}[}

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux … 5.18.16-…-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-… (2022-…) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Pat

Mailcheck during completion

ted in response to a completion. Instead, the only places where such a check should be performed are in my opinion the initial prompt after startup and any prompt after a command was actually executed. Just pressing enter with an empty command line should also do the check, I think. Greetings

completion handles variables inconsistently

well, but there appears to be nothing specific to Gentoo about this. So I'm forwarding the bug report here. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature

Re: Mailcheck during completion

Hi Chet, thanks for the swift reply! On 11.08.2011 15:54, Chet Ramey wrote: > I suspect that you have a completion defined for `ls' and it's running a > command or process substitution that's causing the mail check. Can you > run `set -x', then attempt the completion again and post the results?

Re: Mailcheck during completion

On 12.08.2011 01:05, Chet Ramey wrote: > It's eval. Try the attached patch. Works like a charm. Thanks a lot! Martin signature.asc Description: OpenPGP digital signature

Re: bash tab variable expansion question?

uncomleted strings from 3. and replace them with the unexpanded forms from 2. I'm not sure what behaviour I'd expect if the variable contains several words. Don't care too much for that case, so I'll be happy with any solution. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature

RFE: brace expansion sequences should do zero padding [patch]

, Martin von Gagern Patch by Martin von Gagern <[EMAIL PROTECTED]> to allow zero-padded numbers in bash brace expansion sequences. diff -pur bash-3.2/braces.c bash/braces.c --- bash-3.2/braces.c 2006-09-09 04:57:17.0 +0200 +++ bash/braces.c 2007-08-29 23:02:02.0 +0200 @@ -61,7

RFE: brace expansion sequences should do zero padding [patch]

, Martin von Gagern P.S.: This is the second time I post this message here. The first one was via NNTP and it seems like it didn't make it. Patch by Martin von Gagern <[EMAIL PROTECTED]> to allow zero-padded numbers in bash brace expansion sequences. diff -pur bash-3.2/braces.c ba

Re: RFE: brace expansion sequences should do zero padding

to generate some feedback here. If you think this useful, tell me about it, and I'll try a bit harder to get this into the offical sources. If I get no single answer this time as well, I'll probably post the patch somewhere online, patch my own version of bash, and that's it. Greetings,

Re: RFE: brace expansion sequences should do zero padding

ce expansion the world splitting is implicit. Yes, I know, this as well can be solved using other tools, probably together with bash arrays. However there will be a huge overhead. On the other hand, brace expansion is intuitive, quick to write, easy to read, and gets the job done - if the job doesn

extglobs in case constructs

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

Re: extglobs in case constructs

Greg Wooledge wrote: > You're using extglobs inside a function, and extglob was enabled > at the time the function was delcared. The parser parsed them at that > time, decided that they are extended globs, and therefore that's what > they are. Then why don't they work as extended globs if the ext

Re: extglobs in case constructs

Martin von Gagern wrote: > I've found out that extglobs behave differently in different > constructs. To avoid syntax errors, the always have to be > enabled at parse time. > For comparison constructs like ``[[ $v == a@(a|b|c)c ]]'' this

Re: extglobs in case constructs

Chet Ramey wrote: > In general, if you enable extglob before a function is parsed and leave > it on when the function is executed, you should be ok. I'm thinking about this in terms of bash completion functions. Many of them use extended globs, but they should not force a specific permanent extglo

make -j# for parallel build failed

There was an issue reported and hopefully solved at gentoo: http://bugs.gentoo.org/show_bug.cgi?id=87247 http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-shells/bash/files/bash-3.0-parallel.patch?rev=1.1&content-type=text/vnd.viewcvs-markup This should probably be fixed upstream as well. ___