bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spaces in args, escapes, and command substitution


From: bash
Subject: Re: Spaces in args, escapes, and command substitution
Date: Mon, 30 Oct 2006 01:41:07 +1100

>
>According to bash@zacglen.com on 10/29/2006 3:39 AM:
>> Why is it that word splitting never makes a distinction between
>> newlines and space?
>
>Because POSIX, and tradition, say so.
>
>>  Because the output of grep -l, and ls, etc are
>> clearly newline delimited.
>
>That is a flawed argument.  Filenames can contain newlines.

That is an even more flawed response.
In practice how many such filenames have you every come across.
I have come across 0, nil, none. Besides, a newline need only be treated
like any other non-printing character.

It would hardly be sensible to have something that occurs 0.0001% of
the time dictate policy for what might occur >1% of the time.

>The only SAFE
>way to pass arbitrary filenames is null-delimited, if you are truly
>worried about metacharacters in the name.

That is not SAFE and not a good idea.
You cannot easily process such a set with a text editor, sed, tr, etc.
It flies right in the face of what Unix is supposed to be about.

>True, spaces are more common
>than newlines, but if you are going for safety, then go all the way.

I think usability is about 1000 times more important than safety,
especially when using the term "safe" is used in such a loose and
non-specific way.
i
>
>> It is bash (and others) which quite deliberately
>> reduce available information by converting all newlines and whitespace
>> into a single space.
>
>Only when told to do so by IFS on underquoted variable expansions and
>process substitutions.

I am still waiting for somebody to show how IFS can be used
to solve this problem.

>
>> 
>> Something simple like "vi $(^grep -l xx *)" would do.
>> The ^ might work because it denotes line-orientated regex (and nobody
>> uses it for pipes any more).
>
>Actually, that is well-defined by POSIX to invoke the command '^grep'.  If
>you are going to propose a new operator, you had better choose one that
>POSIX leaves unspecified.  But you are correct that no one uses ^ for
>pipes any more - POSIX does not allow ^ to mean pipes.
>

I am sure you get my meaning.  Just a matter of finding the right character
and/or syntax.

BTW which comes first - innovation or POSIX mandate?

Regards
Bahser





reply via email to

[Prev in Thread] Current Thread [Next in Thread]