Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is the DOS path character "\"? (2005)

web.archive.org

Post reply on HN
Print view View original

21–30 of 166 posts

Re: Why is the DOS path character "\"? (2005)

#21

Post by josefx »

est wrote: post #11
fjfaase wrote: post #3

One reason might be that DOS used the "/" character for options, whereas in other operating systems the "-" character is used.

I never understood why Unix chose "-" for options. It creates unnecessary confusion. E.g. when deleting a directory called "-rf"

Wouldn't / just cause confusion trying to delete a directory called /rf ?

Re: Why is the DOS path character "\"? (2005)

#22

Post by pram »

emptyparadise wrote: post #8
kiwidrew wrote: post #6

Thanks to Microsoft's recent release of the MS-DOS 2.0 source code, we can now peek under the hood and confirm that Microsoft specifically intended for the DOS 2.0 file APIs to be compatible with Unix. From XENIX.ASM [1], the code that implements the new API: ; ; xenix file calls for MSDOS ; TITLE XENIX - IO system to mimic UNIX And the CONFIG.DOC [2] file discusses the 'AVAILDEV' option which lets the system mimic U…

I really look forward to the day NT's source is released. It's a truly fascinating kernel. Imagine somebody building an entire Unix on top of NT! Like WSL, but even beyond.

Isn't that what SFU was?

Re: Why is the DOS path character "\"? (2005)

#23

Post by r00f »

Can anyone explain why was that a problem, from technical point of view? They already had paths starting with "driveletter:", not like unix with just "/". Why would it be a problem for parser to distinguish between filepaths and arguments switch?

Re: Why is the DOS path character "\"? (2005)

#24

Post by kaoD »

est wrote: post #11
fjfaase wrote: post #3

One reason might be that DOS used the "/" character for options, whereas in other operating systems the "-" character is used.

I never understood why Unix chose "-" for options. It creates unnecessary confusion. E.g. when deleting a directory called "-rf"

There's always going to be ambiguity.

rmdir /f /usr

Is that force-deleting the /usr directory, or the /usr and /f directories?

Re: Why is the DOS path character "\"? (2005)

#27

Post by eznzt »

est wrote: post #11
fjfaase wrote: post #3

One reason might be that DOS used the "/" character for options, whereas in other operating systems the "-" character is used.

I never understood why Unix chose "-" for options. It creates unnecessary confusion. E.g. when deleting a directory called "-rf"

For everybody reading, a directory called "-rf" is deleted by writing "rm -- -rf"; -- indicates the end of all user-provided options.

Re: Why is the DOS path character "\"? (2005)

#28

Post by bayindirh »

john4532452 wrote: post #14
emptyparadise wrote: post #8

Earlier quoted context omitted.

I really look forward to the day NT's source is released. It's a truly fascinating kernel. Imagine somebody building an entire Unix on top of NT! Like WSL, but even beyond.

What special about NT kernel that's not in linux kernel ?

It's a whole different paradigm and a popular one too. Just being able to look into it and get inspired is enough to be excited TBH.

Re: Why is the DOS path character "\"? (2005)

#29

Post by minxomat »

ganafagol wrote: post #10
est wrote: post #9

Earlier quoted context omitted.

Win2k and WinXP source code are leaked if I am not mistaken

Release != leak

Even the leaks contain enough of Microsoft's spirit in their comments: https://gist.github.com/turbo/75f0905275c29a3049f983cfe273ea...

;)

Re: Why is the DOS path character "\"? (2005)

#30

Post by st_goliath »

est wrote: post #11
fjfaase wrote: post #3

One reason might be that DOS used the "/" character for options, whereas in other operating systems the "-" character is used.

I never understood why Unix chose "-" for options. It creates unnecessary confusion. E.g. when deleting a directory called "-rf"

You can make that exact same argument irregardless of what switch character Unix uses. The real problem is not the switch character itself, but the approach used by standard Unix tools to "parse options until parsing fails, then assume it's an argument" which becomes an amazingly great foot gun if the actual option is inserted by a shell glob or a shell variable.
Post reply on HN