

Why "ls *.c" is at least dumb, and possibly dangerous - r11t
http://groups.google.com/group/comp.unix.shell/msg/5d19dadaf9329f87

======
yan
Wait. What?

1) Is he implying that launching a perl interpreter is somehow a more
lightweight operation than launching ls and having it stat() half a dozen
files? Having ls check if a file exists 99% of the time won't even touch the
disk. If you're working in that directory, those inodes will probably be
cached. Running stat() on a cached inode is hardly more expensive than a
system call. Read: cheap. Now perl launching will probably load a few libs and
check a few files before even getting to his one-liner.

2) Am I the only one, who in my ~10 years of running unix-like operating
systems have _never_ created a filename with a newline char in it? Like even
when opening obscure filesystems, never.

3) Does he think unlink() skips the check for the file's existence?

4) If he wanted to overcomplicate things and _make sure_ everything's kosher,
why not:

    
    
      find . -maxdepth 1 -type f -name '*.c' -delete
    
    

Whenever I see anything piped to a perl one liner, 4 times out of 5 it's some
sort of hack that can be done with standard utils.

It also grinds my gears when people take longer to think of making something
more efficient than the amount of CPU time they'll save in their lives of
using that 'more efficient' solution. So he spent a minute coming up with this
and ten minutes posting about it. Now, will he save roughly 11 minutes of
execution time in his life while running this "superior" command (also count
that it takes longer to type)? If not, he wasted his time.

From his sig: "Smalltalk/Perl/Unix consulting". When you have a large-enough
hammer....

~~~
tptacek
_You_ aren't going to create a file with a newline in the name. The person who
wants to totally screw you over is going to create the file with the newline
in the name.

~~~
yan
I realize that. The example he used was a collection of c files, leading me to
believe he was showing a personal collection of source as an example, wrongly
or rightly. And I realize _you_ aren't going to be creating files with
newlines in them (or leading dashes, or many dots, etc), but once you get into
a territory of someone being able to do that, and you're not competing in a
CTF, I'd say there are larger issues to deal with.

~~~
basugasubaku
I can do no better than quote Randal himself again, from the same thread:

"Well, there was a very embarassing error for Apple a few years ago for the
10.3 to 10.4 upgrade as I recall. Apparently, if you had a space in your home
disk name, all sorts of files got deleted.

So, the moral is, no matter how rare you think something is, that's _NO
EXCUSE_ for not doing the right thing for _all_ possible characters."

[http://groups.google.com/group/comp.unix.shell/msg/504a75cc7...](http://groups.google.com/group/comp.unix.shell/msg/504a75cc7d87e16c)
[http://groups.google.com/group/comp.unix.shell/msg/0385fc2d1...](http://groups.google.com/group/comp.unix.shell/msg/0385fc2d1dbf745d)

~~~
nailer
Spaces in names are not rare - space is part of natural language, a filename
or volume name in considered to be a single line label.

------
drp
"ls *.c" is not dangerous. The pipe is dangerous.

~~~
nailer
The user making files with newlines is dangerous.

~~~
omouse
The user doing something that the system allows him to do is dangerous??

You guys are insane.

~~~
nailer
I completely agree that the system shouldn't allow him to do this either. Both
the graphical and command shells for Linux (GNOME and bash respectively) do
not allow files to be created with newlines characters as far as I know.

------
DanHulton
Filenames can contain newlines?

You learn something new (and vaguley horrifying) every day.

~~~
rmaccloy
Filenames can contain plenty of happy stuff.

$> touch -- --

$> rm --

usage: rm [-f | -i] [-dPRrvW] file ... unlink file

$> rm -- --

$> touch \

$> touch \\\ \ \ . \\-

favorites of malware authors everywhere.

~~~
aw3c2
On a sidenote, creating a -i file in important directories can help against
accidental "rm -rf"s. The -i will be given to rm as switch and rm will now
prompt for each file. Of course backups are better but this might just safe
your ass that certain time.

------
wvenable
This article does point out one thing that I've always found really
strange/dumb about Unix. Why does the shell expand the wildcards? That's not
how it works in Windows, for example.

I periodically have to cleanup abandoned and overflowing unix mailboxes where
every message is it's own file. You'd think a simple "rm *" would work, but it
doesn't, because you get an error message saying that there are "too many
arguments". From my perspective there's one argument, the asterisk. Very
confusing. I end up having to use xargs to get it work. Seems like a poor
design.

~~~
bobbyi
It's so that every script in the world doesn't have to duplicate the logic for
how to interpret globs. They inevitably won't end up doing it exactly the same
way.

~~~
wvenable
Shouldn't that be part of the OS API? Why call me with 1,000 arguments, when I
could call an API with the wildcard and get the 1,000 files back? My poor argv
can't handle it the other way.

------
nuggien
this is one of those things no one cares about until it affects them.

~~~
nailer
> Suppose you have a file with a name of "aaa\nbbb.c". (from the article)

To be honest, I wouldn't care about my shell not handling newlines in files,
I'd care about my users creating files with newlines in them. Space is natural
language, newline is not.

------
slice
I wonder how many files with a name containing \n are in the wild. And if you
encounter such a file, does it really matter if you accidentally delete it?

Waisting brain cycles to save CPU cycles (in the wrong places) is shameful,
insulting and boring.

It would be amazing if there weren't tons of other, much more significant,
things that deserved attention in the relevant script, system, or the
developer's life. (sign)

~~~
omouse
_And if you encounter such a file, does it really matter if you accidentally
delete it?_

It matters. Leaving a bug around is disgusting and wasteful especially when
you can fix it.

* would be amazing if there weren't tons of other, much more significant, things that deserved attention in the relevant script, system, or the developer's life. (sign)*

Fixing bugs and writing programs that have as few bugs as possible is very
important.

~~~
slice
When you find a bug, by all means, go ahead and fix it. (Well, not always. You
need to make sure your fix is not likely to introduce a more severe bug. Not
all bugs made equal and some guts-feeling required).

If your goal is to make your system as robust as _engineerically_ possible,
you should most likely pay more attention in some directions and less in
other. It's not only about quantity - you better have no critical bugs then
have only-a-very-few critical ones.

------
catzaa
Am I the only one who thinks that scripting is a "Dirty Job"?

I have not written nor seen any bash script that is neat, clean and fairly
clear. It all seems like a very shady hack that someone think is smart.

~~~
nailer
Not sure why you're being downmodded. On the simplest of engineering levels,
shells don't adequately separate data from execution. They also lack data
structures beyond strings and arrays.

ipython / iruby can and do make much nicer shells out of the box.

------
GeoffWozniak
Dumb on whose behalf? If you need to know the inner workings of the shell in
order to know that is "dumb" then I submit that in and of itself is dumb.

~~~
weaksauce
Apparently you have not been bitten by a filename expansion bug when shell
scripting. This kind of thing is fairly common with bash and some of the other
ones when dealing with files that have spaces/newlines/whatever. It boils down
to learning and knowing your tools and how to work around their limitations.

