Comment by jasode | Hacker News Reader

Comment by jasode | Hacker News Reader

Parent Full thread

>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

[2]https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Roman...

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.

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

The security problem is incompetent programmers, not dashes, then.

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).

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.

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"

Relying on quotes as special characters is not that simple to parse either:

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.)

Reply on news.ycombinator.com