On 1 Jan 00, at 19:39, Blue Boar wrote:
> > at least with GNU rm (and i'm assuming all other versions have a similar
> > method), you can use rm -- -proc, but you could have also done rm ./-proc
> > (or in this case, rm -R ./*).
>
> I got a lot of replies suggesting these two methods. I believe I tried
> single-quoting the filename too, but that didn't work, which surprised me.
>
> # rm '-test'
>
> # rm \-test
The problem here is that you've got the wrong model of the Unix universe.
Quoting [any way: \, ", '] and wildcards are functions of the *SHELL* and
all do their thing _before_ the called-program is run. By the time the
called-program is run *all* of that stuff is gone and the program just
gets plain-jane 'strings' as its arguments. The 'quotes' and such are
**NOT** passed on... they're jsut directvies _to_hte_shell_ on how to
massage the strings on the command line before passing them to the called
program.
In both cases above the 'rm' program was given the single argument
hyphen-t-e-s-t . Whether you got that by wildcard expansions or fancy
quoting or the output of a ``'ed program or however, doesn't matter: at
the time 'rm' is run, all the exciting stuff has been done.
and so what you need is a way to get *rm*, not the _shell_, to deal with
the hyphened [or otherwise hacked] filename properly. After you figure
out what you need to pass to rm, then you take a step back and can ask
'now what syntax do I need to give to the shell so that it'll pass <THAT>
to the program it is calling'.
> >
> > All arguments will be prefixed with /tmp/ in this case, thus negating the
> > effect. No vulnerability.
>
> How about if there's a space in front?
Doesn't matter. Again, you need to have the right model: when the shell
expands wildcards, it "plugs in" the expansion strings
*no*matter*what*they*are*, and drops the resuling string as an argument
to the called program. This is the -last- step before calling the
program and so the args are _not_ interpreted by the shell an additional
time. Now the *PROGRAM* might get confused if you give it an
appropriately hacked arg string [cf the recent comments on bugtraq about
the problems with majordomo and giving it a pipe-redirect in its config
file name], but the shell wont/cant be confused.
> > Yes, but it won't matter, when it's expanded by the shell they will be
> > passed as if they were quoted.
>
> That's what I wanted to know. So why does the shell escape those,
> and not the - ? What can't I single-quote around or manually escape
> the - ? (using /bin/sh in my examples.)
Because you're confusing 'expansion' with 'quoting'. There's what you
type, which tells the -shell- something. Based on that, the shell
constructs an ARGV array-of-strings [null terminated, so things like
semicolon and spaces and newlines and the line are irrelevant!] and the
called-program uses the entries in that array as its arguments. There is
no "quoting" at the point the program is running: just plain old null-
terminated C strings; 'quoting' is simply a syntatic artifact to get the
shell to give the called program a particular argument string; there are
lots of syntatic-artifacts by which you get the shell to do various
things, and wildcard expansion is one of them.
The point is, again, that the confusion lies in the fact that it is the
called progrma, rm in this case, that is having trouble with what it sees
as its first argument [-proc]. The program has *NO* way of knowing which
of the many syntatic tricks available in the shell you may have used to
create that particular string, only that it showed up as the first
argument.
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
mailto:bernie_at_fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
Received on Jan 01 2000
Intro
