10

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?

  • 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.) – Stephen Kitt Sep 8 '17 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 '17 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 '17 at 11:08
  • 1
    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 '17 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 '17 at 21:08
6

History

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.

  • 1
    "(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 '17 at 19:34
  • @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 '17 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). – Jerry Coffin Sep 9 '17 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 '17 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 '17 at 15:06

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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