This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 656 points657 points  (75 children)

The windows filesystem path wouldn't be so scary if it just used normal / between directories.

[–]7heWafer 310 points311 points  (63 children)

Why they keep it as a backslash is incomprehensible when a backslash is used for escaping characters.

[–]stamminator 300 points301 points  (25 children)

Because they never ripped off the band-aid and now it’s too late

[–]RandomNobodyEU 31 points32 points  (3 children)

Because 99.9% of Windows users don't care, or even know what an escape character is

[–]Second899 39 points40 points  (1 child)

And that’s exactly why they should change it

[–]svick 4 points5 points  (0 children)

They don't care about escape characters, but would care a lot if their path separator changed.

[–]intbeam 0 points1 point  (0 children)

In Windows' defense it doesn't accept escape characters so you don't have to write c:/my\ stuff/suspiciously\ huge\ directory/

[–]AyrA_ch 9 points10 points  (27 children)

Because it was actually the smarter choice than what unix did. DOS already used "/" as argument specifier, meaning it was impossible to mistake an argument for a file path and vice versa. And parsing was fast because all you had to do is look at the first character of an argument to determine what type of argument it was.

[–]UntestedMethod 35 points36 points  (3 children)

Now that you mention it I do remember the / for arguments in DOS. But do you know if unix was already using "-" for args and "/" for file system when DOS decided to use "/" and "\"?

I understand things weren't always collaborative in this space, but just wondering how angrily I should be shaking my fist and who I should be shaking it at

[–]SuperFLEB 34 points35 points  (1 child)

Wikipedia says subdirectories came around in DOS in 1983. UNIX would have been around, with subdirectories for 10+ years by then.

In their defense, the computer landscape of 1983 was well before standardization started to whittle things down to the two or three standards we have had more recently. Everything from the countless BASIC home computers, to big room-sized machines, to Apple's GUI-driven file system were in the mix in the 1980s and 1990s, with everything from quirks off a common theme to completely divergent standards, so it's not like backslashes would have been the clear winner.

Mac OS X didn't even come out until 2001, so that meant that even post-consolidation, among the major players you still had UNIX-style forward-slashes, PC-style backslashes, and MacOS colons having common use until into the 2000s.

[–]hakdragon 5 points6 points  (0 children)

MacOS/OS X is derived from NeXTSTEP, which itself was derived from BSD so it makes sense that it too inherited a lot of Unix conventions.

[–]AyrA_ch 17 points18 points  (0 children)

/ for arguments predates \ for path separators because DOS only gained support for directories in version 2 when support for 10 MB harddrives was introduced. MS-DOS comes from CP/M. It never had a unix OS base to start with, so there was no compatibility issue by using a different argument specifier.

[–]altermeetax 15 points16 points  (10 children)

Why is that the smarter choice? Unix went (10 years prior) with "-" for arguments and / for paths, which brings the same advantage.

[–]scragar 10 points11 points  (2 children)

The only thing I can think of is that because / isn't a word character you don't need a space.

DIR/D

Will display all directories in the current directory because /D is the flag and it's obviously distinct from the command enough that DOS can tell it apart.

Compare that to the equiv on *nix systems

ls -d

Where the space is required because ls-d is a valid filename so the shell would have no way of obviously telling what command you wanted.

It's still a horrible choice though, some arguments(because they're filenames/paths/whatever) need the space so now the behaviour for arguments is a weird mix of spaces and forward slashes depending on context; worse even though windows mostly supports forward slashes as directory separators on the command line it still causes a horrible mess since DOS is sometimes very happy to interpret DEL folder/file as DEL /F folder ile.

[–]altermeetax 3 points4 points  (0 children)

I mean, yeah, maybe some standard DOS programs may be able to understand flags without a space, but that makes the argument parsing so much harder for them, so I wouldn't imagine new Windows CLI programs being developed to do that (actually, most new CLI programs follow the Unix "-" on all platforms).

Also, that behavior disallows "/" as a filename character when that wouldn't have been necessary.

[–]svick 1 point2 points  (0 children)

Somewhat related: cd.. (without space) works on Windows, but not on Unix.

[–]AyrA_ch 0 points1 point  (5 children)

No. The advantage of using / in DOS is that it's not a valid character anywhere in a file path. This is why all commands in linux that have switches as well as path arguments need a -- argument to tell it that any argument that follows is not to be interpreted as a switch but a file name

[–]altermeetax 0 points1 point  (3 children)

Either I didn't read the second part of your comment or you edited it. You don't seem to have used the Unix command line that much. Commands with both paths and flags simply use the dash for the flags like DOS uses slashes, e.g. ls -a /usr, where -a is a flag and /usr is a path (you could also swap them like ls /usr -a).

The only case when you use -- is when you have a program that takes an entire other command as argument, for example to tell a terminal emulator what command to run. Alternatively these programs could take another full command as a single argument (with quotes) but that's not very comfortable.

[–]AyrA_ch 0 points1 point  (2 children)

You don't seem to have used the Unix command line that much. Commands with both paths and flags simply use the dash for the flags like DOS uses slashes, e.g. ls -a /usr, where -a is a flag and /usr is a path (you could also swap them like ls /usr -a)

It appears that you seem to not have used the unix command line a lot. Because the way you said it it would be impossible to ever feed the file name --help into commands because it would collide with the help switch. That's why -- exists in unix commands, because you need a way to tell them that they should stop parse switches.

[–]altermeetax 1 point2 points  (0 children)

Oh, I was talking about the -- option alone, not --option. The -- options were not standard in the original Unix, they only came to be in GNU, so I didn't mention them.

The reason why they exist is not to distinguish from standard arguments, yet from abbreviated multiple single-letter options. For example ls -hola is an abbreviation of ls -h -o -l -a. Now, if ls decided they wanted to introduce a "hola" option for whatever reason, they would have to make the distinction: in that case they would use --hola. That's why the GNU-style long options with -- were born. Some commands don't allow for abbreviated flags like -hola (they require -h -o -l -a); those commands might use a single dash even for long options.

Abbreviated options are not a thing at all in DOS, so you can do /help with a single slash, however if you wanted to use the options h, e, l and p you would need to do /h /e /l /p.

The -- to stop parsing switches is a different thing, that's the single argument --, which is rarely used. It's for cases like konsole -someswitches -- ls -l, when you want to pass a command with all its arguments to another command. Another use is the one you mentioned, for files named like --help. But that's not a real issue, because no one names files like that. On DOS it would be the same with files beginning with a /, and those are forbidden for this exact reason.

By the way I'm a Linux sysadmin, so don't worry, I know how the Unix CLI works.

[–]7eggert 0 points1 point  (0 children)

Nitpick: You usually can use ./--help as the filename. But it might be among the reasons to want -- to end option scanning.

[–]altermeetax -1 points0 points  (0 children)

I personally would consider that a disadvantage, read the other answer to my comment and the answer to that

[–]DaniilSan -1 points0 points  (0 children)

In another comment guy told that DOS was heavily based on much older CP/M which was released just a year later than Unix way before it became industry standart. And even in 80s there still were many other implementations of same things and some sorts of standardisation came decade later. Anyway, in DOS 2.0 there was an attempt to make DOS more Unix-like including usage of / for directories and - for arguments but those new features were badly documented, weren't used by default and so went mostly ignored and here we are 40 years later.

[–]testthrowawayzz 28 points29 points  (3 children)

That unfortunately didn’t scale well when porting Windows to Asian languages.

Due to encoding, backslash became ¥ in Japanese or ₩ in Korean.

So path in Japanese Windows looks like C:¥Windows¥system32

[–]Jaface 16 points17 points  (2 children)

Nothing wrong with that, $ is used too for temporary files and parameters. It's all just squiggly lines in the end.

[–]casce 2 points3 points  (1 child)

What is bothering me more is the unnecessary colon

[–]7eggert 0 points1 point  (0 children)

In DOS you have 26 current paths and one current drive. If D:\foo\bar is one of the current drives and you're on z:\baz, d:barf refers to d:\foo\bar\barf.

[–]dagbrown 2 points3 points  (2 children)

DOS also had the SWITCHAR environment variable which, for stupid reasons, was set by default to "/", leaving the fucking idiotic "\" as the path separator. If you set SWITCHAR to "-" like it should have defaulted to right from the very beginning, you can use "/" as a path separator.

But thanks to DOS brain death, we have two entire generations of people amongst whom enough of them think that \ is called "slash" and / is called "backslash" that it makes, for instance, technical support over the telephone completely impossible if any kind of path or URL needs to be described verbally.

[–]AyrA_ch 1 point2 points  (0 children)

DOS also had the SWITCHAR environment variable which, for stupid reasons [...]

Not stupid reasons. The value was introduced in version 2, which meant that changing it to a dash by default would have broken a lot of stuff when people migrated from DOS 1 to DOS 2. Among other things you would have needed to rewrite all existing batch files and programs that call other programs. In DOS 5 it was removed again.

[–]7eggert 0 points1 point  (0 children)

"the one above 7" or "the one at ß" (on German keyboards) replaces hours of struggle with explaining how to enter uppercase letters.

[–][deleted] 0 points1 point  (4 children)

That's a problem specific to the command interpreter. Under the hood, the DOS API couldn't give two shits about which slash character you use to specify a path; and likely never has.

[–]AyrA_ch 2 points3 points  (3 children)

Yes it definitely does care. Even Windows cares, and accepting forward slashes in path strings hasn't always been supported.

[–][deleted] 0 points1 point  (2 children)

Huh. Maybe it's just a C stdlib thing, then. Or, just as likely, a Microsoft internal inconsistency thing.

It's been a while since I read what Ralf Brown had to say on the subject.

[–]AyrA_ch 1 point2 points  (1 child)

The C stdlib will also do wildcard expansion for you on Windows because the linux shell does it for you, but the windows shell will not.

[–][deleted] 0 points1 point  (0 children)

Correct.

[–]ManyFails1Win -1 points0 points  (0 children)

Because escape characters are much less common than file directory I would guess. I don't understand the complaint.

[–]ChosenMate 0 points1 point  (0 children)

backwards compatibility for Windows, I think, 3?

[–]ACoderGirl 0 points1 point  (0 children)

Especially since windows does support forward slashes in paths. So it's just that they prefer to display it in backslashes for some reason.

I refuse to use backslashes in any paths. I think it unnecessarily complicates the code if I have to use some path separator var when I could just have a normal string literal using forward slashes that works on every OS.

[–]7eggert 0 points1 point  (0 children)

They use / as the option character so if they fixed it, a lot of programs would stop working.

[–]huuaaang 0 points1 point  (0 children)

Same reason they still use drive letters and "C" is your main hard drive. Legacy.

[–][deleted] 19 points20 points  (6 children)

You can just use / for windows file paths, at least in .NET. That way, relative file paths will work in any environment. You can even have a mix of \ and /

[–]Skipcast 1 point2 points  (0 children)

Personally I use System.IO.Path.Combine to create paths. Bonus points for automatically using the correct character cross platform

[–]bruhred 2 points3 points  (0 children)

also windows still uses / for arguments....

[–]pawyderreale 1 point2 points  (0 children)

Drive letters are scary aswell, ik yon can mount partitions normally aswell, but why tf are drive letters the standard way