document that echo can't be given a NULL
No way to hand echo or /bin/echo a NULL. $ set a $'\x00' b $ echo $# 3 $ echo A$'\x01'B|wc -c 4 $ echo A$'\x00'B|wc -c 3 $ echo -n `echo -ne 000`|wc -c 0 BASH_VERSION='3.1.0(1)-release' At least the echo docs should say so. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: document that echo can't be given a NULL
Dan Jacobson <[EMAIL PROTECTED]> wrote: > No way to hand echo or /bin/echo a NULL. For /bin/echo, that's because execve() uses null-terminated strings. For bash's builtin echo, it could be done, but then it would be inconsistent with external commands, which might be surprising. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
edit-and-execute-command in non-posix vi editing mode fails with default editor
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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
uname output: Linux hpstryn6 2.6.15-1-amd64-k8-smp #2 SMP Thu Feb 23 04:57:49
UTC 2006 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
The default edit-and-execute-command behavior for non-posix vi
editing mode fails when EDITOR is not set. It has changed from
using vi in 3.0 to trying to use 'editor' first in 3.1. But it
fails to start an editor and just executes the unchanged command line.
Repeat-By:
Start bash
set -o vi
unset EDITOR
Type 'datev'
The date command is run without a chance to edit it.
Fix:
Remove an extra right parenthesis from bashline.c.
--- bash/bashline.c~2006-01-31 13:30:34.0 -0700
+++ bash/bashline.c 2006-03-09 12:32:24.0 -0700
@@ -800,7 +800,7 @@
command being entered (if no explicit argument is given), otherwise on
a command from the history file. */
-#define VI_EDIT_COMMAND"fc -e \"${VISUAL:-${EDITOR:-$(command
-v editor || echo vi))}}\""
+#define VI_EDIT_COMMAND"fc -e \"${VISUAL:-${EDITOR:-$(command
-v editor || echo vi)}}\""
#define EMACS_EDIT_COMMAND "fc -e \"${VISUAL:-${EDITOR:-$(command -v
editor || echo emacs)}}\""
#define POSIX_VI_EDIT_COMMAND "fc -e vi"
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Wrong parsing of backslash inside backquote
Configuration Information [Automatically generated, do not change]: Machine: ia64 OS: linux Compiler: gcc -I/usr/src/packages/BUILD/bash-3.1 -L/usr/src/packages/BUILD/bash-3.1/../readline-5.1 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='ia64' -DCONF_OSTYPE='linux' -DCONF_MACHTYPE='ia64-suse-linux' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -pipe -g -fbranch-probabilities uname output: Linux sykes 2.6.16-rc5-git9-2-default #1 SMP Tue Mar 7 14:56:34 UTC 2006 ia64 ia64 ia64 GNU/Linux Machine Type: ia64-suse-linux Bash Version: 3.1 Patch Level: 11 Release Status: release Description: A backslash inside `...` leads to a parse error when it is the last character in a single quoted string. Repeat-By: $ cat x.sh foo `bar 'a\'` $ sh x.sh x.sh: line 1: unexpected EOF while looking for matching `'' x.sh: line 2: syntax error: unexpected end of file ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: edit-and-execute-command in non-posix vi editing mode fails with default editor
Mike Stroyan wrote:
> Bash Version: 3.1
> Patch Level: 0
> Release Status: release
>
> Description:
> The default edit-and-execute-command behavior for non-posix vi
> editing mode fails when EDITOR is not set. It has changed from
> using vi in 3.0 to trying to use 'editor' first in 3.1. But it
> fails to start an editor and just executes the unchanged command line.
>
> Repeat-By:
> Start bash
> set -o vi
> unset EDITOR
> Type 'datev'
> The date command is run without a chance to edit it.
>
> Fix:
> Remove an extra right parenthesis from bashline.c.
>
> --- bash/bashline.c~ 2006-01-31 13:30:34.0 -0700
> +++ bash/bashline.c 2006-03-09 12:32:24.0 -0700
> @@ -800,7 +800,7 @@
> command being entered (if no explicit argument is given), otherwise on
> a command from the history file. */
>
> -#define VI_EDIT_COMMAND "fc -e \"${VISUAL:-${EDITOR:-$(command
> -v editor || echo vi))}}\""
> +#define VI_EDIT_COMMAND "fc -e \"${VISUAL:-${EDITOR:-$(command
> -v editor || echo vi)}}\""
> #define EMACS_EDIT_COMMAND "fc -e \"${VISUAL:-${EDITOR:-$(command -v
> editor || echo emacs)}}\""
> #define POSIX_VI_EDIT_COMMAND"fc -e vi"
That's not in bash-3.1 as distributed. It must have been added by
Debian.
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: document that echo can't be given a NULL
> No way to hand echo or /bin/echo a NULL. You mean NUL, not NULL. And printf can do it. > $ set a $'\x00' b > $ echo $# > 3 > $ echo A$'\x01'B|wc -c > 4 > $ echo A$'\x00'B|wc -c > 3 Here, command substitutions strip all NULs from the command's output. POSIX doesn't specify whether this behavior is allowed or not, but I think it makes more sense for command substitution to strip NULs than to risk the inconsistency of arguments being chopped short as they are passed through exec() calls. -- Eric Blake ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Wrong parsing of backslash inside backquote
[EMAIL PROTECTED] wrote: > Configuration Information [Automatically generated, do not change]: > Machine: ia64 > OS: linux > Compiler: gcc -I/usr/src/packages/BUILD/bash-3.1 > -L/usr/src/packages/BUILD/bash-3.1/../readline-5.1 > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='ia64' > -DCONF_OSTYPE='linux' -DCONF_MACHTYPE='ia64-suse-linux' -DCONF_VENDOR='suse' > -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H > -I. -I. -I./include -I./lib -O2 -fmessage-length=0 -Wall > -D_FORTIFY_SOURCE=2 -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -pipe -g > -fbranch-probabilities > uname output: Linux sykes 2.6.16-rc5-git9-2-default #1 SMP Tue Mar 7 14:56:34 > UTC 2006 ia64 ia64 ia64 GNU/Linux > Machine Type: ia64-suse-linux > > Bash Version: 3.1 > Patch Level: 11 > Release Status: release > > Description: > A backslash inside `...` leads to a parse error when it is the > last character in a single quoted string. > > Repeat-By: > $ cat x.sh > foo `bar 'a\'` > $ sh x.sh > x.sh: line 1: unexpected EOF while looking for matching `'' > x.sh: line 2: syntax error: unexpected end of file Applying the updated patch 10 as distributed here and on ftp.case.edu would have fixed this problem. (No, I have received no answer from the folks who run ftp.gnu.org in response to my attempts to replace the version of patch 10 there.) z3(1)$ cat x5 foo `bar 'a\'` z3(1)$ ./bash ./x5 ./x5: line 1: bar: command not found ./x5: line 1: foo: command not found z3(1)$ ./bash --version GNU bash, version 3.1.11(9)-release (powerpc-apple-darwin8.3.0) Copyright (C) 2005 Free Software Foundation, Inc. However, in the long run, it's hopeless to try and recursively parse quoted strings and shell expansions inside `` and retain backwards compatibility with the Bourne shell, despite what POSIX says. The problem only gets worse when considering double-quoted strings. 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: edit-and-execute-command in non-posix vi editing mode fails with default editor
On Fri, Mar 10, 2006 at 04:40:00PM -0500, Chet Ramey wrote:
> Mike Stroyan wrote:
...
> > Remove an extra right parenthesis from bashline.c.
> >
> > --- bash/bashline.c~2006-01-31 13:30:34.0 -0700
> > +++ bash/bashline.c 2006-03-09 12:32:24.0 -0700
> > @@ -800,7 +800,7 @@
> > command being entered (if no explicit argument is given), otherwise on
> > a command from the history file. */
> >
> > -#define VI_EDIT_COMMAND"fc -e \"${VISUAL:-${EDITOR:-$(command
> > -v editor || echo vi))}}\""
> > +#define VI_EDIT_COMMAND"fc -e \"${VISUAL:-${EDITOR:-$(command
> > -v editor || echo vi)}}\""
> > #define EMACS_EDIT_COMMAND "fc -e \"${VISUAL:-${EDITOR:-$(command -v
> > editor || echo emacs)}}\""
> > #define POSIX_VI_EDIT_COMMAND "fc -e vi"
>
> That's not in bash-3.1 as distributed. It must have been added by
> Debian.
>
> Chet
Oops. Now I see the debian patch that caused it. I'll file a report
against debian. Thanks for the reality check.
--
Mike Stroyan, [EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
incomplete execution in long backtick expansion
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 uname output: Linux bminton.is-a-geek.net 2.6.15.4 #0 SMP Sat Feb 18 12:04:34 EST 2006 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 5 Release Status: release Description: If I have a long command line expansion with back ticks, executing code in a for loop, the contents of the loop are not executed every time. This does not seem to be true for built-in commands inside the loop. Repeat-By: for f in `seq 2`; do ls /dev/null;done|wc -l (output: 4097) for f in `seq 2`; do echo /dev/null;done|wc -l (output: 2) for f in `seq 2`; do /bin/echo /dev/null;done|wc -l (output: 4097) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash reproducibly segfaults while globbing large directory
Nikita Danilov wrote: > Bash Version: 2.05b > Patch Level: 0 > Release Status: release > > Description: > bash 100% reproducibly crashes when trying to do a globbing in a huge > directory Thanks. This will be fixed in the next version. 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: Escape newline within quotes in commands
Werner Fink wrote: > BASH PATCH REPORT > = > > Bash-Release: 3.1.5 > Bug-Description: > > Lines like > >g31:bash-3.0 > x=`echo A B C | sed 's/ /\\ >> /g'` >g31:bash-3.0 > echo "$x" >A >B >C > > do not work with current bash 3.1.5. This breaks > scripts working with both the pdksh/ksh and the > old bash 3.0. The enclosed patch restore the old > behaviour. This is fixed by official patch 10. Make sure to get the updated version of that patch from ftp.case.edu. I have not yet been able to get the folks who manage ftp.gnu.org to allow me to update patch 10 there. Now that bug-bash appears to have arisen from the ashes, I will send out the updated patch 10 again. 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 Official patch 10
Greg Schafer wrote:
> It appears there might be problem with this patch. Here is a test case I
> distilled from the grep-2.5.1a testsuite:
>
> status=`echo '-'| { ${GREP} -E -e 'a\' >/dev/null 2>&1 ; echo $?; }`
>
> Put that line into a file called "myfile" then run like this:
>
> # bash -n myfile
> myfile: line 1: unexpected EOF while looking for matching `''
> myfile: line 2: syntax error: unexpected end of file
>
> AFAICT, this used to be accepted by older Bash versions.
>
> Do think problem lies with this Bash patch or with test case?
It looks like the patch is over-agressive allowing backslashes to
quote characters in a backquoted command substitution. I will update
the patch, and send out the new one.
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
Configure script in db-3.3.11 fails with bash-3.1, but, works with ast-ksh
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 -O3 -fomit-frame-pointer
-march=athlon-xp -pipe
uname output: Linux athlon.localdomain 2.6.15 #1 PREEMPT Mon Feb 13 03:55:15
IST 2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 7
Release Status: release
Description:
The configure script in db-3.3.11 fails with bash-3.1, but, passes with
ast-open's (2006-01-24) ksh (version sh (AT&T Labs Research) 1993-12-28 r).
The output produced by running configure is:
checking how to run the C preprocessor... cc -E
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for cc option to produce PIC... -fPIC
checking if cc PIC flag -fPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.lo...
checking if cc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
../dist/configure: line 13666: syntax error near unexpected token `('
../dist/configure: line 13666: `case `(ac_space=' '; set | grep ac_space)
2>&1` in'
Repeat-By:
Download db-3.3.11.tar.gz from http://sleepycat.com/
tar xzf db-3.3.11.tar.gz
cd db-3.3.11/build_unix
../dist/configure
Thanks,
Rajeev
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Failure of removing pattern.
Here is a bug report generated by bashbug.
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix5.2.0.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
-DCONF_OSTYPE='aix5.2.0.0' -DCONF_MACHTYPE='powerpc-ibm-aix5.2.0.0'
-DCONF_VENDOR='ibm'
-DLOCALE
DIR='/users/hit/hitach01/src/bash-trace//share/locale' -DPACKAGE='bash'
-DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl
-I/users/hit/hitach01/src/bash-3.1/lib/intl -lm
uname output: AIX sr2_n24 2 5 00C500314C00
Machine Type: powerpc-ibm-aix5.2.0.0
Bash Version: 3.1
Patch Level: 0
Release Status: release
Description:
A refference to a shell variable doesn't work under specific case.
The result of the following operations isn't shown and prompt doesn't
return when environment variable LANG is Ja_JP on AIX 5.2L
$ i=123456789012l
$ echo ${i%l}
(Pronput doesn't return...)
Fix:
This problem is avoidable by the modification shown below:
Replace l. 3365 in subst.c ("ret = wcsdup (wparam);")
to the following two lines:
ret = (wchar_t *) malloc((size_t)(n + 1) * sizeof(wchar_t));
wcscpy(ret, wparam);
--
Ken'ichiro Shirose
[EMAIL PROTECTED]
Hitachi, Ltd.
Goverment & Public Corporation Information
Systems Division
--
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Trap on ERR not inherited by subshell with "set -E"
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-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 uname output: Linux Knoppix 2.6.12 #2 SMP Tue Aug 9 23:20:52 CEST 2005 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Bash manpage says that if "set -E" is set, "any trap on ERR is inherited by shell functions, command substitutions, and commands executed in a subshell environment. The ERR trap is normally not inherited in such cases." But when running this script trap 'echo ERR' ERR set -E echo "Fail in this shell" false ( echo "Fail in subshell" ; false ) Only first 'false' is trapped, and the 'false' in subshell is not trapped. Repeat-By: Repeat by running this shell-script. trap 'echo ERR' ERR set -E echo "Fail in this shell" false ( echo "Fail in subshell" ; false ) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
double array var expansion
Help! Why does this not work? n=a a=( x y z) echo "$!n[0]" echo "$!n[1]" echo "$!n[2]" only value i get is a[0] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
LINES and COLUMNS variables are not exported
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 uname output: Linux pundit 2.6.15-1-686 #2 Thu Feb 2 18:29:01 UTC 2006 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 5 Release Status: release Description: LINES and COLUMNS variables are not exported, so applications using these variables can not find the screen size. Repeat-By: $ ( echo $LINES ) 24 $ sh -c 'echo $LINES' $ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
BUG: ls -ld directory/
If you do an ls -ld directory/ for some existing directory then the output contains TWO trailling slashes: drwx-- 2 pypgcm users 4096 Aug 16 2005 directory// The directory and the first slash appear in blue on my terminal, trailing slash in black. Piping through something else does not supress the double slash. This does not happen if you produce the same entry using: ls -ld directory or: ls -l and pick out the appopriate entry. I believe this is a bug. Thanks, -- Graham McNeil-Watson University of Bath ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
core/loop vi mode when '.' used to repeat a replace
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd4.8 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd4.8' -DCONF_MACHTYPE='i386-unknown-freebsd4.8' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=pentiumpro uname output: FreeBSD base686.home.org 4.8-RELEASE FreeBSD 4.8-RELEASE #14: Thu Sep 8 12:45:15 CDT 2005 [EMAIL PROTECTED]:/usr/src/sys/compile/base686 i386 Machine Type: i386-unknown-freebsd4.8 Bash Version: 3.1 Patch Level: 11 Release Status: release Description: I've noticed that if I use ',' to repeat a substitution in vi-mode, bash either dumps core or goes into a hard loop. Repeat-By: Any command should do, I used this now as I was filling out this form: $ set -o vi $ date; date; date Fri Mar 3 12:53:06 CST 2006 Fri Mar 3 12:53:06 CST 2006 Fri Mar 3 12:53:07 CST 2006 Now, with vi-mode in effect, type 'ESC -' to bring up the "date..." command, type 'f e' to move the cursor to the first 'e', type 'r e' to replace the 'e' with 'e', type ';' to move the cursor to the second 'e', type '.' to repeat the previous substitution. For me, bash goes into a hard loop at this point and I need to 'kill -9' the process. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
for loops without in do not work
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd4.11 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd4.11' -DCONF_MACHTYPE='i386-portbld-freebsd4.11' -DCONF_VENDOR='portbld' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_THREAD_SAFE -I/usr/local/include -O -pipe uname output: FreeBSD pc5.i.0x5.de 4.11-RELEASE-p14 FreeBSD 4.11-RELEASE-p14 #0: Fri Jan 13 12:29:14 CET 2006 [EMAIL PROTECTED]:/scratch/obj/usr/exported/src/sys/PC5 i386 Machine Type: i386-portbld-freebsd4.11 Bash Version: 3.1 Patch Level: 10 Release Status: release Description: for loops where no in is specified do not work at least in the FreeBSD port of if (bash-3.1.10) Repeat-By: cat t.sh #!/usr/local/bin/bash echo X "$@" for i do echo A $i done EOF > ./t.sh a b c X a b c A > bash 2.05b.0(1)-release gives the correct output X a b c A a A b A c ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
for VAR; do does not work any more on some platforms
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd6.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd6.0' -DCONF_MACHTYPE='i386-unknown-freebsd6.0' -DCONF_VENDOR='unknown' -DLOCALEDIR='/tmp/bash/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl -I/tmp/bash-3.1/lib/intl -g -O2 uname output: FreeBSD katsuragi.div0.ccc-offenbach.org 6.0-STABLE FreeBSD 6.0-STABLE #1: Sat Jan 28 12:11:17 CET 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DIV0_KERNEL i386 Machine Type: i386-unknown-freebsd6.0 Bash Version: 3.1 Patch Level: 11 Release Status: release Description: In other shells (like bash 3.0, bash 2.x, zsh, dash), for VARIABLE; do ...; done is equivalent to for VARIABLE in "$@"; do ...; done GNU autoconf also relies on this fact at many points: ac_prev= for ac_option do # If the previous option needs an argument, assign it. if test -n "$ac_prev"; then eval "$ac_prev=\$ac_option" ac_prev= continue fi ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` The problem becomes quite visible in that configure scripts seem to ignore parameters line --prefix. libtool does not work either... mode=link for arg do case $arg in -c) mode=compile Too bad that this does not work in bash 3.1 any more (3.1 without the patches is also affected). It at least happens on FreeBSD/x86 and _did_ happen on Gentoo/PPC but apparently got fixed. On some other platforms like FC4/x86 it does NOT happen. Repeat-By: [EMAIL PROTECTED] /tmp/bash/bin $ set -- a b c [EMAIL PROTECTED] /tmp/bash/bin $ echo "$@" a b c [EMAIL PROTECTED] /tmp/bash/bin $ for V; do echo $V; done [EMAIL PROTECTED] /tmp/bash/bin $ for V in "$@"; do echo $V; done a b c [EMAIL PROTECTED] /tmp/bash/bin $ help for for: for NAME [in WORDS ... ;] do COMMANDS; done The `for' loop executes a sequence of commands for each member in a list of items. If `in WORDS ...;' is not present, then `in "$@"' is assumed. For each element in WORDS, NAME is set to that element, and the COMMANDS are executed. for ((: for (( exp1; exp2; exp3 )); do COMMANDS; done Equivalent to (( EXP1 )) while (( EXP2 )); do COMMANDS (( EXP3 )) done EXP1, EXP2, and EXP3 are arithmetic expressions. If any expression is omitted, it behaves as if it evaluates to 1. [Describe the sequence of events that causes the problem to occur.] [EMAIL PROTECTED] /tmp/bash/bin $ set -xv [EMAIL PROTECTED] /tmp/bash/bin $ for X; do echo $X; done for X; do echo $X; done + for X in '""' + echo ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: BUG: ls -ld directory/
> > If you do an > > ls -ld directory/ > > for some existing directory then the output contains TWO trailling > slashes: > > drwx-- 2 pypgcm users 4096 Aug 16 2005 directory// > > I believe this is a bug. This is not a bash problem, so you should have mailed the bug-coreutils mailing list. However, my guess is that you have an alias in place such that you are executing 'ls -F' or 'ls -p' rather than 'ls'. Try 'type ls' to learn more about what is really happening, before incorrectly calling this a bug. -- Eric Blake ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: double array var expansion
[EMAIL PROTECTED] wrote: > Help! > > Why does this not work? > > n=a > a=( x y z) > echo "$!n[0]" > echo "$!n[1]" > echo "$!n[2]" > > > only value i get is a[0] First of all, you need the braces. Otherwise you get $!, followed by n[0], n[1], and n[2], respectively. Second, once you add the braces, the entire parameter is indirected: n[0], n[1], or n[2]. Only the first expands to anything, since subscripting a scalar with 0 is equivalent to expanding it without the array syntax. So you get 'a', since $n == a, and try to indirect through `$a'. Since referencing an array variable without using array syntax is equivalent to referencing element 0, you get a[0], or x. Bash uses the entire rest of the parameter portion of the expansion as the part to expand and perform indirection on; this is documented in the manual page. 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: LINES and COLUMNS variables are not exported
Thierry EXCOFFIER wrote: > 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 > uname output: Linux pundit 2.6.15-1-686 #2 Thu Feb 2 18:29:01 UTC 2006 > i686 GNU/Linux > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.1 > Patch Level: 5 > Release Status: release > > Description: > LINES and COLUMNS variables are not exported, > so applications using these variables can not > find the screen size. It's a simple matter to export them yourself; maybe out of a startup file. Once they find their way into the environment, bash will export them automatically. 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: BUG: ls -ld directory/
G C McNeil-Watson wrote: > If you do an > > ls -ld directory/ > > for some existing directory then the output contains TWO trailling > slashes: > > drwx-- 2 pypgcm users 4096 Aug 16 2005 directory// [...] > and pick out the appopriate entry. I believe this is a bug. It might be, and I am sure there are those who would disagree, but any `bug' is in ls, not bash. 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: for VAR; do does not work any more on some platforms
[EMAIL PROTECTED] wrote: > Bash Version: 3.1 > Patch Level: 11 > Release Status: release > > Description: > > In other shells (like bash 3.0, bash 2.x, zsh, dash), > > for VARIABLE; do ...; done > > is equivalent to > > for VARIABLE in "$@"; do ...; done And it is in bash, too. When this has been reported in the past, it has been due to a bug in the version of bison used to generate the parser from parse.y. I cannot remember the exact version of bison that's at fault, and can't easily find it right now, but that is the culprit. 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
trap handler scope wrong?
I ran into something weird the other day, but I'm not sure if it's a bug or not
since I'm a bit new to bash shell scripting. Basically I have a script that
has structure like this:
set -e
trap "cat $LOGFILE" ERR
{
foo
bar
baz
} > $LOGFILE 2>&1
If an error happens inside the {} block, it looks like the ERR trap handler is called inside the {} context, so it's stdout is redirected to the log file. I had expected it to be called in the same scope it was defined in so that it's stdout would not be redirected.
Is this a bug, or expected behavior? If it is expected, can anyone suggest a way to do what I'm trying to? The reason for this structure was to redirect verbose output to a log file which would normally be deleted from the EXIT trap handler, but if anything goes wrong, the ERR handler is to cat the full log file so I can see exactly what went wrong.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: LINES and COLUMNS variables are not exported
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Thierry EXCOFFIER on 2/26/2006 8:59 AM: > > Description: > LINES and COLUMNS variables are not exported, > so applications using these variables can not > find the screen size. POSIX states that "Users should not need to set this variable in the environment unless there is a specific reason to override the implementation's default behavior, such as to display data in an area arbitrarily smaller than the terminal or window." But if it is causing you problems, you can simply do: export LINES COLUMNS before invoking your app that does not know how to query the terminal for its normal size. - -- 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 iD8DBQFECjIg84KuGfSFAYARAsjIAJ0Z45aEZxmin04YxSfRS1cMT9zhjwCgnXjT e3HtvPU/8vrwbJ0nczT0q9M= =Ix8n -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
