3 ms·

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M FORMAT C: /S /U The option-indicator in UNIX-like systems was

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M FORMAT C: /S /U The option-indicator in UNIX-like systems was the dash/hyphen '-' ls -al

Joe_Cool 2y ago
thats why it also works without any spaces DIR C:/p/s/w Doesn't do what you might expect.
glandium 2y ago
And the article points out it's NOT a carry-over from CP/M.
- dirkt 2y ago
  And I am not sure if their argument holds water. CP/M is clearly influenced by DEC usage [1], and various DEC OS and tools had slashes for tool options as a standard. Those then got carried over to CP/M (e.g. PIP), so that was the standard way to define options everyone CP/M used would have known. It's really really hard to imagine the usage for slashes as arguments was not a carry over. And for anyone old enough to actually remember the transition from CP/M to MS-DOS (like me), it felt very natural. [1] https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
  - fanf2 2y ago
    As the article explains, CP/M PIP uses [ ] for options, not /
skissane 2y ago
> Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M It wasn't a carry-over from CP/M itself. The utilities shipped with CP/M itself didn't use slash as an option character. PIP put options in square brackets. It was a carry-over from Microsoft's programming tools for CP/M. And, as the article points out, Microsoft appears to have borrowed that syntax from DEC TOPS-10, where it originated
lproven 2y ago
[Article submitter here] > a carry-over from CP/M No, it wasn't, and I posted this correcting someone else on HN sharing this disinformation. CP/M does not have command switches as standard. There is no standard separator because it didn't support switches. (Some programs did on their own.) Didn't you RTFA before posting this -- gods, I hate the term -- fake news?

Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M FORMAT C: /S /U The option-indicator in UNIX-like systems was the dash/hyphen '-' ls -al

Joe_Cool 2y ago

thats why it also works without any spaces DIR C:/p/s/w Doesn't do what you might expect.

glandium 2y ago

And the article points out it's NOT a carry-over from CP/M.

dirkt 2y ago
And I am not sure if their argument holds water. CP/M is clearly influenced by DEC usage [1], and various DEC OS and tools had slashes for tool options as a standard. Those then got carried over to CP/M (e.g. PIP), so that was the standard way to define options everyone CP/M used would have known. It's really really hard to imagine the usage for slashes as arguments was not a carry over. And for anyone old enough to actually remember the transition from CP/M to MS-DOS (like me), it felt very natural. [1] https://en.wikipedia.org/wiki/CP/M https://en.wikipedia.org/wiki/CP/M
- fanf2 2y ago
  As the article explains, CP/M PIP uses [ ] for options, not /

skissane 2y ago

> Because the '/' in MSDOS was already in use as an option-indicator - a carry-over from CP/M It wasn't a carry-over from CP/M itself. The utilities shipped with CP/M itself didn't use slash as an option character. PIP put options in square brackets. It was a carry-over from Microsoft's programming tools for CP/M. And, as the article points out, Microsoft appears to have borrowed that syntax from DEC TOPS-10, where it originated

lproven 2y ago

[Article submitter here] > a carry-over from CP/M No, it wasn't, and I posted this correcting someone else on HN sharing this disinformation. CP/M does not have command switches as standard. There is no standard separator because it didn't support switches. (Some programs did on their own.) Didn't you RTFA before posting this -- gods, I hate the term -- fake news?