Spaces in args, escapes, and command substitution
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-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 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables" uname output: Linux XXX.zacglen.com 2.6.14-1.1644_FC4 #1 Wed Feb 22 11:11:16 EST 2006 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Inconsistent handling of escapes in command substitution. Repeat-By: 1. echo `echo a\\ b` 2. echo $(echo a \\ b) In case 1) the result is plain "a b" (both escapes discarded) In case 2) the result is "a\ b" (the space is has single escape) Fix: Can some attention be given to the problem of spaces in file names please? For example, "vi `grep -l *.c`" is fine so long as there are no spaces in the *.c filenames. But if there are, then the split on space that command subsitution does messes everything up. Given that "grep -l" outputs newline-delimited result then surely there should it should be possibly to have the spaces on each line escaped and only the newlines converted to spaces. Perhaps quoted "$(command)" should properly escape spaces before converting newline to space, a little like quoted "$*" does. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Empty sub-string expansion bug
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 lnxdavid 2.6.17-2-686 #1 SMP Wed Sep 13 16:34:10 UTC 2006
i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
Substring operations that are meant to return an empty string ""
sometimes return character "\177" instead.
Repeat-By:
A=""
B="${A:0}"
touch "/tmp/test/TEST${A:0}"
-> touch: cannot touch `/tmp/test/TEST\177': No such file or directory
touch "/tmp/test/TEST$B"
-> touch: cannot touch `/tmp/test/TEST': No such file or directory
The example above is contrived, here is another (more realistic)
example:
A="abc"
touch "/tmp/test/TEST${A:3}"
-> touch: cannot touch `/tmp/test/TEST\177': No such file or directory
Fix:
Bash script work-around: Use an intermediate variable until the bug is
fixed.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
[EMAIL PROTECTED] writes: > For example, "vi `grep -l *.c`" is fine so long as there are no spaces > in the *.c filenames. But if there are, then the split on space > that command subsitution does messes everything up. > > Given that "grep -l" outputs newline-delimited result then surely there > should it should be possibly to have the spaces on each line escaped > and only the newlines converted to spaces. Word splitting is controlled by IFS. Use IFS=$'\n' to only split on newlines. 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: Empty sub-string expansion bug
David Purdy wrote: > Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: > Substring operations that are meant to return an empty string "" > sometimes return character "\177" instead. > [...] > Fix: > Bash script work-around: Use an intermediate variable until the bug is > fixed. This was previously reported and is fixed in bash-3.2. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer 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: Problem with echo -e in bash 3.2
Zitat von Chet Ramey <[EMAIL PROTECTED]>: > Actually, I am discouraged that applications were not written to use the > portable `printf'. Use of `echo' in portable applications has been > deprecated for years. > > It's hindsight, of course, but had mc been written (or modified later) > to use printf, it would not need the shell-specific code it apparently > now contains. Ok, I'll see, if we can get the message over to the mc maintainers. Best regards, J. Roderburg ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Spaces in args, escapes, and command substitution
> >> For example, "vi `grep -l *.c`" is fine so long as there are no spaces >> in the *.c filenames. But if there are, then the split on space >> that command subsitution does messes everything up. >> >> Given that "grep -l" outputs newline-delimited result then surely there >> should it should be possibly to have the spaces on each line escaped >> and only the newlines converted to spaces. > >Word splitting is controlled by IFS. Use IFS=$'\n' to only split on >newlines. Tried that. Doesn't work. Perhaps instead of just saying "Use IFS..." you could show me a working example. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
