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'
-DLOCALEDIR='/home/murase/opt/bash-4.4/share/locale' -DPACKAGE='ba\
sh' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2
-march=native -Wno-parentheses -Wno-format-security
uname output: Linux padparadscha 4.7.2-101.fc23.i686 #1 SMP Fri Aug 26
16:39:46 UTC 2016 i686 i686 i386 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.4
Patch Level: 0
Release Status: release
Description:
Variables in the discarded branches of conditional expressions are
evaluated. This is caused by the function `evalcond' in expr.c. The
calls of `readtok' in `evalcond' are made before the global variable
`noeval' is set up.
Repeat-By:
$ bash-4.4 -c 'a=0 x="a=1"; ((0?x:0)); echo $a'
1
$ bash-4.4 -c 'a=0 x="a=1"; ((1?0:x)); echo $a'
1
The value 1 is set by the evaluation of x. But I expect the result 0
because the variable `x' is in the discarded branch and therefore is
natural not to be evaluated. All the other similar patterns returns 0:
$ bash-4.4 -c 'a=0 x="a=1"; ((0?(x):0)); echo $a'
0
$ bash-4.4 -c 'a=0 x="a=1"; ((0?$x:0)); echo $a'
0
In addition, variables in logical and/or expressions are not
evaluated if the branch is not selected:
$ bash-4.4 -c 'a=0 x="a=1"; ((0&&x)); echo $a'
0
$ bash-4.4 -c 'a=0 x="a=1"; ((1||x)); echo $a'
0
There is another pattern caused by the same bug.
$ bash-4.4 -c 'a=0; ((0?arr[a=1]:0)); echo $a'
1
All the versions of bash from 3.0 to 4.4 behave the same. Is the
result `1' intended? It's not intuitive for me.
Fix:
In `evalcond', the selection of branches are controlled by setting
the global variable `noeval'. While, evaluation of variables are made
in `readtok'. The function `readtok' is aware of `noeval', but is
called by `evalcond' before `noeval' is modified. In the following
patch, the calls of `readtok' are moved after the set of `noeval'.
diff --git a/expr.c b/expr.c
index 1ddb693..ad3e24d 100644
--- a/expr.c
+++ b/expr.c
@@ -578,24 +578,21 @@ expcond ()
rval = cval = explor ();
if (curtok == QUES) /* found conditional expr */
{
- readtok ();
- if (curtok == 0 || curtok == COL)
- evalerror (_("expression expected"));
if (cval == 0)
{
set_noeval = 1;
noeval++;
}
+ readtok ();
+ if (curtok == 0 || curtok == COL)
+evalerror (_("expression expected"));
val1 = EXP_HIGHEST ();
if (set_noeval)
noeval--;
if (curtok != COL)
evalerror (_("`:' expected for conditional expression"));
- readtok ();
- if (curtok == 0)
- evalerror (_("expression expected"));
set_noeval = 0;
if (cval)
{
@@ -603,7 +600,11 @@ expcond ()
noeval++;
}
+ readtok ();
+ if (curtok == 0)
+evalerror (_("expression expected"));
val2 = expcond ();
+
if (set_noeval)
noeval--;
rval = cval ? val1 : val2;
Regards,
Koichi
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, or the array length,
>>> otherwise:
>>>
>>>
>>> echo ${#array[@]:-0}
>>>
>>> But I note it only seemed to work in arrays, and in 4.4 gets a
>>> syntax error:
>>>
>>> echo ${#array[@]:-0} bash: ${#array[@]:-0}: bad substitution
>>
>> Because it is a syntax error, and if it were not it would be ambiguous.
>> The ${param:-word} word expansion takes a parameter, not another word
>> expansion, as the object to be expanded.
>
> On a possibly related note, would you consider adjusting +, :+, -, :-,
> as in "${var[@]+word}" to align with the meaning of [[ -v var[@] ]] as
> discussed in https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00099.html
> ?
There's not a compelling reason to break backwards compatibility or to be
unnecessarily incompatible with other shells that implement that construct,
like ksh93.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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 to say it. Therefore I might be wrong about bash. But it is a general statement about shells. > ... runs an external command that requires a large memory If bash is running an external comand then it will be doing so in a fork()'d off subshell using exec(). It won't be bash anymore but the other process. If it exits after the fork but before the exec then it will be the subshell child process that exits not the main bash execution thread. If the bash process itself has grown very large then the fork() might fail on systems that do not use memory overcommit. (Traditional Unix kernels or Linux kernels with overcommit disabled for robustness.) If the fork fails then I am not sure what bash should do in that case. It could potentially loop and retry a few times but if all fail then exiting is probably the only reasonable action. If bash itself is running out of memory then it is almost certainly due to inefficient shell scripting. For example like one that I analyzed in this thread. Of course that is just one of many possibilities. http://lists.gnu.org/archive/html/bug-bash/2011-11/msg00189.html Bob
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 finding long-lived bugs this week. This behavior has been there for at least 20 years (I stopped looking when I got to 1995). It should be an easy thing to change. > Interestingly, the shell does not exit without the "trap - INT", > although no trap was set for INT to begin with (as shown by the empty > output of "trap"). It looks like the shell interpreted "reset to the default value" a little too literally in this particular case. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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 problem for "read", "echo" and
probably many other cases:
$ echo $'\u3b1 b c' | bash -c 'read a b c; echo $b'
c
$ echo $'\u3b1 b c' | ksh93 -c 'read a b c; echo $b'
c
$ echo $'\u3b1 b c' | zsh -c 'read a b c; echo $b'
b
$ echo $'\u3b1 b c' | yash -c 'read a b c; echo $b'
b
$ locale charmap
BIG5-HKSCS
(ksh93 has a similar bug).
\u3b1 is the Greek lower case alpha character encoded as a3 5c
in that Hong Kong charset.
Also:
$ export alpha=$'\u3b1'
$ printf 'A%sB\n' "$alpha" | bash -c 'IFS=$alpha read a b c; echo $b'
(that one is OK in ksh93, zsh and bash).
$ bash -c 'echo -e "a${alpha}b"' | LC_ALL=C sed -n l
a\243\b$
(second byte of \u3b1 with "b" expanded to BS).
(same bug in zsh and ksh93, only yash OK).
(same with $'...' and printf)
--
Stephane
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 the SIGINT trap is unset from within the trap itself. $ trap 'echo "unignoring SIGINT"; trap - INT; kill -s INT "$$"' INT $ kill -s INT "$$" unignoring SIGINT (interactive shell exits. Expected behaviour: return to command prompt with exit status 130) Thanks, - M.
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, that has nothing to do with the command you ran. There is no way the shell can continue in this situation, if it cannot allocate any memory at all. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
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: > 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 execute properly, then make sure > that there's enough memory in the system, and remove artificial > restrictions (ulimit -v?). There's no trick here, and certainly no bug > in bash. > -- Regards, Peng
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 execute properly, then make sure that there's enough memory in the system, and remove artificial restrictions (ulimit -v?). There's no trick here, and certainly no bug in bash.
