segfault
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-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables uname output: Linux windmill 3.5.1-1.fc17.i686.PAE #1 SMP Thu Aug 9 17:50:53 UTC 2012 i686 i686 i386 GNU/Linux Machine Type: i686-redhat-linux-gnu Bash Version: 4.2 Patch Level: 36 Release Status: release Description: segfaults on "while read -sN1 K; do echo $K; done" when baskslash and then enter taped twice Repeat-By: run this from command line or script, tap backlslash, then enter twice Additional info: excerptum from the log file when running the script rktest rktest[424]: segfault at 8 ip b7614ab6 sp bf856904 error 4 in libc-2.15.so[b7592000+1a8000]
Re: segfault
On 8/22/12 7:28 AM, arman...@gmail.com wrote:
> 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-redhat-linux-gnu'
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
> -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin'
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom
> -fasynchronous-unwind-tables
> uname output: Linux windmill 3.5.1-1.fc17.i686.PAE #1 SMP Thu Aug 9 17:50:53
> UTC 2012 i686 i686 i386 GNU/Linux
> Machine Type: i686-redhat-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 36
> Release Status: release
>
> Description:
> segfaults on "while read -sN1 K; do echo $K; done" when baskslash and
> then enter taped twice
Thanks for the report. Try the attached patch; it fixes the problem
for me.
Chet
--
``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/
*** ../bash-4.2-patched/builtins/read.def 2012-03-11 17:52:44.0 -0400
--- builtins/read.def 2012-08-22 11:53:09.0 -0400
***
*** 792,796
#endif
! if (saw_escape)
{
t = dequote_string (input_string);
--- 847,851
#endif
! if (saw_escape && input_string && *input_string)
{
t = dequote_string (input_string);
bashref.texi niglets
Hi Chet,
Perusing bashref.texi ...
1) Technically, version.texi should be before the %**end of header.
2) @setchapternewpage odd creates blank pages. There's no need to
inflict them on everyone by default. If the FSF or anyone wants that
for printing, they can always use -t @setchapternewpage odd or whatever.
3) The "Permission is granted ..." paragraph is part of the old
permissions statement and shouldn't be used with the GFDL. (The FDL
grants the same permission.) And no need for blank line before
@end quotation.
4) The Temple Place FSF address is stale and has been for years
(http://www.fsf.org/about/contact/ has their present address). I
suggest removing it from here and let the FSF put in wherever they
happen to be when and if they print the manual. (BTW, they aren't
distributing it now, as far as I can see from
http://shop.fsf.org/category/books/.)
5) Mention the bash home page. What the heck?
6) Better to send bug reports to the list than you personally?
Happy documenting,
Karl
--- ORIG/bashref.texi 2011-01-16 12:31:57.0 -0800
+++ bashref.texi2012-08-22 08:57:35.0 -0700
@@ -4,7 +4,4 @@
@settitle Bash Reference Manual
-@c %**end of header
-
-@setchapternewpage odd
-
@include version.texi
+@c %**end of header
@@ -20,6 +17,2 @@
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
@quotation
@@ -35,3 +28,2 @@
developing GNU and promoting software freedom.''
-
@end quotation
@@ -61,9 +53,2 @@
@insertcopying
-
-@sp 1
-Published by the Free Software Foundation @*
-59 Temple Place, Suite 330, @*
-Boston, MA 02111-1307 @*
-USA @*
-
@end titlepage
@@ -77,3 +62,4 @@
This text is a brief description of the features that are present in
-the Bash shell (version @value{VERSION}, @value{UPDATED}).
+the Bash shell (version @value{VERSION}, @value{UPDATED}). The Bash
+home page is @url{http://www.gnu.org/software/bash/}.
@@ -7663,3 +7649,3 @@
Please send all reports concerning this manual to
-@email{chet.ramey@@case.edu}.
+@email{bug-bash@@gnu.org}.
Diff finished at Wed Aug 22 08:59:34
BASH_COMMAND is incorrect when working with subshells and error traps
consider this simple code: $ cat test.sh #!/bin/bash trap 'echo $BASH_COMMAND; exit 1' ERR set -e true (false) true when run, we see: $ ./test.sh true 1 this can be confusing when utilized with automatic backtraces :( even when using errtrace and debugtrace, BASH_COMMAND is incorrect -mike signature.asc Description: This is a digitally signed message part.
Re: BASH_COMMAND is incorrect when working with subshells and error traps
On Wednesday 22 August 2012 12:30:11 Mike Frysinger wrote: > consider this simple code: > > $ cat test.sh > #!/bin/bash > trap 'echo $BASH_COMMAND; exit 1' ERR > set -e > true > (false) > true > > when run, we see: > $ ./test.sh > true 1 err, i tweaked my shell script slightly so this output would not be ambiguous, but forgot to post the updated shell script. #!/bin/bash trap 'echo $BASH_COMMAND; exit 1' ERR set -e true 1 (false) true 2 -mike signature.asc Description: This is a digitally signed message part.
Re: BASH_COMMAND is incorrect when working with subshells and error traps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/22/12 3:35 PM, Mike Frysinger wrote: > On Wednesday 22 August 2012 12:30:11 Mike Frysinger wrote: >> consider this simple code: >> >> $ cat test.sh >> #!/bin/bash >> trap 'echo $BASH_COMMAND; exit 1' ERR >> set -e >> true >> (false) >> true >> >> when run, we see: >> $ ./test.sh >> true 1 > > err, i tweaked my shell script slightly so this output would not be > ambiguous, > but forgot to post the updated shell script. > > #!/bin/bash > trap 'echo $BASH_COMMAND; exit 1' ERR > set -e > true 1 > (false) > true 2 > -mike Thanks for the report. This will be fixed for the next bash version. Chet - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1fOMACgkQu1hp8GTqdKvXkACfUXigH7aqdk/hOgYWPwxqP65/ MDIAnRhAr4jsW7UkWeXikv/bfIhj8x0z =rHgq -END PGP SIGNATURE-
Re: bash does filename expansion when assigning to array member in compound form
On 8/20/12 5:12 PM, Dan Douglas wrote:
> On Monday, August 20, 2012 07:44:51 PM Roman Rakus wrote:
>> And how would you achieve to fill array with all file names containing
>> `[1]=' for example.
>
> $ ls
> [1]=a [1]=b
> $ ( typeset -a a=( \[1\]=* ); typeset -p a )
> typeset -a a=('[1]=a' '[1]=b')
> $ ( typeset -a a=( [1]=* ); typeset -p a )
> typeset -a a=([1]='*')
> $
>
> In ksh93, by escaping. I think this is what most people would expect and
> probably what Bash intended.
Then how about this: words inside a compound assignment statement that are
recognized as assignment statements ([1]=foo) are expanded like assignment
statements (no brace expansion, globbing, or word splitting). Other words
undergo all the expansions.
That means you can do things like
[{0,1,2,3}]=foo
to set the first four elements to the same value, but things like
f='more than one word'
x=( [0]=$f )
will still only set the first element. This sounds like what you're after.
Chet
--
``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/
