Suggestion: Documentation: ulimit -f
Hi folks. Currently, the documentation (both, help-command and manpage) on ulimit -f says: "The maximum size of files created by the shell" which may make one think of, it only affects files that are created from the shell itself. Assuming -f works like it should work, a text like: "The maximum size of files created by the shell and its child processes" might be better. I know that the description of ulimit itself mentiones that. But the -f description is the only one that says "by the shell". Best regards, Jan -- Live as if your were to die tomorrow. Learn as if you were to live forever. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
BUG? Wrong BASH_LINENO for trap in compound command
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='/usr/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -g -O2
uname output: Linux Knoppix 2.6.12 #2 SMP Tue Aug 9 23:20:52 CEST 2005
i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
In the included script, BASH_LINENO[0] within trap is allways the
ending line
of the enclosing compound command, instead of the line which caused
the trap.
Is this the intended behaviour, and if yes, is there any way to know
within
the trap the linenumber which caused the trap?
Repeat-By:
Repeat by running this script.
echo $BASH_VERSION
mytrap() {
echo "ERR @ ${BASH_LINENO[0]}"
}
trap mytrap ERR
{
false # <-- I want this linenumber
true
} # <-- this line is reported
while true ; do
false # <-- I want this linenumber
true
break
done # <-- this line is reported
(
trap mytrap ERR
false # <-- I want this linenumber
true
) # <-- this line is reported
--
Markus Laire
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
* Ralf Wildenhues wrote on Tue, Mar 21, 2006 at 05:02:49PM CET: > FWIW, are there _any_ other shells that do not output \1 with > echo "\\1" > except for bash-3.0-with-xpg-echo? Ouch. Never mind that stupid question, please. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
completion lists directories in $PATH as commands
Retrying as this mail does not appear after 5 days Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-mandriva-linux-gnu' -DCONF_VENDOR='mandriva' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fomit-frame-pointer -march=i586 -mtune=pentiumpro -fasynchronous-unwind-tables uname output: Linux localhost 2.6.12-13mdk-i686-up-4GB #1 Mon Nov 21 18:31:00 CET 2005 i686 Intel(R) Pentium(R) M processor 1.60GHz unknown GNU/Linux Machine Type: i586-mandriva-linux-gnu Bash Version: 3.1 Patch Level: 7 Release Status: release Description: When some directories (or link to directories) are present in some directory listed in $PATH, they are returned as if they were commands. Repeat-By: # mkdir /usr/bin/foo # fo[TAB] -> will complete to "foo " Fix: Test if the file is a directory (or links to) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Fwd: Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)]
* Chet Ramey <[EMAIL PROTECTED]> [2006-03-05 12:38 -0500]: > This has been a known issue with bison-1.75 for over three years: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167635;archive=yes > http://lists.gnu.org/archive/html/bug-bash/2003-01/msg00061.html > http://lists.gnu.org/archive/html/bug-bash/2004-09/msg00118.html If it's a known issue, why does the configure script select the bison-1.75 instead of the working yacc? If this can't be changed easily, perhaps you can add a note in INSTALL or somewhere else, warning people to use bison-1.75. Thanks, Nicolas -- http://www.rachinsky.de/nicolas ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Henrik Nordstrom wrote: lör 2006-03-18 klockan 14:15 -0800 skrev Linda W: Bash added the "feature" to allow dropping of the leading "0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that most bash users run in a shell that has expansion turned off by default or this would have come up before. the xpg_echo bash option.. Lets see what this does to configure shall we.. oh, yes it fails miserably with this bash option set. please send this to the autoconf maintainers as well. Probably they can add a rule detecting this kind of systems and falling back on an alternative somewhat slower echo method.. Regards Henrik I believe bash is broken in regards to using "any" number after "\" as an octal value. The shell specifications require the leading zero for an octal constant and I don't think this problem would arise if that was fixed. I can forward the info to them anyway. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash 3.1 fails to build on AIX
Since compilation failed bashbug hasn't been installed, so I am having to guess what is wanted. Let me know if you need any more help. uname -a: AIX marvin 1 5 005A0E6C4C00 cc version: C for AIX Compiler, Version 6 CFLAGS=-O2 ./configure works fine make fails thus: ... cc -c -DHAVE_CONFIG_H -DSHELL -I. -I../.. -I../.. -I../../include -I../../lib -O2 tilde.c rm -f libtilde.a ar cr libtilde.a tilde.o test -n "ranlib" && ranlib libtilde.a make[1]: Leaving directory `/tmp/bash-3.1/lib/tilde' rm -f bash cc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/sh-O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -lcurses -lglob -ltilde lib/intl/libintl.a -liconv -ldl ld: 0711-317 ERROR: Undefined symbol: .isnan ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: *** [bash] Error 8 -Nigel ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash shell parser bug
Hello, I just found a bug that affects a number of shells (pressumably the code there is from the same roots) in the parser. The following code; l='eval "$l"' eval "$l" Which sets off an infinite recursion on 'eval', should result in an infinite loop to be terminated by INT (doesnt' work) or at least end gracefully with an error "bash: out of memory". Instead the system has to kill the shell process because of SEGV fault. I'm not familiar with bash internals but it looks to me like some sort of heap overflow problem. I traced the system calls using 'strace' and it is extending the data area with brk() by 4k a time until finally, pressumaby it just doesn't check the error from brk() not finding anymroe memory. bestwishes laura ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.1.011 escaped character error
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='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -g -march=i686 -pie -fpie uname output: Linux noname.nowhere.net 2.6.14-i865PERL-0.2 #1 SMP Fri Jan 27 18:40:14 CET 2006 i686 pentium4 i386 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.1 Patch Level: 11 Release Status: release Description: When IFS is "\n" a single n at the end of a line is dropped. i.e. the following does not work (at least on my machine(s)): while IFS="\n" read i; do echo $i; done abc abc abcn<- input abc <- output abcnn abcnn abcnnn abcnnn Best regards Mihai ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert: > Autoconf deals with shells that do not conform to XSI, and where the > results are implementation-defined if there's a backslash anywhere in > the string, so to some extent this point is moot for Autoconf (though > it's undeniably a portability problem, one that is documented in the > Autoconf manual under "Limitations of Builtins"). I thought so too, but in this case it is a autoconf 2.57 output which is failing, ending up with a lot of control characters instead of the expected sed backreferences.. The package in question is the Squid-3 development snapshots found at http://www.squid-cache.org/Versions/v3/HEAD/ The failure is seen at least in the cppunit subpackage called recursiverly from the main configure. Maybe in the main package as well. My access to systems with a shell behaving like this is somewhat limited so I have not produced a smaller test case for the problem. So far Linda is the only one reporting this issue to us, but shells behaving like this is not very wide spread in our community of Squid-3 snapshot/development release users.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Possible race in bash signal handling?
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc-34 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux murphy 2.6.12.3-rock #1 SMP Sun Aug 7 15:13:36 CEST 2005 i686 unknown unknown GNU/Linux Machine Type: i386-unknown-linux-gnu Bash Version: 2.05b Patch Level: 0 Release Status: release Description: One of my bash scripts got killed with a sig11. I was curious so I made a stack backtrace: (gdb) bt #0 0x0806da71 in kill_current_pipeline () #1 0x0806eb6a in kill_pid () #2 0x0806efd1 in kill_pid () #3 #4 0x4007d6f6 in free () from /lib/libc.so.6 #5 0x0806d7cc in save_pipeline () #6 0x0806d816 in cleanup_the_pipeline () #7 0xbfed2dac in ?? () #8 0x0807351f in command_substitute () #9 0x0807351f in command_substitute () ... My bash has the following patches applied: http://www.rocklinux.net/svn/rock-linux/trunk/package/base/bash/bash2/ Is it possible that there is a race condition when a certain signal (maybe SIGCHLD? - I'm not sure how to figure out the cought signal from stack frame 3) is interrupting the cleanup_the_pipeline() codepath? Repeat-By: I'd guess that would be pretty hard reproduce. It happened to me while executing a script that never showed this problem before. It is a more sophisticated script thought: http://www.rocklinux.net/svn/rock-linux/trunk/scripts/Download The last output seen on the terminal was produced by the echo "bzip'ing + cksum-test: $gzfile" in line 529 in download_file() called by all() (line 933). There are a lot of pipes, command substitutes and '<( .. )' constructs in the script. But I'm afraid that the script won't help you much tracing the issue.. -- L I N : B I T ___ ___ __ _ |_ | The OSS cluster synchronization tool for / __(_-http://oss.linbit.com/csync2/ ] --- /___/ "You can now flame me, I am full of love, and will ignore any insults, because that is how good my Gnus filter is." -- MiguelDeIcaza ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [squid-users] Re: my "CPPUNIT" is "broken"... ;-) ?
lör 2006-03-18 klockan 14:15 -0800 skrev Linda W: > Bash added the "feature" to allow dropping of the leading > "0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that > most bash users run in a shell that has expansion turned off by default or > this would have come up before. the xpg_echo bash option.. Lets see what this does to configure shall we.. oh, yes it fails miserably with this bash option set. please send this to the autoconf maintainers as well. Probably they can add a rule detecting this kind of systems and falling back on an alternative somewhat slower echo method.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [squid-users] Re: my "CPPUNIT" is "broken"... ;-) ?
Henrik Nordstrom wrote: fre 2006-03-17 klockan 19:31 -0800 skrev Linda W: Mystery solved. My shell _expanded_ control sequences by default in echo. (echo "\1" -> becomes "echo ^A"). Apparently there are literals in the configure script like "\\1" "\\2" that were trying to echo a literal '\1' into a "sed" script. Instead it was echoed in as a control-A. Hmm.. so you have replaced /bin/sh with something else than a UNIX shell? Or was it you /bin/echo being different? --- It was the builtin on "bash" compiled to adhere with the System-V standard, and some implementations of ksh and other unix implementations. See "http://ou800doc.caldera.com/en/man/html.1/echo.1.html";. Am I misremembering, aren't their systems were expanded echo is the default? If so then the GNU autoconf people have not run into it yet.. --- Well that could be because the feature was "extended" in BASH. The original standard requires "\0" before an octal number consisting of 1-3 digits. This required \0 to invoke the special decoding. Bash added the "feature" to allow dropping of the leading "0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that most bash users run in a shell that has expansion turned off by default or this would have come up before. I am leaning toward thinking this is a case of Bash implementing an incompatible and conflicting extension (by allowing the dropping of the leading 0 of an octal sequence). Good you found what it was, and a way around the problem. Even better if you would enlighten us what it was you were using causing the problem, and how you worked around it. --- For now, I disabled expansion, since it isn't compatible (as you note with existing scripts (like autoconf). Meanwhile, I've submitted a suggestion to go back to requiring the full prefix "\0" before possible interpretation as octal. It seems cleanest if they require "\0" before either an octal or hex encoding, with hex using \0xH[H] and octal using \0N[N[N]]. Linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
* Ralf Wildenhues wrote on Tue, Mar 21, 2006 at 05:02:49PM CET: > > The issue is not in Autoconf, but in the macro AC_CREATE_PREFIX_CONFIG_H [...] > I will look into that, and post an update. To finish this up for squid: Please install the patches below (it'd be nice if you could feed back the cppunit related ones to their upstream), install the file lib/cppunit-1.10.0/config/ax_prefix_config_h.m4 from http://autoconf-archive.cryp.to/ax_prefix_config_h.html (you can remove ac_create_prefix_config_h.m4 then), and rerun the autotools. The first patch is an unrelated bugfix. The second one gets cppunit in line with better Autoconf style (portable to older versions, but necessary for newer ones), and makes use of AX_PREFIX_CONFIG_H. I will followup (on bug-autoconf only) with a bug in CVS Autoconf that I just discovered, that led me to thinking the AX_PREFIX_CONFIG_H macro was broken.. Cheers, Ralf * configure.in: Call AM_PROG_CC_C_O right after AC_PROG_CC. Do not call AC_PROG_CC again. Index: configure.in === RCS file: /squid/squid3/configure.in,v retrieving revision 1.401 diff -u -r1.401 configure.in --- configure.in20 Mar 2006 23:38:23 - 1.401 +++ configure.in21 Mar 2006 16:27:38 - @@ -26,9 +26,9 @@ dnl Check for GNU cc AC_PROG_CC +AM_PROG_CC_C_O AC_LANG_C AC_PROG_CXX -AM_PROG_CC_C_O AC_CANONICAL_HOST AC_DISABLE_SHARED AC_PROG_LIBTOOL @@ -99,9 +99,6 @@ AC_DEFINE_UNQUOTED(SQUID_CONFIGURE_OPTIONS, "$ac_configure_args", [configure command line used to configure Squid]) -dnl Check for GNU cc -AC_PROG_CC - dnl Gerben Wierda <[EMAIL PROTECTED]> case "$host" in mab-next-nextstep3) * configure.in: Use AC_CONFIG_FILES to list config files. Use AX_PREFIX_CONFIG_H instead of AC_CREATE_PREFIX_CONFIG_H. Index: lib/cppunit-1.10.0/configure.in === RCS file: /squid/squid3/lib/cppunit-1.10.0/configure.in,v retrieving revision 1.2 diff -u -r1.2 configure.in --- lib/cppunit-1.10.0/configure.in 27 Sep 2004 17:32:39 - 1.2 +++ lib/cppunit-1.10.0/configure.in 21 Mar 2006 16:21:13 - @@ -117,8 +117,7 @@ #AC_DEFINE_UNQUOTED(NO_TESTPLUGIN,$testplugin_val, #[defined to disable TestPlugIn]) - -AC_OUTPUT([ +AC_CONFIG_FILES([ Makefile cppunit.spec cppunit-config @@ -147,5 +146,7 @@ examples/money/Makefile ],[chmod a+x cppunit-config]) -AC_CREATE_PREFIX_CONFIG_H([include/cppunit/config-auto.h], +AX_PREFIX_CONFIG_H([include/cppunit/config-auto.h], $PACKAGE, [config/config.h]) + +AC_OUTPUT ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
tis 2006-03-21 klockan 17:32 +0100 skrev Ralf Wildenhues: > To finish this up for squid: Please install the patches below (it'd be > nice if you could feed back the cppunit related ones to their upstream), > install the file lib/cppunit-1.10.0/config/ax_prefix_config_h.m4 from > http://autoconf-archive.cryp.to/ax_prefix_config_h.html (you can remove > ac_create_prefix_config_h.m4 then), and rerun the autotools. > > The first patch is an unrelated bugfix. The second one gets cppunit in > line with better Autoconf style (portable to older versions, but > necessary for newer ones), and makes use of AX_PREFIX_CONFIG_H. Many thanks! Your updates have been applied. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.1.011 escaped character error
Mihai Barbos <[EMAIL PROTECTED]> writes: > When IFS is "\n" a single n at the end of a line is dropped. IFS="\n" is equivalent to IFS=n If you want to set IFS to a single newline character use either IFS=$'\n' or IFS=" " Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Linda W <[EMAIL PROTECTED]> writes: > I believe bash is broken in regards to using "any" number after > "\" as an octal value. The shell specifications require the leading > zero for an octal constant The specification does not _require_ it, it allows it. Any other use of the backslash results in implementation defined behaviour. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Possible race in bash signal handling?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 3/14/2006 4:26 AM: > > Bash Version: 2.05b > Patch Level: 0 Consider upgrading. Bash is now at 3.1 patch level 14. Perhaps your problem has already been identified and fixed in subsequent releases. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEIpjK84KuGfSFAYARAk1TAJ4mGAuitHlUg4epvrb68Nx+Z0wqXwCeJwN7 RqmTWGI8ZDSthqV5TsEzRfQ= =boMT -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Keybinding "yank 0th arg", "delete backward argument"
I would find the following two functions useful in bash command line editing; is it possible to simulate them somehow with the current bash version, or would this have to be a new feature in a future version of bash? (1) yank 0th arg, similar to yank-last-arg, but copies the command part of the previous line into the current buffer. Example: The previous line was /usr/local/bin/perl myprog.pl then yank-0th-arg should insert /usr/local/bin/perl into the buffer. (2) delete-backward-argument, similar to delete-backward-word, but should delete everything to the left until the first white space. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Keybinding "yank 0th arg", "delete backward argument"
"Com MN PG P E B Consultant 3" <[EMAIL PROTECTED]> writes: > (1) yank 0th arg, similar to yank-last-arg, but copies the command part > of the previous line > into the current buffer. Example: The previous line was > > /usr/local/bin/perl myprog.pl > > then yank-0th-arg should insert /usr/local/bin/perl into the buffer. M-0 M-. (digit-argument yank-last-arg) > (2) delete-backward-argument, similar to delete-backward-word, but > should delete everything > to the left until the first white space. C-w (unix-word-rubout) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash-3.1 Official Patch 10 - UPDATED
On Fri, Mar 03, 2006 at 11:10:50AM -0500, Chet Ramey wrote: > Bash-Release: 3.1 > Patch-ID: bash31-010 > [...] > THIS IS AN UPDATED PATCH. [...] Uh. Why couldn't you just release a new patch on top of the old ones instead? Would have been less cumbersomely for build systems where the source and patch files are downloaded automatically and cached for later re-use. (I had to intervene and manually delete the old `bash31-010'.) Regards, Thomas ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Backquote Mystery
While hunting a bug in my script, I stumbled over an effect involving
the usage of
backquote and grep, which completely puzzles me. To reproduce the
effect, execute
first the following four commands, which create a small directory tree
in your
working directory and set the bash variable 'e':
mkdir -p dirx/sub/f
cd dirx
touch x
e=$('ls' *)
Wenn you now do echo $e, you should get the following output:
x sub: f
And here comes the mystery part. Execute the following two commands:
echo g|grep "$e"
echo g|grep "x sub: f"
Could some kind soul explain to me, why the first grep matches?
BTW, BASH_VERSION is "2.05b.0(1)-release"
Ronald
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: Backquote Mystery
> Try echo "$e". Then read about Word Splitting in the Bash manual. Good point. Since no word splitting occurs within "$e", it is expanded to a string containing newlines: $ echo $e # Expansion without quotes -> word splitting x sub: f $ echo "$e" # Expansion with quotes -> no word splitting x sub: f grep then matches the empty line. Indeed, one can reproduce this with a much simpler example: $ u=$(printf 'ab\n\ncd\n') $ echo xx|grep "$u" xx So we don't have a mystery here, but rather an undocumented feature of grep (or at least not documented in the man pages of *my* version of grep): If the pattern is a string containing newline characters, grep matches each of these lines in order to every line in the input file, until a match is found. Thank you for pointing me into the right direction. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Possible race in bash signal handling?
[EMAIL PROTECTED] wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Compiler: gcc-34 > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-unknown-linux-gnu' > -DCONF_VENDOR='unknown' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib > -g -O2 > uname output: Linux murphy 2.6.12.3-rock #1 SMP Sun Aug 7 15:13:36 CEST 2005 > i686 unknown unknown GNU/Linux > Machine Type: i386-unknown-linux-gnu > > Bash Version: 2.05b > Patch Level: 0 > Release Status: release > > Description: > One of my bash scripts got killed with a sig11. I was curious so I > made a stack backtrace: This particular problem was fixed in bash-3.1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash 3.1 fails to build on AIX
Nigel Horne wrote: > Since compilation failed bashbug hasn't been installed, so I am having to > guess what is wanted. Let me know if you need any more help. Does isinf appear in libc on AIX 5.1? How about isnan? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
