Re: In ((0? var: 0)), expressions stored in var are evaluated.

> Variables in the discarded branches of conditional expressions are > evaluated. This is caused by the function `evalcond' in expr.c. The Sorry, `evalcond' in the previous mail should have been `expcond'. Regards, Koichi

In ((0? var: 0)), expressions stored in var are evaluated.

Hello, here is another bashbug report. Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCAL

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

On 11/1/16 5:57 AM, Dan Douglas wrote: > On Mon, Oct 24, 2016 at 8:25 AM, Chet Ramey wrote: >> On 10/21/16 5:41 PM, L. A. Walsh wrote: >>> On 4.3 and earlier, at least on arrays, one could have >>> the illusion of this working w/o complaint -- and returning >>> 0 when the array was 0-len or unset,

Re: Why does bash use xmalloc?

Peng Yu wrote: > My point is why bash terminates when it runs an external command that > requires a large memory. Shouldn't bash return an exit code on behalf > of the failed command and continue to the next command? Note that I am going to say something without looking at the source code of bash

Re: SIGINT kills interactive shell from dot script

On 11/6/16 4:08 AM, Martijn Dekker wrote: > An interactive bash is killed by SIGINT after a command to unset any > trap for SIGINT. > > $ cat >/tmp/dotscript < trap > trap - INT > kill -s INT "$$" > EOF > $ . /tmp/dotscript > (no output of 'trap') > (interactive shell exits) You're on a roll find

Re: "builtin printf '\uFF8E'" generates broken surrogate pairs in Cygwin

On 11/6/16 12:38 AM, Koichi MURASE wrote: > Bash Version: 4.3 > Patch Level: 46 > Release Status: release > > Description: > > I noticed that built-in commands "printf '\uFF8E'", etc. generate > broken surrogate pairs in Cygwin. Thanks for the report and fix. Chet -- ``The lyf so short, t

Re: [bug] [[ $'\Ux' = $'\Ux' ]] returns false for some values of x in some locales

2016-11-04 12:29:03 +, Stephane Chazelas: [...] > $ LC_ALL=zh_HK.big5hkscs locale charmap > BIG5-HKSCS > > Most of the problematic characters are the ones ending in 0x5c > (which happens to be backslash in ASCII (or in BIG5-HKSCS when > standing alone). [...] Those characters are also a probl

Re: SIGINT kills interactive shell from dot script

Op 06-11-16 om 09:08 schreef Martijn Dekker: > An interactive bash is killed by SIGINT after a command to unset any > trap for SIGINT. ...if executed in a dot script, that is (in case that wasn't clear from the subject line and the code examples). Another datapoint: the same phenomenon occurs if

Re: Why does bash use xmalloc?

On Nov 06 2016, Peng Yu wrote: > My point is why bash terminates when it runs an external command that > requires a large memory. Shouldn't bash return an exit code on behalf > of the failed command and continue to the next command? You have limited the amount of memory the shell itself can use,

Re: Why does bash use xmalloc?

The artificial ulimit is to tigger the error. My point is why bash terminates when it runs an external command that requires a large memory. Shouldn't bash return an exit code on behalf of the failed command and continue to the next command? On Sunday, November 6, 2016, Eduardo Bustamante wrote:

SIGINT kills interactive shell from dot script

An interactive bash is killed by SIGINT after a command to unset any trap for SIGINT. $ cat >/tmp/dotscript <

Re: Why does bash use xmalloc?

Hi Peng. Read the link you provided again. xmalloc is not an alternative version of malloc. It's just a common wrapper function around malloc. You can go and see for yourself, the definition is here: http://git.savannah.gnu.org/cgit/bash.git/tree/xmalloc.c#n97 If you want the rest of the commands