Live data from Hacker News

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

web.archive.org

141–150 of 166 posts

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

#141

Earlier quoted context omitted.

Mind blown. C is truly a terrifying language and I can’t help but love it for that.

It was designed in a time where keyboards around the world (German QWERTZ, Cyrillic JCKUEN/ЙЦУКЕН) and text encoding (remember that this is pre-Unicode, so we're dealing with ISO 646 and Eastern Asian character sets) has only the subset of Latin characters used in the US. Nowadays, it is strongly recommended to simply use the standard American keyboard in programming (outside of comments).

I still cannot decide whether it's better to comment in English or in my native language. English works, but it's a weird fit with words from the application domain. Those, I don't really want to translate, but I have to keep doing it because there is so much legacy code with the translations. Sure, I could do a rampage through the code base and fix everything up (would be done in an afternoon thanks to IntelliJ), but my team would almost certainly give me lots of flak for this. At the same time, it also feels weird to conjugate english words in my native language.

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

#142
post #91

Earlier quoted context omitted.

Proper support for paged kernel memory? Async-by-default I/O? Must better power management (compare win vs linux battery life on same hardware).

> Async-by-default I/O? What? Can you elaborate? I mean if you want non blocking IO from an fd in Linux, you can just do that. Not sure what defaults have to do with anything. Your code will still have to be written appropriately.

Default in linux is read()/write() and be blocked. Doing async is a lot more work and until relatively (to NT timelines) recently quite limited (select).

On NT the standard way is async, and doing things in the block-and-wait way is abnormal and unusual.

Defaults matter. Because that's what most people will do.

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

#143
post #75

Earlier quoted context omitted.

I have to suppress the urge to correct people both when they refer to it as a backslash and when they use the term "forward slash". I've already lost all my friends by being that guy; I don't need to also earn the enmity of random strangers on the internet. But technically it's a solidus not a slash.

Nothing is wrong with "forward slash.

"forward slash" vs. "forward backslash" would be more consistent.

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

#144
post #82

Where it says FileName.Extension[,Version] MONITR.EXE,4 What was the version used for? Did it track the changes?

I don't know about DEC-20, but on VMS, changing a file makes a copy with a new version number: $ edit foo.txt ... Ctrl-Z $ dir foo.txt;1 $ edit foo.txt ... Ctrl-Z $ dir foo.txt;1 foo.txt;2 When you delete a file, you have to specify a version field (blank for latest): $ del foo.txt; $ dir foo.txt;1 IIRC, you can configure how many versions to keep.

Yes that's right, the versions to retain was configurable, and the whole versioning mechanism was really useful and a great miss from today's OSes. The VMS file and directory syntax otoh was a real pain, Unix definitely wins there.

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

#145

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 ?

Is the fact that it's a very stable and robust kernel that evolved over different means, with different priorities and expectations not enough?

The kernel itself is very interesting, regardless of what happened in the Linux world. If all you ever look at is Linux, you get stuck in Linux ideas of how things should, or even can, be done.

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

#146

Earlier quoted context omitted.

i've just started calling it "shift 3". that seems to be the least confusing way to communicate the character haha

That will usually work in the US, but Shift-3 returns £ on keyboards configured for the UK!

Is that related in any way to the fact that both symbols can be referred to as a 'pound' symbol, or is it a complete coincidence?

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

#147

>*nix defines hierarchical paths with a simple hierarchy rooted at "/" - in *nix's naming hierarchy, there's no way of differentiating between files and directories, etc (this isn't bad, btw, it just is). I don't see the problem, but I guess it's just a personal preference.

>this isn't bad,btw,it just is

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

#148
post #106

Earlier quoted context omitted.

Except that on Windows, you can use "C:/path/to/something" nearly everywhere where it accepts "C:\path\to\something".

Except C:/ is not a command option, and only Unix people would write "/"

Sounds a bit provincial. That might have been true before mainstream internet access, but the average user these days is likely more familiar with unix style paths via URLs than local filesystem paths.

Also, most non-unix operating systems that don't happen to be made by Microsoft also use the forward slashes for paths.

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

#149
post #47

In addition to its use as a path separator in DOS and Windows, the backslash character itself is also interesting because it is very likely a modern invention, with the first attestation in 1940s (!). Its original use in ASCII (1960s) was for ALGOL operator digraphs `\/` and `/\`. Its early use as the C escape sequence (1970s, replacing `*` in BCPL) suggests that it carried no significant semantics at that time.

C also has trigraphs, in case your keyboard does not have a \ you can type ??/ instead. https://en.wikibooks.org/wiki/C_Programming/C_trigraph

I wonder how many regex security filters would break using ??/ for escape because very few people know this exists.

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

#150
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.

[deleted]
Post reply on HN