'set -e' and 'trap 0' togheter does not work as expected on syntax errors

2009-08-21 Thread Stefano Lattarini
I have the following scripts: $ cat nobug.sh trap 'e=$?; [ $e -gt 0 ] echo OK || echo BAD; exit $e' 0 # syntax error here true $ cat bug.sh set -e trap 'e=$?; [ $e -gt 0 ] echo OK || echo BAD; exit $e' 0 # syntax error here true I thought that when bash detect a syntax errors in

bug with 'set -e' + 'trap 0' + syntax error

2009-08-21 Thread Stefano Lattarini
I have the following scripts: $ cat nobug.sh trap 'e=$?; [ $e -gt 0 ] echo OK || echo BAD; exit $e' 0 # syntax error here true $ cat bug.sh set -e trap 'e=$?; [ $e -gt 0 ] echo OK || echo BAD; exit $e' 0 # syntax error here true I thought that when bash detect a syntax errors in a

Re: bug with 'set -e' + 'trap 0' + syntax error

2009-08-21 Thread Stefano Lattarini
Stefano Lattarini a écrit : I thought that when bash detect a syntax errors in a script, it would pass a $? != 0 to the code in the exit trap, regardless of whether `set -e' is active or not. [CUT] I think this can be classified as a bug in bash (in some situations, a very nasty

Re: 'set -e' and 'trap 0' togheter does not work as expected on syntax errors

2009-08-22 Thread Stefano Lattarini
At Saturday 22 August 2009, Chet Ramey chet.ra...@case.edu wrote: Stefano Lattarini wrote: I have the following scripts: [CUT] I thought that when bash detect a syntax errors in the script, it would pass a $? != 0 to the code in the exit trap, regardless of whether `set -e' is active

printf does not always display warning messages on write errors

2009-09-02 Thread Stefano Lattarini
Hi everybody. I found the following bug while running some of my bash scripts on GNU/Linux with stdout redirected to /dev/full, to see if write errors where correctly detected and reported. It turned out that, on write errors, the printf builtin correctly returns a non-zero status (thus my

Re: printf does not always display warning messages on write errors

2009-09-03 Thread Stefano Lattarini
At Thursday 03 September 2009, Chet Ramey chet.ra...@case.edu wrote: Thanks for the report. This will be fixed in the next version. Good! And thanks to you for your quick answers and your useful software. Chet Regards, Stefano

Re: bash 3.2.51, ERR traps and subshells

2010-06-22 Thread Stefano Lattarini
At Tuesday 22 June 2010, Andres P wrote: Bash 4.1 does not set the ERR trap: $ env -i HOME=$HOME TERM=$TERM bash3 \! set -o errexit set -o errtrace TRIGGERED_ERR() { return $?; } trap 'TRIGGERED_ERR' ERR set -o xtrace var=$(false) || true Here, the subshell has

Re: bash 3.2.51, ERR traps and subshells

2010-06-22 Thread Stefano Lattarini
At Tuesday 22 June 2010, Andres P wrote: On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: ++ false # Subshell false +++ TRIGGERED_ERR # Ignores outer || true No, it doesen't even see it; the script seen by the subshell consists just

Re: inconsistent exit status of ((count++))

2010-07-30 Thread Stefano Lattarini
At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect of: 1. `((EXPR))' returning a non-zero exit status iff EXPR evaluates to zero, and 2. `var++'

Re: inconsistent exit status of ((count++))

2010-07-30 Thread Stefano Lattarini
At Friday 30 July 2010, Andrew Benton wrote: On 30/07/10 19:55, Stefano Lattarini wrote: At Thursday 29 July 2010, Andrew Benton wrote: andy:~$ count=0 andy:~$ ((count++)) andy:~$ echo $? 1 andy:~$ ((count++)) andy:~$ echo $? 0 I don't think it's a bug, it's just an effect

Re: inconsistent exit status of ((count++))

2010-07-30 Thread Stefano Lattarini
At Friday 30 July 2010, Greg Wooledge wrote: On Fri, Jul 30, 2010 at 09:49:22PM +0200, Stefano Lattarini wrote: But then, maybe an exit status of `2' instead of `1' in case of errors in ((...)) would be helpful -- currently the exit status is still `1' also if a real error is present

Re: conditional aliases are broken

2011-08-18 Thread Stefano Lattarini
Hi Eric. On Thursday 18 August 2011, Eric Blake wrote: On 08/18/2011 08:44 AM, Eric Blake wrote: how do I write a function that would print the same as $ \ls | cat Useless use of cat. This can be done with \ls -1. f(){ for a in $@; do echo $a; done; } Or skip the loop altogether:

Re: conditional aliases are broken

2011-08-18 Thread Stefano Lattarini
On Thursday 18 August 2011, Stefano Lattarini wrote: Hi Eric. On Thursday 18 August 2011, Eric Blake wrote: On 08/18/2011 08:44 AM, Eric Blake wrote: how do I write a function that would print the same as $ \ls | cat Useless use of cat. This can be done with \ls -1. f

Re: exit status issue

2011-11-23 Thread Stefano Lattarini
On Wednesday 23 November 2011, Andreas Schwab wrote: Steven W. Orr ste...@syslang.net writes: I think we're beating this one to death, but I have point out that telling perl to run a print command whose output is redirected by bash is not the same as telling bash to run a builtin echo

Re: Bash git repository on savannah

2011-11-28 Thread Stefano Lattarini
Hello everybody. Just my 2 cents about this ... On Monday 28 November 2011, Chet Ramey wrote: On 11/28/11 4:48 AM, Roman Rakus wrote: On 11/28/2011 06:28 AM, Mike Frysinger wrote: I don't think I'll push every change to git as soon as it happens, but I'm thinking about fairly frequent

Re: bash 4.2 breaks source finding libs in lib/filename...

2012-03-01 Thread Stefano Lattarini
On 03/02/2012 02:50 AM, Chet Ramey wrote: On 2/29/12 2:42 PM, Eric Blake wrote: In the middle of the histrionics and gibberish, we have the nugget of an actual proposal (thanks, Eric): [to allow `.' to look anchored relative pathnames up in $PATH] About the best we can do is

Re: bash 4.2 breaks source finding libs in lib/filename...

2012-03-03 Thread Stefano Lattarini
On 03/03/2012 08:28 AM, Pierre Gaston wrote: On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini wrote: Or here is a what it sounds as a marginally better idea to me: Bash could start supporting a new environment variable like BASHLIB (a' la' PERL5LIB) or BASHPATH (a' la' PYTHONPATH) holding

Re: Determine if a file is a valid Bash script

2012-03-19 Thread Stefano Lattarini
On 03/19/2012 08:54 PM, Lane Schwartz wrote: Hi, If I have a file that contains a bash script, is there any straightforward way of determining whether that script can be parsed successfully as a Bash script, without actually running the file? Yes: the -n option. Simple examples: $ echo

Re: cd // produces unexpected results

2012-06-22 Thread Stefano Lattarini
On 06/22/2012 09:47 PM, Chet Ramey wrote: By accident I keyed in : cd // and noticed that my prompt included both slashes. Posix says shells have to leave two leading slashes in a pathname alone. Three or more can be collapsed to one, but two have to stay unchanged. This has come up

[PATCH 1/3] build: use configure.ac, not configure.in

2012-08-28 Thread Stefano Lattarini
/archive/html/automake-patches/2012-06/msg4.html Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- INSTALL | 4 ++-- MANIFEST | 2 +- Makefile.in | 4 ++-- configure.in = configure.ac | 0 doc

[PATCH 3/3] docs: regenerate text documentation (but not PDF, DVI nor PostScript)

2012-08-28 Thread Stefano Lattarini
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- doc/bash.html| 54 ++--- doc/bashref.html | 28 +++-- doc/bashref.info | 329 --- 3 files changed, 227 insertions(+), 184 deletions(-) diff --git a/doc/bash.html b/doc

documentation bug (uid resetting in posix mode)

2012-10-30 Thread Stefano Lattarini
From experimenting, I've found out that bash (4.2.20), when invoked as sh, doesn't reset the effective user id to the real user id, even if called *without* the '-p' option. This behaviour seems consistent with that of other POSIX shells like dash (0.5.7) and ksh (JM 93u+ 2012-02-29), so I

Re: documentation bug (uid resetting in posix mode)

2012-10-30 Thread Stefano Lattarini
On 10/30/2012 06:28 PM, Andreas Schwab wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: $ ./system-suid [8204] ruid = 1000, euid = 0, suid = 0 Looks like your /bin/sh is broken. How broken exactly? Honest question. Anyway, my /bin/sh is bash ... $ ls -l /bin/sh

Re: documentation bug (uid resetting in posix mode)

2012-10-30 Thread Stefano Lattarini
Hi Bob, thanks for the tips. However ... On 10/30/2012 07:37 PM, Bob Proulx wrote: Stefano Lattarini wrote: Anyway, my /bin/sh is bash ... $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh - bash I'm on Debian Unstable BTW (sorry for not specifying that earlier). Let me

Re: Question about the return value of 'local'

2012-12-14 Thread Stefano Lattarini
On 12/14/2012 06:07 PM, Bill Gradwohl wrote: I'm not trying to start a war, but ... Has anyone entertained the idea of getting rid of the man pages and the info system? Those are relics of the tty era. Don't make the error of confusing the texinfo system with just the info format. I, for

Re: Question about the return value of 'local'

2012-12-14 Thread Stefano Lattarini
On 12/14/2012 06:58 PM, Bill Gradwohl wrote: My point was to DESIGN for html and the rich environment it offers, not to try to convert a Model T into a Mercedes. I'm not wild about a wiki either, if its a free for all. If on the other hand, it is a submission platform that gets reviewed and

Re: weird problem -- path interpretted/eval'd as numeric expression

2013-03-29 Thread Stefano Lattarini
On 03/29/2013 12:57 PM, Greg Wooledge wrote: On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote: include was designed to search the path for functions that are relative paths. While the normal sourcepath allows searching for filenames on the search path, I don't believe (please

Regression in development version of bash w.r.t. associative hashes

2013-05-03 Thread Stefano Lattarini
[+cc bug-gnulib, see below for a reason] Minimal reproducer of the regression: $ cat foo.bash echo $BASH_VERSION declare -A hash echo ${hash[a/b]} echo $? $ /bin/bash foo.bash 4.2.45(1)-release 0 $ ~/bleeding/bin/bash foo.bash 4.3.0(1)-alpha foo.bash: line 3: a/b:

Development version of bash is very slow in running autoconf-generated scripts

2013-05-06 Thread Stefano Lattarini
Compared with Bash 4.2, the development version of bash is very slow in running autoconf-generated configure scripts (or, to be more precise, that's where I noticed the slowness; it might very well be more generalized, but I haven't checked for that). Some numbers: $ /bin/bash -c 'echo

Re: Development version of bash is very slow in running autoconf-generated scripts

2013-05-06 Thread Stefano Lattarini
On 05/06/2013 12:33 PM, Andreas Schwab wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: Four times slower, yikes. Any idea where these numbers might be coming from? Try building without debugging options (make DEUBG= MALLOC_DEBUG=) Thanks! This solved the issue (after s

Re: Regression in development version of bash w.r.t. associative hashes

2013-05-06 Thread Stefano Lattarini
On 05/06/2013 10:00 PM, Chet Ramey wrote: On 5/3/13 5:48 AM, Stefano Lattarini wrote: [+cc bug-gnulib, see below for a reason] Minimal reproducer of the regression: $ cat foo.bash echo $BASH_VERSION declare -A hash echo ${hash[a/b]} echo $? $ /bin/bash foo.bash 4.2.45(1