[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
- Re: Spaces in args, escapes, and command substitution, (continued)
- Re: Spaces in args, escapes, and command substitution, Eric Blake, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Bob Proulx, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Bob Proulx, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Eric Blake, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Bob Proulx, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Eric Blake, 2006/10/29
- Re: Spaces in args, escapes, and command substitution,
bash <=
- Re: Spaces in args, escapes, and command substitution, Bob Proulx, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Chet Ramey, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Chet Ramey, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Eric Blake, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, bash, 2006/10/29
- Re: Spaces in args, escapes, and command substitution, Eric Blake, 2006/10/29