3 ms·

>The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" ... "-" ... The reasons

by jasode 11y ago

>The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" ... "-" ... The reasons were technical[1] instead of a stubborn resistance. The hyphen "-" was allowed in DOS/Windows filenames. The "/" was not. Therefore, if you programmed your command utility to use "-" as command line switches to match UNIX convention, your app would be "broken" because it couldn't accept filenames that began with hyphens such as "-verify.txt" If you then try to mitigate that with an "escape" switch such as double-hyphen "--" to turn off the hyphen processing, that means you can't operate on files that are named as "--". (Viruses and malware love creating files with legal filenames that utilities can't open.) So then you layer another hack on top of that and create the mother of all escape sequences with something like "--switch_character=-" (and then cross your fingers that nobody has a file that's actually named "--switch_character=-". (Arguably, you could make "myapp -- --" be unambiguous by imposing a rule that position is significant (the 1st "--" is parsed as a semantics switch, and the 2nd "--" is parsed as the oddly named file) but now you've given up the flexibility of specifying parameters in any order which many UNIX utilities do allow.) Instead of all that complication, you just let "/" be the switch character and it's easier because "/" is already an illegal character for filenames. (When in Rome...[2]) [1]https://en.wikipedia.org/wiki/8.3_filename#Directory_table https://en.wikipedia.org/wiki/8.3_filename#Directory_table [2]https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans_do https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Roman...

bluefinity 11y ago
I don't think that's the reason, you could just quote the filename (which is commonly done if the name contains spaces anyway): myapp "-verify.txt"
- jasode 11y ago
  Relying on quotes as special characters is not that simple to parse either: http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx http://blogs.msdn.com/b/twistylittlepassagesallalike/archive... That article also doesn't go into the difficulties of quotes in legacy DOS apps. Passing/ignoring quotes in DOS command lines was extremely difficult compared to the Win32 API. The CMD.EXE would eat the quote delimiters and your app wouldn't even see them. (It's been many years since I last tested this so a new OS like Windows 10 may have changed things.)
voyou 11y ago
Except that Unix also allows "-" in the filename, and as far as I know always has done. Using "--" to mark that all subsequent arguments should be treated as filenames rather than options has worked fine to allow Unix programs to access files beginning with a dash (including files called "--"). The actual reason that DOS uses "/" to mark options isn't technical, it's purely historic: that was the character that CP/M used.
- jasode 11y ago
  It's technical in the sense that the historical decision was already made at the OS layer and subsequent DOS/Win programmers have to work with it in the app layer. Yes, 40 years ago, the decision was arbitrary not technical.
- Someone1234 11y ago
  And UNIX allowing - in filenames is a massive security problem[0]. If you go grab a bunch of random scripts off of GitHub many of them won't correctly escape filenames, and a specially named file can alter how the script executes. [0] http://www.net-security.org/article.php?id=2061 http://www.net-security.org/article.php?id=2061
  - lottin 11y ago
    The security problem is incompetent programmers, not dashes, then.
    - Someone1234 11y ago
      Users and programmers. It is trivial to mistakenly execute a command on the shell which is subject to this issue. I'd call the behaviour "dangerous by default." You need specific training to be aware of, and overcome the issue, without the training you're likely executing commands which can be taken advantage of (in particular recursive commands over files and directories you yourself don't control).

by jasode 11y ago

bluefinity 11y ago

I don't think that's the reason, you could just quote the filename (which is commonly done if the name contains spaces anyway): myapp "-verify.txt"

jasode 11y ago
Relying on quotes as special characters is not that simple to parse either: http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx http://blogs.msdn.com/b/twistylittlepassagesallalike/archive... That article also doesn't go into the difficulties of quotes in legacy DOS apps. Passing/ignoring quotes in DOS command lines was extremely difficult compared to the Win32 API. The CMD.EXE would eat the quote delimiters and your app wouldn't even see them. (It's been many years since I last tested this so a new OS like Windows 10 may have changed things.)

voyou 11y ago

Except that Unix also allows "-" in the filename, and as far as I know always has done. Using "--" to mark that all subsequent arguments should be treated as filenames rather than options has worked fine to allow Unix programs to access files beginning with a dash (including files called "--"). The actual reason that DOS uses "/" to mark options isn't technical, it's purely historic: that was the character that CP/M used.

jasode 11y ago
It's technical in the sense that the historical decision was already made at the OS layer and subsequent DOS/Win programmers have to work with it in the app layer. Yes, 40 years ago, the decision was arbitrary not technical.
Someone1234 11y ago
And UNIX allowing - in filenames is a massive security problem[0]. If you go grab a bunch of random scripts off of GitHub many of them won't correctly escape filenames, and a specially named file can alter how the script executes. [0] http://www.net-security.org/article.php?id=2061 http://www.net-security.org/article.php?id=2061
- lottin 11y ago
  The security problem is incompetent programmers, not dashes, then.
  - Someone1234 11y ago
    Users and programmers. It is trivial to mistakenly execute a command on the shell which is subject to this issue. I'd call the behaviour "dangerous by default." You need specific training to be aware of, and overcome the issue, without the training you're likely executing commands which can be taken advantage of (in particular recursive commands over files and directories you yourself don't control).