linux beivrit

linux beivrit

Tzafrir Cohen tzafrir at cohens.org.il
Sat Jul 10 22:09:09 IDT 2010


On Sat, Jul 10, 2010 at 09:40:08PM +0300, Raz wrote:
> On Fri, Jul 9, 2010 at 3:05 AM, Tzafrir Cohen <tzafrir at cohens.org.il> wrote:
> 
> > On Thu, Jul 08, 2010 at 10:44:52PM +0300, Raz wrote:
> > > On Tue, Jul 6, 2010 at 2:14 AM, Tzafrir Cohen <tzafrir at cohens.org.il>
> > wrote:
> > >
> > > > On Mon, Jul 05, 2010 at 03:16:38PM +0300, Raz wrote:

> > > > 3. You write about ls:
> > > >
> > > > ls מקבלת תווים מיוחדים שתפקידם לייצג תבנית חיפוש  , סימן הכוכב* מייצג
> > > > מספר כלשהו של תווים
> > > >
> > > > I hope you explain later on that this is not ls that interperts those
> > > > wildcards.
> > > >
> > > Does it matter so much ?
> >
> > Hmm... if you don't understand the difference - it does matter.
> >
> > The shell expansion is not that of simple wildcard. It is also of
> > variables, command substitution, and more.
> >
> > For instance:
> >
> >  cp *.a *.b
> >
> > is pointless (unless you happen to only have a single *.a, and in which
> > case it will be bopied to the literal '*.b'.
> >
> > This is because 'cp' does not care about wildcard expansion.
> 
> I understand your point. what I mean is that when talking about certain
> commands i do not want to add the complexity of who buffers what. Also, are
> you sure that "ls" does not accept wildcards ? stracing it seems to indicate
> that it does.

Sure it doesn't:

tzafrir at sweetmorn:~$ mkdir test
tzafrir at sweetmorn:~$ cd test
tzafrir at sweetmorn:~/test$ touch file1
tzafrir at sweetmorn:~/test$ touch file2
tzafrir at sweetmorn:~/test$ ls '*'
ls: cannot access *: No such file or directory
tzafrir at sweetmorn:~/test$ ls *
file1  file2
tzafrir at sweetmorn:~/test$ touch '*'
tzafrir at sweetmorn:~/test$ ls '*'
*
tzafrir at sweetmorn:~/test$ ls
*  file1  file2


Now let's ask the shell to tell us what it does:

tzafrir at sweetmorn:~/test$ set -x
tzafrir at sweetmorn:~/test$ ls *
+ ls --color=auto '*' file1 file2
*  file1  file2
tzafrir at sweetmorn:~/test$ ls '*'
+ ls --color=auto '*'
*
tzafrir at sweetmorn:~/test$ ls file*
+ ls --color=auto file1 file2
file1  file2
tzafrir at sweetmorn:~/test$ ls \*
+ ls --color=auto '*'
*
tzafrir at sweetmorn:~/test$ set +x
+ set +x

ls or whatever command have nothing to do with expanding the '*'.

> I added to section 2 in part 1:
> 
> רלמעטפת יש מספר פקודות משלה שאינם בינרים ויש מקרים שבינרי ייכשל בפרשנות של
> סימנים מסוימים. למשל : cp *.a *.b יכשל כי הבינארי cp לא מקבל סימנים מיוחדים
> ואיננו יכול לבצע הוראה זו.

That's plain wrong. The binary may fail, but it's not the binary that
expands wildcards.

tzafrir at sweetmorn:~/test$ ls *
*  file1  file2
tzafrir at sweetmorn:~/test$ ls nosuchfile*
ls: cannot access nosuchfile*: No such file or directory
tzafrir at sweetmorn:~/test$ touch *
tzafrir at sweetmorn:~/test$ touch nosuchfile*
tzafrir at sweetmorn:~/test$ ls
*  file1  file2  nosuchfile*


And another one, with 'cp' this time:
tzafrir at sweetmorn:~/test$ rm nosuchfile*
tzafrir at sweetmorn:~/test$ ls *
*  file1  file2
tzafrir at sweetmorn:~/test$ cp file1 nosuchfile*
tzafrir at sweetmorn:~/test$ ls
*  file1  file2  nosuchfile*


The shell failed to expand the '*' in 'nosuchfile*' so it left it as-is.
For 'ls' the result was a missing file. For touch and for cp (the second
parameter of cp) there's no problem with that file not to exist. So no
error.


Is the target audince someone familiar with DOS/cmd.exe wildcard
expansion, or someone who isn't? For those with such a background you
may need to explain the differences. For others, just explain what they
do and don't bother with 'cp *.a *.b'.

-- 
Tzafrir Cohen         | tzafrir at jabber.org | VIM is
http://tzafrir.org.il |                    | a Mutt's
tzafrir at cohens.org.il |                    |  best
tzafrir at debian.org    |                    | friend



More information about the Linux-il mailing list