Re: [BUG] incorrect exit status from subshell on bash with --enable-minimal-config
On 9/21/16 7:06 PM, Martijn Dekker wrote: > On bash with --enable-minimal-config, as of version 4.3 (as far as I can > tell), there appears to be a bug with the exit status on returning from > subshells. Apparently the exit status of the subshell is not given to > the main shell. Thanks for the report. This is related to http://lists.gnu.org/archive/html/bug-bash/2016-08/msg3.html but affects only those builds without job control. I will fix it in the devel branch with the next push. 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: local --help should work outside of functions
On 9/22/16 7:13 AM, Norm Abramovitz wrote: > Bash Version: 4.4 > Patch Level: 0 > Release Status: release > > Description: > > I was playing around with the new --help feature and I was expecting it > should work for all commands at the interactive prompt. The local command > did not work that way. Can exceptions be made for the local command? This is a reasonable suggestion. 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/
Racing condition leads to unstable exit code
Hello,
I'm using 'GNU bash, version 4.3.46(1)-release (x86_64-suse-linux-gnu)'
provided by OpenSUSE Tumbleweed. I recently faced a problem that, depending
on the system load, bash returns different exit codes. I detected that it
is related to trap processing.
My tests uses 3 blocks of code:
1) installs a trap for USR1 and calls function testme
2) calls (3) in background, waits for it and return its exit code
3) send kill -USR1 to main process (1)
The way (1) calls (2) has some variants:
a) direct call: testme
b) as a subshell: (testme)
c) as a command substitution $(testme)
I added some sleeps in order to have these variations:
x) main bash instance receives signal after the code on (2) reaches the
wait (which might be a subprocess when (b) and (c)
y) main bash instance receives signal before the code on (2) reaches the
wait
w) main bash instance finish signal processing before the code on (3)
returns
z) main bash instance finish signal processing after the code on (3) returns
When I have scenarios "a,x,{w,z}", trap is received while main instance is
running wait. It returns error code 138. I know that this is a documented
behavior to return 128+signal. However, letting the time a signal reaches
the process change wait behavior seems to be a weak solution. I guess wait
should ignore this signal when there is a trap waiting for that signal. I
really don't understand why wait should return at all when process receives
a signal. Anyway, this is not the bug.
When I have scenarios "a,y,{w,z}", bash works nicely. When I have scenarios
"b,{x,y},{w,z}", bash also works nicely, even using subshell. The scenario
"c,{x,y},w"
also is OK. The only problem is with "c,{x,y},z", when the command
substitution subshell returned while the trap was still running. Even
returning code 2, the caller installed gets 0. it seems that trap
processing cleans the exit code of any finished command substitution. I
guess this is not expected :-)
A simple version of the test code that considers only scenario c,x,z is this
#!/bin/bash
#
trap_USR1() {
echo "$BASHPID:Trap USR1 start"
sleep 3
echo "$BASHPID:Trap USR1 end"
}
testme() {
(
sleep 0.5
kill -USR1 $parent
sleep 0.5
err=2
echo "$BASHPID:exit $err..." >&2
exit $err
) &
_pid=$!
echo "$BASHPID:waiting $_pid" >&2
wait $_pid
err=$?
echo "$BASHPID:return $err" >&2
return $err
}
parent=$BASHPID
echo "$BASHPID:I'm installing trap USR1..." >&2
trap trap_USR1 USR1
x=$(testme)
echo "$BASHPID:err=$? (should be equal previous return) command
substitution" >&2
testme return 2 while $? on the last line gets 0. I'll attach a full
version script.
Regards,
--
Luiz Angelo Daros de Luca
luizl...@gmail.com
full.sh
Description: application/shellscript
Re: Execution of a data string
On 9/21/16 11:15 PM, mobatu...@yahoo.ca wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > ___ > You can see in the picture below that: > declare -a "$ExecuteThisData" > resulted in executing the string "$ExecuteThisData" without > eval being explicitly invoked. I believe this is unintentional since this > is a variable assignment: Not exactly, but the story is somewhat complicated. `declare' is a builtin command. It's not part of the shell syntax, so its arguments undergo a round of word expansion before declare sees them. It's also desirable to make something like `declare -a x=(foo bar)' work the same as `declare -a x; x=(foo bar)', but that's problematic given its status as a builtin instead of a reserved word. The basic issue is that by the time declare sees it, there's very little difference between declare -a "$ExecuteThisData" and declare -a a=($Data) As the shell has evolved, I've changed `declare' to behave more like a reserved word than a regular builtin, so the arguments that look like assignment statements before word expansion can be identified and expanded like standalone assignment statements. For backwards compatibility, though, I retained the ability for declare to parse compound assignment statements that aren't marked as assignment statements by the parser. There was an extensive discussion about this after bash-4.3 was released, beginning at http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html that resulted in several changes to this type of construct in bash-4.4. However, for backwards compatibility, constructs such as the one you use are still accepted as they were in bash-4.2 and bash-4.3. 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: Execution of a data string
Reuti wrote: Am 22.09.2016 um 15:23 schrieb Greg Wooledge : On Wed, Sep 21, 2016 at 11:15:45PM -0400, mobatu...@yahoo.ca wrote: declare -a "$string" # results in execution of $string declare -a a=($string)# does not result in execution of $string This is why you don't use the first form. It's the same with eval -- if you don't have full control over the statement being eval'ed, then you risk undesired code execution. Even without `eval` it's dangerous, i.e. specifying solely $ExecuteThisData on the command line. It's amazing how much people expect to be protected from doing anything stupid. *nix is not a walled garden (despite appearances it is heading in that direction).
[PATCH] fix printf %b without an argument
here's a patch that fixes this problem
$ printf "<%3s><%3b>"
< ><>
---
xoxo iza
From c5ffd55ffa9224dd7919a4d09b27a11308d2152e Mon Sep 17 00:00:00 2001
From: izabera
Date: Sat, 24 Sep 2016 02:01:16 +0200
Subject: [PATCH] fix printf %b without an argument
old behavior:
$ printf "<%3s><%3b>"
< ><>
removed bogus check on xp returned by bexpand
printstr must not return immediately if the string is null
---
builtins/printf.def | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/builtins/printf.def b/builtins/printf.def
index d39a6d3..1037b5c 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -543,22 +543,19 @@ printf_builtin (list)
ch = rlen = r = 0;
xp = bexpand (p, strlen (p), &ch, &rlen);
- if (xp)
+ /* Have to use printstr because of possible NUL bytes
+ in XP -- printf does not handle that well. */
+ r = printstr (start, xp, rlen, fieldwidth, precision);
+ if (r < 0)
{
- /* Have to use printstr because of possible NUL bytes
- in XP -- printf does not handle that well. */
- r = printstr (start, xp, rlen, fieldwidth, precision);
- if (r < 0)
+ if (ferror (stdout) == 0)
{
- if (ferror (stdout) == 0)
- {
- sh_wrerror ();
- clearerr (stdout);
- }
- retval = EXECUTION_FAILURE;
+ sh_wrerror ();
+ clearerr (stdout);
}
- free (xp);
+ retval = EXECUTION_FAILURE;
}
+ free (xp);
if (ch || r < 0)
PRETURN (retval);
@@ -711,8 +708,7 @@ printstr (fmt, string, len, fieldwidth, precision)
int fw, pr; /* fieldwidth and precision */
intmax_t mfw, mpr;
- if (string == 0 || len == 0)
-return 0;
+ if (string == 0) string = "";
#if 0
s = fmt;
--
2.10.0
