I'm so happy to see arguments specified with "-" and "--" (UNIX-style) instead of "/" (DOS-style).
The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" won the battle for folder path separators (see: URLs) and "-" won the battle for argument delimiters.
>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])
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.
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.
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.)
Fun fact: most MS kernels, including DOS, supported "/" as a path separator. They were just filtered out of the command lines by the argument passing code.
There was a system call which would tell the argument parser that you wanted a different switch character, and if you changed it to, say, "-", then "/" would work. Of course, not everything used the standard argument parser, so if you did change this you ended up in a world of pain because your tools would start behaving inconsistently, but it was theoretically possible.
I've seen references to this code existing as late as XP, but I don't do Windows any more, so can't comment on later versions.
In terms of file path, windows seems to always support \\ or /, both in API or in software like Explorer. That's still true for Windows 10.
That leads to some interesting answers on stackoverflow sometimes about cross compatibility, where the correct answer of "use whatever constant your language has for directory separator" gets down-voted in favor of "use forward slash everywhere".
Many applications assume \ and deal with paths directly, instead of using the Windows APIs for path manipulation.
This means the moment your application gives a / to another application, there is a high probability that it will break, regardless of what the Windows API supports.
But a path in windows is very unlikely to start with / ... went through some serious pain trying to pass the command options to a windows program from a bash script last night in fact, so it's very fresh in my memory.
LOL, just last night I was updating my start-ssh-agent[1] script for bash in windows to parallel the logic of the cmd file that comes with msysgit[2]. I spent hours trying to figure out a way to pass `/IM` to taskkill without it expanding out to `/c/.../IM` from bash itself... before finally finding a solution[3], when I stopped searching for a generic answer[4].
The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" won the battle for folder path separators (see: URLs) and "-" won the battle for argument delimiters.