Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Dangerous use of ls (was Re: Why preceed a "rm" command with a backslash?)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Randal L. Schwartz  
View profile  
 More options Sep 24 2009, 8:32 pm
Newsgroups: comp.unix.shell
From: mer...@stonehenge.com (Randal L. Schwartz)
Date: Thu, 24 Sep 2009 17:32:47 -0700
Local: Thurs, Sep 24 2009 8:32 pm
Subject: Dangerous use of ls (was Re: Why preceed a "rm" command with a backslash?)

>>>>> "Keith" == Keith Keller <kkeller-use...@wombat.san-francisco.ca.us> writes:

Keith> rm [filespec]

Keith> with (this is just off the top of my head; one can probably be more
Keith> efficient about it)

Keith> ls [filespec] |perl -ple unlink

That's scarily bad.  I have something akin to my once-famous "useless use of
cat award" that I used to give out for "dangerous use of ls".  You've just
triggered it for me.

Here's the point.  When you say:

  ls *.c

The following happens:

1) the shell expands *.c, into say: aaa.c, bbb.c, ccc.c
2) the shell fires up "ls aaa.c bbb.c ccc.c"
3) ls wakes up, and says "oh, I have command line args... let's go list those"
4) ls verifies aaa.c is there, and it's a file, so it prints it out
5) ls verifies bbb.c is there, and it's a file, so it prints it out
6) ls verifies ccc.c is there, and it's a file, so it prints it out

Why the heck would you make both the shell *and* ls go figure out what files
those are?

And don't get me started about what would have happened if you had a directory
that matched *.c.  That's a total tangent here, and also bad.

Now, let's go on to the dangerous part, more than just the wasted-CPU part.

"perl -ple" reads newline delimited names.  (By the way, it also needlessly
prints them... maybe you wanted "-nle".)

Suppose you have a file with a name of "aaa\nbbb.c".  Yup, that's legal.
Now your ls will print:

   aaa
   bbb.c

but Perl sees those as two separate names.  If you have an "aaa",
whoops, I mean, "now that you had an aaa", because it's now gone, even
though it didn't match "*.c".

Oops.

So, slow, and needlessly dangerous.  Bad all around.

Here's what I think you *might* have meant:

  perl -e 'unlink @ARGV' [filespec]

1) no useless use of ls
2) no danger from filenames containing newlines
3) no firing off two processes to do what one can do

And they say shell programming is simple.  {sigh}

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.