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

51–60 of 166 posts

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

#51

Post by shaoonb »

skissane wrote: post #35
est wrote: post #11

Earlier quoted context omitted.

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

Another viewpoint: the problem is caused by Unix allowing any character in filenames (other than slash and null). Other platforms are more restrictive in what characters filenames are allowed to contain. If you banned the '-' character from starting a filename, the problem wouldn't happen. I personally think Unix allowing almost any character in filenames was a mistake. You can put newlines and other control characte…

A coworker of mine got into trouble when he named a directory ~ and then tried to delete it.

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

#52

Post by scaladev »

tinus_hn wrote: post #50
john4532452 wrote: post #14

Earlier quoted context omitted.

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

* It is (with a lot of ifs and buts) a microkernel * it is optimized for integration with third party software from people who don’t have the source, so for instance the driver model is interesting * the built in configuration system (the registry) and how it’s used throughout * the (underused) personalities system you can use to show different apis to different binaries * the security model is much more interesting,…

>in Linux you have ‘root’ and everything else

Well, you do have:

- capabilities (which are so coarse-grained as to be practically useless)

- 8 types of namespaces

- seccomp-bpf

- LSM (AppArmor, SELinux, TOMOYO, etc)

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

#53

Post by tinus_hn »

scaladev wrote: post #48
tobias3 wrote: post #41

Earlier quoted context omitted.

No, like io_uring which Linux got in 2019 and still doesn't cover everything yet (e.g. currently mkdirat() is being added). It also often falls back to a kernel-level thread pool, since many e.g. file systems don't implement async IO.

>since many e.g. file systems don't implement async IO If we're picking on Linux here we should also mention that this issue cannot exist on Windows because it doesn't support anything else besides NTFS and a couple of options dating back to the 18th century or so. Oh, and WinFS, of course, F being short for future which is like the horizon, or the communism, always out there just a month or two away.

You can actually for example get drivers for APFS for Windows from third party vendors.

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

#56

Post by scaladev »

tinus_hn wrote: post #53
scaladev wrote: post #48

Earlier quoted context omitted.

>since many e.g. file systems don't implement async IO If we're picking on Linux here we should also mention that this issue cannot exist on Windows because it doesn't support anything else besides NTFS and a couple of options dating back to the 18th century or so. Oh, and WinFS, of course, F being short for future which is like the horizon, or the communism, always out there just a month or two away.

You can actually for example get drivers for APFS for Windows from third party vendors.

Sure, and there are third party drivers for ext* and btrfs and god knows what else… but we're talking about official support here, I think. You can find all sorts of craziness in out-of-tree patches for the Linux kernel.

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

#57

Post by sophistc »

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.

NT originally had a Unix subsystem: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

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

#58

Post by raverbashing »

scaladev wrote: post #52
tinus_hn wrote: post #50

Earlier quoted context omitted.

* It is (with a lot of ifs and buts) a microkernel * it is optimized for integration with third party software from people who don’t have the source, so for instance the driver model is interesting * the built in configuration system (the registry) and how it’s used throughout * the (underused) personalities system you can use to show different apis to different binaries * the security model is much more interesting,…

>in Linux you have ‘root’ and everything else Well, you do have: - capabilities (which are so coarse-grained as to be practically useless) - 8 types of namespaces - seccomp-bpf - LSM (AppArmor, SELinux, TOMOYO, etc)

Yes though a lot of this came "long after" the NT kernel (at least after NT 4.0)

A lot of innovations on NT are late as well to be fair, like the whole Application Views (?) of the system (basically an FS/Registry app sandboxing)

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

#59

Post by est »

kaoD wrote: post #24
est wrote: post #11

Earlier quoted context omitted.

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?

I mean on Windows it's

   rd /s /q \path\to\something
There's zero ambiguity because both "/" and "\" are special characters.

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

#60

Post by sophistc »

pjmlp wrote: post #45
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…

Well, there is this different timeline in the universe where Microsoft decides to keep selling Xenix instead of focusing on MS-DOS.

... and where it is not successful.
Post reply on HN