In Linux we have command line switches traditionally started with minus ls -al. In Windows those start with slash dir /b.

I remember that on RSX-11M that I used to deal with and later on RT-11 the switches where traditionally slashes. This means that Windows did not invent the slash as a command line switch, it simply used an existing convention, albeit different from Linux.

Is it known who when and why came up with these different types of command line switches?

  • 1
    An interesting curiosity is that MS-DOS supports both - and / to introduce command line switches, and can be configured either way. (Many third-party tools only work with / though so it’s not that useful in practice.) Sep 8, 2017 at 6:53
  • 1
    BTW, you can trace the switches right from the various DEC PDP OS's (e.g. OS/8) via CP/M to MS-DOS and then to Windows, from DEC to VMS, and also to Unix. But I don't know if the origin predates DEC.
    – dirkt
    Sep 8, 2017 at 8:19
  • Not sure if the origin of using / as the directory separator in Unix but that is almost certainly the reason for using - for switches... otherwise it would be difficult or impossible to parse command lines and know which arguments were switches and which were paths.
    – mannaggia
    Sep 8, 2017 at 11:08
  • 2
    As @StephenKitt said, starting with MSDOS 2.0, you could put SWITCHAR=- in config.sys and intrinsic commands in command.com would allow - for switches instead of /. I think some external command respected this also but since there was no DOS API call to parse command lines, rarely did 3rd party software respect this and they hard coded / for switches. Additionally, internally, DOS and Windows API calls will allow either / or \ for a directory separator in a pathname, regardless of SWITCHAR.
    – mannaggia
    Sep 8, 2017 at 11:13
  • The number of unshifted, non-modifier (and, thus, easy to reach), non-letter/number keys on a classical US keyboard is limited - "#+.," are somewhat semantically occupied already, so the next choice would have been "-" and "/". Unix chose "/" for the path separator, so that was occupied as well and left only "-". DOS and VMS could pick "/" as well.
    – tofro
    Sep 8, 2017 at 21:08

1 Answer 1



Unix' style of command line handling is clearly inherited from GE's Multics, as much as its name is a play on Multics. This incudes the hypen (-) as token. In Multics it was called a Control Argument. Multics itself may have inherited it from DECs TOPS-10, or more exact the PDP-6 Monitor program as it originally was called.

The popularity of Mutics at universities, together with many DEC installations at such places, can be seen as the major influence in next to all later systems.

Data Generals RDOS/AOS, in itself a child of DEC trained people (and DECs RSX-11 as direct competition) might have been the first to use a slash (/) as token.

(I still think the Multics path seperator looks more natural >etc>bin - too bad Unix diverted here)

Comparsion with Mainframes

Next to all modern mini- / micro-computer OS commandline uses spaces as seperators between arguments and a dedicated token to indicate parameter names, which can stand for themself (switches) i.e. have no value assigned.

Example: command arg1 arg2 -name1 val -name2

In contrast mainframe cli/script environments are based arround comma (,) seperated arguments where parameter names are seperated by an equal/assignment (=) sign from their value. Enpty values revert usually to the same default as if not present, therefore whats a lone switch elsewhere must here be accompanied by a (legal) value to enable the option.

Example: command arg1,arg2,name1=val,name2=yes

The mainframe style has some advantages due less ambiguity, but is often considerete bloaty. Technical not true. It's rather that mainframe command designers love to have nice redable names, so it does get lengthy ... then again, GNU style parameter lists can easy spread over multiple lines.

  • 2
    "(I still think the Multics path seperator looks more natural >etc>bin - too bad Unix diverted here)" -- I disagree. I'm ambivalent on its use as a path separator, but I am however convinced that it is the right and natural character to use for stream redirection, so if Unix had used it for path separators it wouldn't have been available for that purpose.
    – Jules
    Sep 8, 2017 at 19:34
  • 1
    @Jules I guess it's a matter of personal taste. I'm in fact not realy in favour for any use of special symbols. Guess what, I've worked decades in manframe environments, where everything is less fancy :))
    – Raffzahn
    Sep 8, 2017 at 21:17
  • 1
    You say "mainframes", but seem to really mean "IBM mainframes". To give one contrasting example, Control Data's command language for NOS used punctuation that looked like a series of function calls: foo(bar, baz). Sep 9, 2017 at 15:29
  • @JerryCoffin You're right, NOS as well followed the style of simple comma seperated lists instead of markers. Just, parameter lists in parentheses where also in use on the IBM side. Having worked with both, I say they still fall into one cathegory, distincly different from the DEC/Unix lineage, and that's the point I tried to make here.
    – Raffzahn
    Sep 9, 2017 at 16:08
  • 1
    @JerryCoffin IIRC, the "command language" (SCL?) for ICL's 39-series (VME) machines also used parentheses and, I think, favoured a name=value syntax. Made-up example: delete( file=BringBackGeorgeIII.txt ).
    – TripeHound
    Sep 12, 2017 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.