This is the mail archive of the
mailing list for the Cygwin project.
RE: "which" command does not expand "~" in path (base-files update needed)
- From: "Dave Korn" <dk at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Tue, 28 Sep 2004 18:49:44 +0100
- Subject: RE: "which" command does not expand "~" in path (base-files update needed)
> -----Original Message-----
> From: cygwin-owner On Behalf Of Dave Korn
> Sent: 28 September 2004 18:35
> Why isn't it expanded by bash's tilde substitution at the
> time the 'export'
> command line is parsed then? That's sooo wrong. Oh wow.
> Guess what: it depends
> whether the *other* part of the assignment is quoted or not:
Interesting. From "info bash", node: "Shell Parameters":
" A variable may be assigned to by a statement of the form
If VALUE is not given, the variable is assigned the null string. All
VALUEs undergo tilde expansion, parameter and variable expansion,
command substitution, arithmetic expansion, and quote removal [ ... ]"
And from node "Tilde Expansion":
" If a word begins with an unquoted tilde character (`~'), all of the
characters up to the first unquoted slash (or all characters, if there
is no unquoted slash) are considered a TILDE-PREFIX. If none of the
characters in the tilde-prefix are quoted, the characters in the
tilde-prefix following the tilde are treated as a possible LOGIN NAME. "
So, given that words are separated by metachars, then the first word in the
is the full string
and therefore the presence of quotes later in the char shouldn't prevent bash
parsing the beginning of the word from the unquoted tilde char to the unquoted
slash immediately following it as a tilde-prefix, none of the chars in which are
Wonder if this is a real bug then, or if I've misread the shell parsing rules?
They are a bit ridiculously complicated and full of exceptions and special
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html