Re: Unix * weirdness

[aflury () NAS NASA GOV (Andrew W. Flury)]

> It took me a minute.  It's taking the file named -proc and parsing as
> if it was a set of command line options.  I guess this makes some
> sense.. I believe the shell just takes all the files and makes them all
> command-line parameters when you use *.
>
> Naturally, I've been thinking about the possibilities...  I haven't
> had much time to work out details (got sucked into Y2K weekend
> work) so I wanted to pass this to the list for further explanation.
>
> BTW, I got rid of it with:
>
> # unlink -proc
>
> So, I wonder what other kinds of traps can be laid for the root
> user or cron jobs, etc...  For example, here's a line from my
> S05RMTMPFILES in /etc/rc2.d dir, on a Solaris 2.6 machine.
> (Which is where this behavior was noticed):
>
> /usr/bin/rm -rf /tmp/*

The above command would work properly with a file named "-foo" in /tmp.  The
shell would simply replace /tmp/* with /tmp/-foo (among other things), which
isn't parsed by getopt(3).  There is only a problem here if the script did
something like "cd /tmp && rm -rf *".

> So, if I can place an interestingly names file in /tmp
> (and anyone can) can I get interesting things to happen
> when the machine reboots.
>
> For example, can I get a file with spaces in it?  How about
> the | (vertical bar) character?  How about a ; ?

All of these characters are interpreted BEFORE the glob (*) is expanded, so
they should work just fine.  The only exception would be if the programmer
does something dumb like passing the glob to eval.

> (Yes, I could test it myself if I had time at the moment.)
>
> Is this a really old "feature" that everyone knows about except me?

I wouldn't call it a "feature"... it's just the way the shell and getopt(3)
interact.