On Apr 7, 2011, at 10:48 PM, Aaron Toponce wrote:
> On Thu, Apr 07, 2011 at 09:50:24AM -0600, Robert LeBlanc wrote:
>>
>> % scp rleblanc@gw:~/test* .
>> zsh: no matches found: rleblanc@gw:~/test*
>> Using the FQDN did not help. What is going on?
>
> Yet another reason to quit using Bash- it teaches you bad habits!
>
> '*' is a file globbing character that gets expanded in the shell before the
> command is run. Thus, if you're in a directory that has files 'foo' 'bar'
> and 'baz', then "scp user@server:/test* ." would not expand '*' to the
> files on the remote server, but 'foo', 'bar' and 'baz' on your local
> server. Thus, before the command is executed, it would be expanded as thus:
>
> scp user@server:/testfoo user@server:/testbar user@server:/testbaz .
Actually, the original Bourne shell behaved like bash does. By definition, if
a glob doesn't match, the unglobbed string is passed as an argument to the
called program.
Your reasoning is flawed... for bash (or sh) to glob as you have described, you
would have to have a directory called "user@server:" in your current working
directory, with files starting with "test" existing in that directory. It
would never match your foo, bar, and baz files, because they don't start with
"user@server:/test".
The only difference I can see between the zsh and bash default implementations
are that zsh follows csh syntax (where a failed glob results in an error
message) while bash follows sh syntax (where a failed glob passes the unglobbed
string to the called program). Unlike the original Bourne shell, both zsh and
bash allow you to change the semantics with a shell option.
Personally, I prefer my Bourne-like shell to behave like the original Bourne
shell. I also prefer POLA (the policy of least astonishment), which says my
Bourne-like shell should behave this way by default.
-jan-
--
Jan L. Peterson
http://www.peterson-tech.com/~jlp/
--------------------
BYU Unix Users Group
http://uug.byu.edu/
The opinions expressed in this message are the responsibility of their
author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG.
___________________________________________________________________
List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
