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

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'

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 @@

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'

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

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

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 21 ; echo $?; }` Put that line into a file called myfile then run like this: # bash -n myfile

Failure of removing pattern.

Here is a bug report generated by bashbug. output 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'

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'

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

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

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'

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

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'

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

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

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 21 If an error happens inside the {} block, it looks

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