[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cp --target-dir=dir + shell expansion?
From: |
Bob Proulx |
Subject: |
Re: cp --target-dir=dir + shell expansion? |
Date: |
Tue, 9 Dec 2003 19:20:38 -0700 |
User-agent: |
Mutt/1.3.28i |
Chris Green wrote:
> find . -name sregex.el -o -name rx.el | xargs cp --target-directory=~/elisp
> cp: `~/elisp': specified target is not a directory
Usually the shell expands ~ characters. But in this case it can't
because it is not a leading ~ but packed in the middle of a string.
Here is the section from the bash man page:
Tilde Expansion
If a word begins with an unquoted tilde character (`~'),
all of the characters preceding 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. If this login name is the null string, the tilde is
replaced with the value of the shell parameter HOME. If
HOME is unset, the home directory of the user executing
the shell is substituted instead. Otherwise, the tilde-
prefix is replaced with the home directory associated with
the specified login name.
Usually in these cases the best practice is to always use $HOME. The
tilde is one of those "new fangled things".
> 1) Should the error string include an explicit ./ to tell the user
> that globbing isn't happening?
Personally I would rather it did not. But I realize it is confusing
to the user who sees ~ and does not realize that it is not expanded
there.
> 2) Should the = parameter do ~ expansion? If so, how would one treat
> files that really are ~.... maybe only do it on the first character
> of the string and requre ./~ for files that are really named that.
You can disable tilde expansion by quoting the tilde. In a shell
script it is a good defensive measure anyway.
> 3) Should the shells expand =~ into a the right string ( doesn't sound
> like a good idea for removing .backup=~ ) -- sounds dangerous
That is a judgement call. But one for the shell folks. This is a
AT&T korn shell feature that the other shells have cloned.
> 4) What there is now... and slap a warning in info/man pages
The problem is that if you try to warn about every shell programming
feature in every man page you end up replicating the shell manual in
every manual. It is just not practical.
> I understand this after thinking about it for a few minutes but I
> don't find my command is that far out of whack with what
> --target-directory is supposed to accomplish
Try using $HOME instead. That should work normally.
Bob