5 ms·

/Options are the norm for Windows (and uh cough VMS).

munificent 5y ago
Which is also why Windows uses backslash (\) as their path separator. Because forward slash would have collided with the slash option marker Windows inherited from VMS.
- throwawayboise 5y ago
  IIRC the "forward slash" convention for Windows command options traces back to DOS, not VMS. Where DOS inherited the convention from I do not know.
  - colejohnson66 5y ago
    CP/M https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M In longer words: Windows was originally a GUI system on top of DOS which was influenced by CP/M. The NT kernel did away with DOS, but the influence still lives to this day. For a simple one: not being able to name a file "con" (or any capitalized variation) comes all the way from CP/M. For the uninitiated: OSes from that era didn't have "directories"; Everything lived in the root of the drive, including device files. So, to print a file, you could literally do something like: A> type FILE.TXT > PRN When DOS added directories, they retained this "feature" so programs unaware of what directories were could still print by writing to the `PRN` "file". Because of "backwards compatibility", NT still has this "feature" as well.
  - JoBrad 5y ago
    Short article on this: https://web.archive.org/web/20150823053040/http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432386.aspx https://web.archive.org/web/20150823053040/http://blogs.msdn...
- kazinator 5y ago
  That is surprisingly false. Microsoft operating systems use both / and \ as a path separator, going all the way back to DOS. Early versions of MS-DOS made it a user preference option in the command.com interpreter, whether the user wanted to use / for options and \ for path separation or vice versa.
erik_seaberg 5y ago
One thing VMS got right is that each binary declared its supported options and the shell could tell you what they were. And it would take any unique abbreviation.
- ziml77 5y ago
  Powershell scripts and cmdlets work similarly. They probably won't have help text but at least you can see what's available without having to look at the argument parsing section of the script. And you can use the shortest unique prefix as the short form of an argument (though I don't love this since adding an argument can break the shortened form of other arguments)
  - JoBrad 5y ago
    It’s easy (although verbose) to add help text, and valid options, too.
    - ziml77 5y ago
      Also easy to create option sets so that mutually exclusive arguments are shown in the help as different ways to invoke the script.
      - TeMPOraL 5y ago
        And bunch of other niceties, all queryable without running the script, and all feeding autocomplete with useful information: https://news.ycombinator.com/item?id=26748549 https://news.ycombinator.com/item?id=26748549
bargle0 5y ago
They were for DOS, too. Not that I’m disputing the VMS roots of WNT.
tzs 5y ago
..and TOPS-10 and TOPS-20 and RT-11 and RSX-11 and RSTS-11.

Which is also why Windows uses backslash (\) as their path separator. Because forward slash would have collided with the slash option marker Windows inherited from VMS.

throwawayboise 5y ago
IIRC the "forward slash" convention for Windows command options traces back to DOS, not VMS. Where DOS inherited the convention from I do not know.
- colejohnson66 5y ago
  CP/M https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M In longer words: Windows was originally a GUI system on top of DOS which was influenced by CP/M. The NT kernel did away with DOS, but the influence still lives to this day. For a simple one: not being able to name a file "con" (or any capitalized variation) comes all the way from CP/M. For the uninitiated: OSes from that era didn't have "directories"; Everything lived in the root of the drive, including device files. So, to print a file, you could literally do something like: A> type FILE.TXT > PRN When DOS added directories, they retained this "feature" so programs unaware of what directories were could still print by writing to the `PRN` "file". Because of "backwards compatibility", NT still has this "feature" as well.
- JoBrad 5y ago
  Short article on this: https://web.archive.org/web/20150823053040/http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432386.aspx https://web.archive.org/web/20150823053040/http://blogs.msdn...
kazinator 5y ago
That is surprisingly false. Microsoft operating systems use both / and \ as a path separator, going all the way back to DOS. Early versions of MS-DOS made it a user preference option in the command.com interpreter, whether the user wanted to use / for options and \ for path separation or vice versa.

erik_seaberg 5y ago

One thing VMS got right is that each binary declared its supported options and the shell could tell you what they were. And it would take any unique abbreviation.

ziml77 5y ago
Powershell scripts and cmdlets work similarly. They probably won't have help text but at least you can see what's available without having to look at the argument parsing section of the script. And you can use the shortest unique prefix as the short form of an argument (though I don't love this since adding an argument can break the shortened form of other arguments)
- JoBrad 5y ago
  It’s easy (although verbose) to add help text, and valid options, too.
  - ziml77 5y ago
    Also easy to create option sets so that mutually exclusive arguments are shown in the help as different ways to invoke the script.
    - TeMPOraL 5y ago
      And bunch of other niceties, all queryable without running the script, and all feeding autocomplete with useful information: https://news.ycombinator.com/item?id=26748549 https://news.ycombinator.com/item?id=26748549

bargle0 5y ago

They were for DOS, too. Not that I’m disputing the VMS roots of WNT.

tzs 5y ago

..and TOPS-10 and TOPS-20 and RT-11 and RSX-11 and RSTS-11.