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: Eric Blake
Subject: Re: Spaces in args, escapes, and command substitution
Date: Sun, 29 Oct 2006 18:40:21 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to address@hidden on 10/29/2006 6:19 PM:
> 
> But maybe IFS really should have been named EFS?

Tradition is hard to break.  Yes, even POSIX admits in its rationale
section that the name IFS is somewhat misleading.  But shells have
implemented it that way for 20 years, so it isn't likely to change.

> 
> Anyhow I see that bash has taken the liberty of changing
> the traditional acronym expansion from "Input Field Separator" to
> "Internal Field Separator".  A subtle difference.

OK, you found a legitimate bug in the bash documentation.  Perhaps Chet
will change that for the next release.

> Anyhow, it is a pity that something like:
> 
>       vi $(IFS=\n grep -l PATTERN *)

That exports IFS as the single character n for the duration of the grep,
but grep does not care what IFS is set to.

> or
>       IFS=\n vi $(grep -l PATTERN *)

That exports IFS as the single character n for the duration of vi, but vi
does not care what IFS is set to.

You need to be careful - there is a big difference between IFS=\n and
IFS=$'\n'.  You also need to understand that it is bash that needs to see
the new value of IFS, not the child process, which means that setting IFS
cannot occur as part of the same simple command as what you are trying to
affect by having changed IFS.

> Also it might also be more convenient for aliasing.

Shell functions are more powerful than aliasing.  Although there are a few
things that only aliases can do, for the most part, you are better off
writing shell functions.

> 
> If it wasn't for the fact that there is an ambiguity regarding multiline
> command output which consists of a single line then it would be possible
> to make a permanent distinction between multi-line command output (with
> args separated by newlines and spaces escaped) and single line output
> where spaces are not escaped.

Messing with shell syntax is not done lightly.  It is too late to change
how `` and $() behave; you will break too many existing scripts.  The best
you can do now is learn how they do behave, and code accordingly.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFRVgF84KuGfSFAYARAg4jAKC59hBD1diOqmRfKHaaX1luoYacNACgxmj8
Vi3QqBg0lmUjdN5w7uZ0lrU=
=47A7
-----END PGP SIGNATURE-----




reply via email to

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