varenv3.sub fails on some systems some of the time.
Hi, When we run the bash unittests on some system we occasionally get a error in the varenv3.sub script. ./varenv3.sub: cannot open named pipe /tmp/bash_tests.8150/sh-np-5140328 for writing: No such file or directory ./varenv3.sub: line 30: /tmp/bash_tests.8150/sh-np-843885584: No such file or directory We cross compile bash for our system with: ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-pc-linux-gnu --libdir=/lib64 --prefix=/ --disable-nls ac_cv_func_mmap_fixed_mapped=yes gt_cv_int_divbyzero_sigfpe=yes ac_cv_func_strcoll_works=yes bash_cv_func_ctype_nonascii=no bash_cv_dup2_broken=no bash_cv_pgrp_pipe=no bash_cv_sys_siglist=no bash_cv_decl_under_sys_siglist=yes bash_cv_under_sys_siglist=yes bash_cv_opendir_not_robust=no bash_cv_ulimit_maxfds=yes bash_cv_getenv_redef=yes bash_cv_getcwd_malloc=yes bash_cv_func_sigsetjmp=present bash_cv_func_strcoll_broken=no bash_cv_printf_a_format=yes bash_cv_must_reinstall_sighandlers=no bash_cv_job_control_missing=present bash_cv_sys_named_pipes=present bash_cv_wcontinued_broken=no bash_cv_unusable_rtsigs=no bash_cv_dev_fd=absent bash_cv_dev_stdin=absent bash_cv_mail_dir=/dev/null GCC 4.8.2, glibc 2.18, seen on kernels 3.14.8 and 3.16.6 I'm hoping someone can help me narrow down the issue to find out what we are doing wrong. The problem seems to have been there since we upgraded to bash 4.3. Happy to give more information and try things out. Kind Regards Scott.
Re: varenv3.sub fails on some systems some of the time.
On Fri, Feb 20, 2015 at 09:08:30AM -0500, Chet Ramey wrote: On 2/20/15 6:56 AM, Scott wrote: Hi, When we run the bash unittests on some system we occasionally get a error in the varenv3.sub script. ./varenv3.sub: cannot open named pipe /tmp/bash_tests.8150/sh-np-5140328 for writing: No such file or directory ./varenv3.sub: line 30: /tmp/bash_tests.8150/sh-np-843885584: No such file or directory Does the directory (which I assume is $TMPDIR) exist? Yeah, directory exists which is why it works some of the time. I can reproduce the error with chmod u+x varenv3.sub; while ./varenv3.sub ; do sleep 0.1; done with default TMPDIR. HTH. Scott. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Brace expansion infinite loop, memory corruption, and other bugs.
A week or so ago I submitted a bug report using the bashbug command
that involved some
overflow issues with braces.c on OpenSUSE12.1 X86_64. Browsing the
patches, I got
the impression that braces.c hasn't been modified since the original
4.2 release, so the
same bugs should exist in the most recent version.
I also submitted potential fixes for the issues. I noticed that the
code in the patch I
submitted was forgetting to set errno = 0 before calling strtoimax.
Therefore I thought I
might as well send a slightly updated patch, which is a bit neater and
at least doesn't have
that particular bug in it.
Regards,
Scott.
--PREVIOUS MESSAGE FOR
REFERENCE
From: scotty.mcmil...@gmail.com
To: bug-bash@gnu.org
Subject: Brace expansion infinite loop, memory corruption, and other bugs.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g
-std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum
-Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe
-fprofile-use
uname output: Linux wks-smcmillan 3.1.10-1.9-desktop #1 SMP PREEMPT Thu Apr 5
18:48:38 UTC 2012 (4a97ec8) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
The errors are all to do with brace expansion in braces.c.
1) echo {9223372036854775806..9223372036854775807} was getting an
infinite loop (or crash with memory corruption or seg fault). The
error was in the mkseq function, because the increment of n done
before checking the loop termination condition was susceptible to
incidences of undefined signed integer overflow. This is fixed in the
patch below.
2) The rhs value and any user-specified increment value were always
clamped to the valid range while the sequence would refuse to expand
if lhs was out of range. This is because strtoimax clamps on
under/overflow and sets errno, but errno was only getting checked
for lhs (inside the legal_number function). expand_seqterm has been
changed in the patch below so that errno is checked after using
strtoimax to read the rhs and incr values. This gives more correct
and consistent behaviour.
3) The incr value was an int but was getting read using strtoimax, so
values beyond the range of an int were getting truncated. incr has
been changed to intmax_t in the patch below to fix this problem.
4) -incr in mkseq must be valid since the sign is switched depending on
the order of start and end. There was potential undefined behaviour
where it was equal to INTMAX_MIN. expand_seqterm now guarantees -incr
will be valid in the patch below.
5) echo {0..9223372036854775807} was getting a segmentation fault due
to overflow calculating the result size in mkseq. This is because the
result size calculated in mkseq is an int (necessarily, since
strvec_create takes an int as an argument), and because the wrong
absolute value function was getting used (abs instead of imaxabs).
After applying the patch below, expand_seqterm makes extra guarantees
on the end and start values passed to mkseq such that no overflow
will occur during the calculation and the result will not overflow
int. This means that the example input given would fail to expand.
Input such as {0..2147483645} will likely give an out of memory
error, which is preferable to segmentation faults or corrupted memory.
Repeat-By:
1) echo {9223372036854775806..9223372036854775807}
2) echo {9223372036854775806..9223372036854775808} (note second value
is more than INTMAX_MAX, but the output before applying the patch
is as if it were equal to INTMAX_MAX).
3) echo {0..10..9223372036854775807}.
4) Self-evident from code, -INTMAX_MIN is not valid.
5) echo {0..9223372036854775807}
Fix:
A patch to apply to braces.c to fix the issues mentioned above has been
pasted in below. The fixes are:
1) Check for overflow before incrementing in the loop in mkseq.
2) Check errno after strtoimax when reading the rhs and incr values
in expand_seqterm.
3) incr in expand_seqterm and mkseq is now intmax_t.
4) expand_seqterm verifi
error in math args?
I'm running Fedora core 3 on an Athlon, and I get the following problem: I get an error when running: echo $(( 008 / 2 )) In my script, however, I'm passing the value as a variable. when it gets to 008, I get an error. see below for my version and such: [EMAIL PROTECTED] complex]$ echo $(( 001 / 2 )) 0 [EMAIL PROTECTED] complex]$ echo $(( 002 / 2 )) 1 [EMAIL PROTECTED] complex]$ echo $(( 003 / 2 )) 1 [EMAIL PROTECTED] complex]$ echo $(( 004 / 2 )) 2 [EMAIL PROTECTED] complex]$ echo $(( 005 / 2 )) 2 [EMAIL PROTECTED] complex]$ echo $(( 006 / 2 )) 3 [EMAIL PROTECTED] complex]$ echo $(( 007 / 2 )) 3 [EMAIL PROTECTED] complex]$ echo $(( 008 / 2 )) -bash: 008: value too great for base (error token is "008") [EMAIL PROTECTED] complex]$ echo $(( 009 / 2 )) -bash: 009: value too great for base (error token is "009") [EMAIL PROTECTED] complex]$ echo $(( 0010 / 2 )) 4 [EMAIL PROTECTED] complex]$ echo $(( 008 / 2 )) -bash: 008: value too great for base (error token is "008") [EMAIL PROTECTED] complex]$ echo $SHELL /bin/bash [EMAIL PROTECTED] complex]$ rpm -q bash bash-3.0-18 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
MacOS X 10.4.10 and Bash 3.2
After running /configure --exec-prefix=/bin (also tried --prefix=/bin), make succeeds, but sudo make install fails: ... fi /usr/bin/install -c -m 0755 bash /bin/bin/bash /usr/bin/install -c -m 0555 bashbug /bin/bin/bashbug ( cd ./doc ; make \ man1dir=/usr/local/man/man1 man1ext=.1 \ man3dir=/usr/local/man/man3 man3ext=.3 \ infodir=/usr/local/info htmldir= DESTDIR= install ) /bin/sh ../support/mkinstalldirs /usr/local/man/man1 /bin/sh ../support/mkinstalldirs /usr/local/info if test -n "" ; then \ /bin/sh ../support/mkinstalldirs ; \ fi /usr/bin/install -c -m 644 ./bash.1 /usr/local/man/man1/bash.1 /usr/bin/install -c -m 644 ./bashbug.1 /usr/local/man/man1/bashbug.1 /usr/bin/install -c -m 644 ./bash.info /usr/local/info/bash.info if /bin/sh -c 'install-info --version' >/dev/null 2>&1; then \ install-info --dir-file=/usr/local/info/dir /usr/local/info/bash.info; \ else true; fi if test -n "" ; then \ /usr/bin/install -c -m 644 ./bash.html ; \ /usr/bin/install -c -m 644 ./bashref.html ; \ fi ( cd ./builtins ; make DESTDIR= install ) make[1]: Nothing to be done for `install'. ( cd ./po/ ; make DESTDIR= install ) test -z "[EMAIL PROTECTED] [EMAIL PROTECTED] ru.gmo" || make [EMAIL PROTECTED] [EMAIL PROTECTED] ru.gmo make[2]: [EMAIL PROTECTED]' is up to date. make[2]: [EMAIL PROTECTED]' is up to date. rm -f ru.gmo && : -c --statistics -o ru.gmo ru.po mv: rename t-ru.gmo to ru.gmo: No such file or directory make[2]: *** [ru.gmo] Error 1 make[1]: *** [stamp-po] Error 2 make: [install] Error 2 (ignored) ... Notice how it is sticking an extra "/bin/" in there (third and fourth lines down). Does this appear to be a bug? I've read everything I can think of in your docs, and also checked the web - appears not too many people have considered upgrading their shell. Host Info: $ uname -a Darwin Vortex.fidnet.com. 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Inconsistent regex matching with =~ between bash 3.1 and 3.2
Hi, all. I hope this report is of some use -- I'm pretty inexperienced
at GNU/Linux and Bash so I'm afraid this is going to sound horribly
amateurish. But I think I've found something for you. (Or I'm simply
about to demonstrate my crude understanding of regular expressions.)
I realize that regex handling has changed for the =~ operator from 3.1
to 3.2, and I'm trying to get my head around this while fixing a script
that has broken in 3.2. I studied this thread:
http://www.nabble.com/Conditional-Regexp-matching-problem-in-3.2-t3040946.html
And other pages and think I understand how I'm supposed to do things in
3.2, and can make my script work in 3.2. I'd like to make it be
backwards compatible for 3.1, but I get different results for the
example shown below (and errors on a variation).
In Ubuntu 7.04, $BASH_VERSION 3.2.13(1)-release, I try:
V="one/two"
[[ ! $V =~ ^\.*/ ]] && echo not
And get "not", as expected. (The first part is true.)
In Ubuntu 6.10, $BASH_VERSION 3.1.17(1)-release:
The first part doesn't evaluate as true, so no output.
And this comes out as true:
[[ $V =~ ^\.*/ ]]
So, either my regex is all wrong (I'm trying to match from a dot at the
start of the string up to the last forward slash), or might there be a
problem with this 3.1 version of bash? Or door #3?
3.1 works as I expect if I try ^\./ as the regex (string starting with
dot slash). (That is, it matches with ! for "one/two".)
Finally!
The following works in 3.2 (produces "yes" for "./one/two"), but gets an
error in 3.1:
[[ $V =~ (^\.*/) ]] && echo yes
unexpected argument `(' to conditional binary operator
syntax error near `(^'
Please let me know if more info would help. Again, I hope this is
helpful, or at least isn't extremely annoying, and I apologize if it
isn't/is.
Scott
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Inconsistent regex matching with =~ between bash 3.1 and 3.2
Paul Jarc spake thusly on 07/11/2007 12:10 PM: Scott Carpenter <[EMAIL PROTECTED]> wrote: V="one/two" [[ ! $V =~ ^\.*/ ]] && echo not 3.1 will remove the backslash as part of basic string parsing, just as if this were not part of a [[ command, while 3.2 handles the arguments for [[ specially, and will keep the backslash as part of the regexp. This will work in both versions: pattern='^\.*/' [[ ! $V =~ $pattern ]] && echo not paul Thanks, Paul (and Chet for also responding). I had seen hints about using a variable but when I tried before posting my question I must have used double quotes or no quotes, which didn't work. I tried with single quotes now and works fine, along with parentheses to get BASH_REMATCH: '(^\.*/)' I really appreciate your guys's patience in answering this newbs question, especially for something that must be an Extreme FAQ by now with the version change. Keep up the great work -- as an escapee from the Windows prison camp, I'm enjoying using and learning more about bash. Scott ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
error with ' in command substitution
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux brickies 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 13 Release Status: release Description: #= test.sh = x=$(cat <<"EOF" bad' syntax EOF ) #=== end test.sh === $ bash test.sh test.sh: line 2: unexpected EOF while looking for matching `'' test.sh: line 6: syntax error: unexpected end of file Above, bash errors on the single ' in "bad'". The above syntax works in on my version of dash (0.5.3-5ubuntu2) and the version of busybox ash that I tested (1.1.3). Using the backtick operator works on my version of bash, and a version 2.05b.0 that I tested. backtick does not work on 3.1.17 (sles 10) I actually see the same behavior as this version of bash on ksh from AIX 5.3.0.0. There, ksh works with `` bug fails with $(). So, I'm not 100% certain what the "correct" behavior is, but it certainly seems like this should work. Repeat-By: printf "%s\n%s\n%s\n%s\n" \ 'x=$(cat <<"EOF"' "bad' syntax" 'EOF' ')' > test.sh bash test.sh printf "%s\n%s\n%s\n%s\n" \ 'x=`cat <<"EOF"' "bad' syntax" 'EOF' '`' > test.sh
`read' builtin does not take last record without trailing delimiter
Bash does not seem to take the last record if it has no
trailing delimiter:
$ echo "0 1 2^3 4 5^6 7 8" |
while read -a array -d ^
do echo $array
done
0 3
In this sense it does not behave like awk:
$ echo "0 1 2^3 4 5^6 7 8" |
awk -v RS=^ '{print $1}'
0 3 6
This behavior is counter-intuitive. It just throws away the
last line and it's never even put into the array. I think
the whole intention of using read to split lines by
delimiter is always to read the last line even though it has
a trailing null or newline instead of a delimiter, just like
awk does.
IMO this is a bug but I'm sure this behavior is known and I
am wondering at its rationalization? I don't see any
arguments about it in the archives, this is just accepted?
It seems silly for a script to always have to take care to
add a delimiter even if the input doesn't have one, as is
extremely common (perhaps even universal). At the very
least I think an option should be present to turn on this
behavior for the builtin, because I can see some cases where
one *would* want the behavior as implemented as well.
What do people think of this?
Thanks.
--
Scott
load small history file after append breaks further appending
-l $HISTFILE 3 /home/test/.bash_history $ cp $HISTFILE $HISTFILE.new $ history -a $ wc -l $HISTFILE 6 /home/test/.bash_history $ history -cr $HISTFILE.new $ HISTFILE=$HISTFILE.new $ test 1 $ test 2 $ test 3 $ history -a $ wc -l $HISTFILE 10 /home/test/.bash_history.new # this time it appended!! (Note that I used control-d to logout, that's why it was not saving the `logout' in history.) ... I believe this shows the bug. I suggest zeroing `history_lines_after_session' upon "history -c" OR having `force_append_history' cause it to do just that in `maybe_append_history()' in addition to `maybe_save_history()' as it does already. Please keep me copied as I am not on the list. Thanks. -- Scott
Bash 5 increase in RAM from loop with many interations that append to file
The following example uses more peak RAM on new bash versions than old versions:
for i in {1..100}; do
echo "${i}" >> example.txt
done
By measuring peak memory usage with time (/usr/bin/time -f "%E %P %M"),
I get that newer versions of Bash use about 284M, where older versions
use about 191M.
Is this perceived increase in memory usage worth looking more into or is
it intended?
I tried to bisect but I'm not sure the result is useful. I got the following:
d233b485e83c3a784b803fb894280773f16f2deb is the first bad commit
commit d233b485e83c3a784b803fb894280773f16f2deb
Author: Chet Ramey
Date: Mon Jan 7 09:27:52 2019 -0500
bash-5.0 distribution sources and documentation
Thank you to Chet and to everyone for their time working on Bash!
Scott
Re: Bash 5 increase in RAM from loop with many interations that append to file
On Tue, Oct 27, 2020 at 08:54:37PM +0900, Koichi Murase wrote: > > I tried to bisect but I'm not sure the result is useful. I got the > > following: > > > > d233b485e83c3a784b803fb894280773f16f2deb is the first bad commit > > commit d233b485e83c3a784b803fb894280773f16f2deb > > Author: Chet Ramey > > Date: Mon Jan 7 09:27:52 2019 -0500 > > > > bash-5.0 distribution sources and documentation > > FWIW, on which branch did you performed bisect? The above commit is > from the branch of distribution. You can perform bisect against > `devel' branch, for example, between 118fb670..5cc55f2f. > > The Bash source is not really managed by the version control system in > a usual sense, but the repository is just a sequence of snapshots. So, > you can only narrow down to a snapshot of some day, but it will become > easier to identify the corresponding changesets. Thank you for the explanation, Koichi. I thought I had bisected on devel but perhaps I did something wrong. I can attempt another bisect at some point in the future, but these days it is very difficult for me to find time. Thanks for your quick reply! Scott
Re: Bash 5 increase in RAM from loop with many interations that append to file
On Tue, Oct 27, 2020 at 09:40:53AM -0400, Chet Ramey wrote:
> On 10/27/20 12:11 AM, Scott Kostyshak wrote:
> > The following example uses more peak RAM on new bash versions than old
> > versions:
> >
> > for i in {1..100}; do
> > echo "${i}" >> example.txt
> > done
> >
> > By measuring peak memory usage with time (/usr/bin/time -f "%E %P %M"),
> > I get that newer versions of Bash use about 284M, where older versions
> > use about 191M.
> >
> > Is this perceived increase in memory usage worth looking more into or is
> > it intended?
>
> My guess is that the huge list that results from the brace expansion caused
> the bash malloc to cross over into a larger memory bin because of unrelated
> memory allocation patterns that changed between bash versions. Once you
> allocate that much memory, a binary bin allocation method is going to waste
> some. In bash-5.0, that large allocation is going to use mmap, which adds
> some overhead of its own.
>
> If you can use valgrind or a similar tool to identify a memory leak, that
> would be useful.
Thanks for the explanation, Chet. I would normally jump at the chance to help
out because I enjoy digging into things like this, but these days I just can't
find the time. I will come back to this at some point, but possibly not for a
while. I'm sorry about that.
Thanks again for all of your work on Bash!
Scott
Minor Bash typo *BUG*
While compiling Bash, I couldn't help but notice that all over GNU's website it is spelled with a capital B. However, when I tried to compile Bash, I noticed a message that said "GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)" in a box surrounded by stars. Why is the B not capitalized here? Also, I'm not sure if this is of any relevance, but if you go to http://www.gnu.org/software/bash/ and scroll down to Mailing Lists, it says "To report bugs or to discus most aspects of developing bash..." and I see two problems with this. An S was forgotten in discuss and the B was not capitalized in Bash in this instance. I think that the spelling of Bash needs to be a little more, you know, standardized.
[ANN] MPI-Bash
(Perhaps this doesn't quite fit in bug-bash, but help-bash doesn't seem like the right spot, either.) In case anyone here is interested in writing massively parallel bash scripts, I hereby present MPI-Bash, a set of loadable builtins for bash that let you use the Message Passing Interface (MPI) to communicate across a cluster network. There's also support for the Libcircle distributed-queueing system for easy task distribution. Here's the MPI-Bash URL: https://github.com/losalamos/MPI-Bash So far, I've used MPI-Bash to wrap the cp, tar, and xz commands into parallel versions that run pretty fast on a parallel filesystem. Enjoy, -- Scott
Second trap invocation is ignored?
Hi, I don't understand the behavior of the trap command... echo ' trap "echo $1" DEBUG ' > ./trapcmd source ./trapcmd first source ./trapcmd second I would expect the debug trap to now be 'echo second'. However, it's still 'echo first' (full output below). Why is the second invocation ignored? Maybe a bug? I see this behavior on 3.2.57 and 4.2.45. Thanks, - Scott Example run: ~$echo 'trap "echo $1" DEBUG' > trapcmd ~$source ./trapcmd first first first ~$source ./trapcmd second first first first ~$ trap -p first trap -- 'echo first' DEBUG first first ~$
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 6:10 AM, Eduardo A. Bustamante López wrote: > Read about set -T in the manual. Hi, I did, over and over. :) I didn't see anything about -T being unnecessary the first time you set a trap from a sourced script, but being required every time thereafter. (quick parentheses: I'm not quite sure if sourcing a file is supposed to share ALL script contexts, or be more like calling a function. If the former, -T would never be required, and if the latter, -T would always be required. Just curious, is this documented anywhere?) > Also, you have an error in your trap > definition. The $1 inside "..." will expand at *definition* time, not when the > trap is executed. See: But I want it to expand at definition time. That makes it easy to see if the trap call worked or not. Here's the bug with explicit expansion: echo "trap 'echo first' DEBUG" > script1 echo "trap 'echo second' DEBUG" > script2 . ./script1 . ./script2 I would expect the trap calls in script1 and script2 to behave identically. Instead, script1's trap is set, but script2's trap is ignored. Thanks for the reply. - Scott
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 5:38 AM, Greg Wooledge wrote: > Without the source shenanigans, it works: > > imadev:~$ trap 'echo first' DEBUG > imadev:~$ echo hi > first > hi > imadev:~$ trap 'echo second' DEBUG > first > imadev:~$ echo hi > second > hi Absolutely right, and I should have included that in my bug report. That doesn't really help my case though. Well, I could have my script echo a trap command to the console and ask the user to re-type it. :) > As soon as I try your source trick, things start to break down: > > imadev:~$ echo 'trap "echo $1" DEBUG' > foo > second > imadev:~$ source ./foo one > second > imadev:~$ echo hi > second > hi > > But if I clear the DEBUG trap first, then it starts to work: > > imadev:~$ trap - DEBUG > second > imadev:~$ echo hi > hi > imadev:~$ source ./foo one > imadev:~$ echo hi > one > hi Agreed. And clearing the debug trap from a script doesn't work: ~$ echo 'trap "echo $1" DEBUG' > foo ~$ echo 'trap - DEBUG' > unfoo ~$ source foo one one one ~$ source foo two one one one ~$ source unfoo one one one ~$ source foo three one one one ~$ $(cat unfoo) one ~$ ~$ source foo four four four > So, if there is a bug here, it's got something to do with setting traps > in a sourced file, when that type of trap is already set. (Also, I > didn't try with any other traps. Maybe it's specific to DEBUG.) Yep. I haven't tried with any traps other than DEBUG, just because that's the only trap my script needs. If the maintainers would like more information about affected traps, I'm happy to investigate. - Scott
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 8:04 AM, Eduardo A. Bustamante López wrote: > There is no bug. Simply, your expectations on when the DEBUG trap runs are > wrong. > > The `script2' I provided ran with set -T is the closest you'll get to what you > expect, but, since DEBUG runs *before* the source command, it'll not work as > you want. True, but that doesn't explain why the first sourced invocation succeeds, but all invocations thereafter fail. Is there a reason for this behavior? Why should a call to trap succeed or fail depending on whether the trap is already set or not? If that's expected behavior, I would certainly like to document it! Thanks, - Scott
Re: Second trap invocation is ignored?
On Fri, Apr 10, 2015 at 8:16 AM, Chet Ramey wrote: > On 4/6/15 11:58 AM, Greg Wooledge wrote: > > I'd be fine with that, but then why does "source ./foo" create a DEBUG > > trap at the global scope the *first* time? > > Because there's nothing to save and restore. Just curious: why not restore the state of emptiness that existed before? Why treat these two states differently? (presence of trap vs. absence of trap) Other than this minor question, your explanation makes total sense. Thanks Chet. - Scott
