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: Sun, 29 Oct 2006 21:39:07 +1100

>
>It is unfortunate that your choice of editor does not accept zero
>terminated strings as filenames because then this would be easy using
>grep's --null option.  The problem therefore as I see it is a
>deficiency in the editor capabilities.
>

Oh, so all applications should be adjusted to account for
bash/POSIX deficiencies? No.

>This is probably not a an optimal solution because this is late night
>time for me but this works:
>
>  eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
>

Yes, that works.
But surely such a grotesque syntax is not really in the spirit
of concise unix expressions.

>I would suggest xargs but the input is not attached to the terminal in
>that case.  I think xargs has recently been enhanced to allow this but
>it is not in most versions.  But batch editing works well.
>
>  grep --null -l PATTERN * | xargs -r0 sed --in-place 's/foo/bar/'
>

Again, one really wants to be able to use normal and concise
expressions.

>Although having spaces in filenames may be common in some cultures it
>is definitely not in the Unix culture.

Well, can I also say that unicode and grotesque multi-byte and
multi-lingual character sets weren't in the unix culture either.
But that is never an excuse.

>Being able to work with file
>names with spaces is definitely an afterthought.  It is best to avoid
>them.
>
>  rename 's/ /_/g' *
>

No! Often filenames must match some scheme, and arbitarily renaming is
not a good idea.  For example, suppose they are target of html href.
Suppose they are target of database reference.

Excuse me - but really somebody should sit down and think very hard
about this problem and come up with better working system, rather
than just excuses.

There is a specific challenge here.  Something is sort-of broken
and needs a good solution.

Why is it that word splitting never makes a distinction between
newlines and space?  Because the output of grep -l, and ls, etc are
clearly newline delimited. It is bash (and others) which quite deliberately
reduce available information by converting all newlines and whitespace
into a single space.

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).

The ball is quite clearly in bash's court.

Regards
Bahser





reply via email to

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