3 ms·

David A. Wheeler, FOSS (and occasionally security) luminary, who also happens to be creator of the popular sloccount tool, has an excellent page that covers thi

David 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 http://www.dwheeler.com/essays/filenames-in-shell.html I strongly recommend his many other essays to HN readers: http://www.dwheeler.com/ http://www.dwheeler.com/ Edit: a simple way to avoid these problems is to prepend the wildcard with ./ (so globbed files won't start with - or -- but with the path ./) and on GNU systems put -- before the wildcard, telling the tool that following arguments are not options.

teddyh 12y ago
The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.
- AceJohnny2 12y ago
  Thanks! I had always figured that, along with long options, they were a GNU thing.
  - _delirium 12y ago
    There's some digging here: http://unix.stackexchange.com/questions/147143/when-and-how-was-the-double-dash-introduced-as-an-end-of-options-delimiter http://unix.stackexchange.com/questions/147143/when-and-how-... Looks like the convention was introduced as part of getopt in AT&T Unix System III (1980), though initially only in a handful of places. Then POSIX adopted it as standard for all utilities sometime later.
  - deleted 12y ago
    [deleted]
  - emmelaich 12y ago
    They were quite distinct. When --longopt was starting to get popular (in an ad-hoc way) for gnu and other utilities there was a poll (gnu.misc? late 90s?) whether to make it a gnu standard. The other choices were a +, or have commands not accept both bundled single letter options and longopts. There may have been other choices I've forgotten about. The double-dash won. There were some people who were concerned that it might be confused with the end-of-args double dash. Maybe that is true but they are certainly unambiguously parsed.
pmahoney 12y ago
> portably in shell scripts (spoiler: it's hard) At what point do you give up and, if you must have portability, bootstrap a saner environment? Are there many options in this area? Assume perl is available? Use autoconf-like shell script compiler? Starting with Lua (which I hope/assume can build anywhere, though I know it's missing lots of functionality out of the box)?
- AceJohnny2 12y ago
  I'm lucky not to have to worry about this, but I figured that having Perl is a safe assumption for desktop and server Unix systems. Not embedded devices, but I guess those are different enough that you're probably not targetting them for portable scripts. Oh no, have I contradicted myself? :)

teddyh 12y ago

The double dash -- to stop option parsing is not a GNU thing – it comes from the POSIX standard.

AceJohnny2 12y ago
Thanks! I had always figured that, along with long options, they were a GNU thing.
- _delirium 12y ago
  There's some digging here: http://unix.stackexchange.com/questions/147143/when-and-how-was-the-double-dash-introduced-as-an-end-of-options-delimiter http://unix.stackexchange.com/questions/147143/when-and-how-... Looks like the convention was introduced as part of getopt in AT&T Unix System III (1980), though initially only in a handful of places. Then POSIX adopted it as standard for all utilities sometime later.
- deleted 12y ago
  [deleted]
- emmelaich 12y ago
  They were quite distinct. When --longopt was starting to get popular (in an ad-hoc way) for gnu and other utilities there was a poll (gnu.misc? late 90s?) whether to make it a gnu standard. The other choices were a +, or have commands not accept both bundled single letter options and longopts. There may have been other choices I've forgotten about. The double-dash won. There were some people who were concerned that it might be confused with the end-of-args double dash. Maybe that is true but they are certainly unambiguously parsed.

pmahoney 12y ago

> portably in shell scripts (spoiler: it's hard) At what point do you give up and, if you must have portability, bootstrap a saner environment? Are there many options in this area? Assume perl is available? Use autoconf-like shell script compiler? Starting with Lua (which I hope/assume can build anywhere, though I know it's missing lots of functionality out of the box)?

AceJohnny2 12y ago
I'm lucky not to have to worry about this, but I figured that having Perl is a safe assumption for desktop and server Unix systems. Not embedded devices, but I guess those are different enough that you're probably not targetting them for portable scripts. Oh no, have I contradicted myself? :)