Re: bash test: lastpipe.tests failed

[dengke...@windriver.com]

Maybe my linux system have some problem. I have upgrade to the 4.3.46.

root@qemux86-64:~# /bin/bash test
test: line 3:  1055 Exit 142exit 142
  1054 Hangup  | false
142 129

root@qemux86-64:~# /bin/bash --version
GNU bash, version 4.3.46(1)-release (x86_64-poky-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 



This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

root@qemux86-64:~# uname -a
Linux qemux86-64 4.4.14-yocto-standard #1 SMP PREEMPT Tue Aug 2 06:48:36 
EDT 2016 x86_64 x86_64 x86_64 GNU/Linux



On 2016年08月12日 21:02, Chet Ramey wrote:

On 8/12/16 4:14 AM, dengke...@windriver.com wrote:

I used the strace tool to follow it. I touch a file named lastpipe just
contain:

 shopt -s lastpipe
 exit 142 | false

run command:)$ ./bash --version

OK.

$ ./bash --version
GNU bash, version 4.3.46(3)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ cat x1
shopt -s lastpipe
exit 142 | false

echo ${PIPESTATUS[@]}
$ ./bash ./x1
142 1
$ uname -a
Linux chet-mail 2.6.32-642.1.1.el6.x86_64 #1 SMP Fri May 6 14:54:05 EDT
2016 x86_64 x86_64 x86_64 GNU/Linux

Re: Intriguing error with arithmetic evaluation

[L. A. Walsh]

Chet Ramey wrote:
The relevant change was probably the change in the set of commands to 
which

`set -e' applies.  The (( command (among others) was added to that list
in bash-4.1.  The change was the result of Posix changing the semantics
of the errexit option and expanding its scope from simple commands to
all commands.

The (( command returns 1 if the expression evaluates to 0.  When `level' is
0, level++ returns a 0 value, and (( returns a status of 1.
  

That doesn't explain why those not using posix mode should suffer the
arbitrary added incompatibility with previous code.

POSIX was meant to describe existing code -- not cause incompatibilities 
with

old or current code.

POSIX disbanded and the name has changed hands to be run by people
unassociated with the original POSIX charter -- who created a different
charter.


It would have been nice if the non-posix change would have stayed
compatible with previous versions -- as it was useful in previous verstions
where "-e" could cause a script to exit early if you didn't
remember to check output of every simple command.

If you are writing complex commands, you are already using the
conditional features error code handling.

Calculations shouldn't ever trigger "-e" except for things like
division by 0 (which doesn't trigger it, as the calculation dies
before an return value can be calculated); it's counter-intuitive.

Note, I am not saying ((0)) should return non-zero status, just that it
shouldn't invoke "-e" handling in non-posix mode -- compatible with 
historical

usage.

Re: Intriguing error with arithmetic evaluation

[Greg Wooledge]

On Mon, Aug 15, 2016 at 03:15:13AM -0700, L. A. Walsh wrote:
> Calculations shouldn't ever trigger "-e" except for things like
> division by 0 (which doesn't trigger it, as the calculation dies
> before an return value can be calculated); it's counter-intuitive.

You may wish as hard as you like, but wishing will not change reality.
The reality is that set -e is worse than useless rubbish.  It is
deceptive.  It is a trap for the unwary.  It makes you THINK you're using
some sophisticated advanced scripting language with exception handling,
but you are NOT.  You are using a horrible duct-tape hack from the
mid-1970s.

The sooner you acknowledge that set -e is NOT intended for use in new
scripts, but instead is ONLY provided to make those old mid-1970s scripts
continue to "run" the same way today as they did back then, the better
off you will be.

Potential buffer under-run in shell_execve()

[John E. Malmberg]

Hello,

In Bash 4.3.42:

In execute_cmd/shell_execve(), if HAVE_BASH_BANG_EXEC is defined, the 
macro READ_SAMPLE_BUF has the potential to set sample_len to -1.


#if defined (HAVE_HASH_BANG_EXEC)
  READ_SAMPLE_BUF (command, sample, sample_len);
  sample[sample_len - 1] = '\0';

This would cause sample[-2] to be set to 0.  Most likely it would set 
part of fd to 0, but all that depends on the compiler.


Since fd is not in use at this point, the under run would not be noticed.

Regards,
-John