Many people are recommending the '--' option-terminating option. Note David Wheeler's caution (in the essay already linked by AceJohnny2 at https://news.ycombinator.com/item?id=8190208) about why this is not an all-purpose solution: http://www.dwheeler.com/essays/filenames-in-shell.html#dashd....
Unix Wildcards Gone Wild
11–20 of 54 posts
Re: Unix Wildcards Gone Wild
#12David A. Wheeler, FOSS (and occasionally security) luminary, who also happens to be creator of the popular sloccount tool, has an excellent page that covers this topic and how to use paths safely and portably in shell scripts (spoiler: it's hard ) : http://www.dwheeler.com/essays/filenames-in-shell.html I strongly recommend his many other essays to HN readers: http://www.dwheeler.com/ Edit: a simple way to avoid thes…
The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.
Re: Unix Wildcards Gone Wild
#13David A. Wheeler, FOSS (and occasionally security) luminary, who also happens to be creator of the popular sloccount tool, has an excellent page that covers this topic and how to use paths safely and portably in shell scripts (spoiler: it's hard ) : http://www.dwheeler.com/essays/filenames-in-shell.html I strongly recommend his many other essays to HN readers: http://www.dwheeler.com/ Edit: a simple way to avoid thes…
The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.
Thanks! I had always figured that, along with long options, they were a GNU thing.
Re: Unix Wildcards Gone Wild
#14Tangentially, anyone know how to make zsh less greedy about parsing wildcards? Something like this will fail with "no files matched", and the command won't run:
rsync example.com:/foo/* .
Re: Unix Wildcards Gone Wild
#15Tangentially, anyone know how to make zsh less greedy about parsing wildcards? Something like this will fail with "no files matched", and the command won't run: rsync example.com:/foo/* . My workaround is to quote the argument, but it's annoying.
How about one of
rsync -a example.com:/foo/. .
rsync example.com:/foo/"*" .Re: Unix Wildcards Gone Wild
#16There's a reason this isn't talked about, it's not an actual legitimate/common vector to compromise a server.
Could you go into more details ?
Re: Unix Wildcards Gone Wild
#17Tangentially, anyone know how to make zsh less greedy about parsing wildcards? Something like this will fail with "no files matched", and the command won't run: rsync example.com:/foo/* . My workaround is to quote the argument, but it's annoying.
escape it, since you know the shell is going to be greedy about things.
rsync accepts globbing it's not a shell expansion that makes it work.
rsync example.com:/foo/\* .Re: Unix Wildcards Gone Wild
#18Even if you're using a tool that doesn't support "--" you can just use "./*" and everything will be fine.
Re: Unix Wildcards Gone Wild
#19 echo rm *
echo chown -R nobody:nobody *.php
echo chmod 000 *
echo tar cvvf archive.tar *
echo tar cf archive.tar *
echo rsync -t *.c foo:src
Later in the article we learn that it also assumes GNU utilities. That is a second problem (IMO), and arguably also one more serious than the behaviour of wildcards. GNU userland and unneeded complexity (e.g. more features than any user will ever use) are practically synonymous.
Then there is the peculiar assumption that someone can place arbitrary files beginning with - or -- on this system. That itself is a far more serious problem than the behaviour of wildcards; I would say with that capability it is more or less "game over". In BSD you have, at the very least, mtree. How does the Linux user know she isn't executing some substituted executable?
Moreover, if caution was important to the hypothetical user in the examples, I think they would be in the form
/path/to/program *Re: Unix Wildcards Gone Wild
#20I have worked with Linux systems since I was able to write and have heard about this the first time. Thanks HN \o/