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/s
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
[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
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 int
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 pri
>
>> 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
>>
