bug-coreutils
[Top][All Lists]
Advanced

[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




reply via email to

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