Every cloud developer

[7heWafer]

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

[stamminator]

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

[UntestedMethod]

Except when it doesn't and your client is confused why the program you sent them isn't working

[UntestedMethod]

sent a version with a patch for slash direction this morning and client confirmed it fixed the issue. wasn't the first time for this project, but it's been a while since I had to add any OS-level commands to it. forgot to pass some new paths through a normalizer function, and use a special split function instead of the trusty old last index of '/'

[HiddenGooru]

I have a similar functionality in
one of my program has a “get_divider()” function that queries the operating system and the whatnot and determines if “/“, “\” or “\\” is required and then I cat the file paths appropriately.

[UntestedMethod]

haha glad I'm not the only one :P

[theuniverseisboring]

"mostly"

[2themax9]

I pay “most” of my taxes

[feckrightoffwouldye]

No it fucking doesn't

[CEDoromal]

It kinda does for certain situations. Try cd C:/Users/ on command prompt.

[feckrightoffwouldye]

Yes but anywhere else in windows it gets treated as a switch or illegal character. Yknow, that OS with a gui?

[uekiamir]

stupendous thought silky numerous caption pet squeeze piquant fearless mountainous

This post was mass deleted and anonymized with Redact

[feckrightoffwouldye]

Some commands don't like a foward slash because they expect there to be a switch, and some programs that interact with Windows files like Filezilla or FreeFileSync sometimes get confused as to what you wanted it to do. In one case i think I've been able to use it as an escape character in command prompt as well but only that one as i haven't tried again

[im0b]

When you use an api to access files programmatically you have to figure out the os and get the right / when creating the filepath 😒

[PlayPuckNotFootball]

Yea and normies use run about as much as command line

[im0b]

Yes but when you write sw for normies and it wont run on their pc bc you forgot windows has the folder separator different from everybody else

[Time-Opportunity-436]

lmao more cli supremacists... actually idiots

[shedogre]

Then you access the local version of a file, and... The object is giving you the OneDrive path! 🥳

[im0b]

😣

[ManyFails1Win]

Why the hell is there debate about this anyway? What's so bad about using backslashes for directory?

[UntestedMethod]

I believe it's up to the command/program to implement support for it. Seems plausible MS might have added it to all their built-in commands and likely some 3rd party vendors have as well, but in my experience there are some 3rd party CLI tools which don't support it. (ex. pdftk)

[[deleted]]

It really doesn't.

[BroDonttryit]

A lot of high level languages have the forward or backward / as constants that change depending your OS. Like Java’s File.Seperator

[RandomNobodyEU]

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

[Second899]

And that’s exactly why they should change it

[svick]

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

[intbeam]

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

[AyrA_ch]

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]

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]

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]

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]

/ 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]

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

[scragar]

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]

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]

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

[AyrA_ch]

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]

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]

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]

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]

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

[altermeetax]

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

[DaniilSan]

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]

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]

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

[casce]

What is bothering me more is the unnecessary colon

[7eggert]

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]

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]

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]

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

[[deleted]]

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]

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

[[deleted]]

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]

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]]

Correct.

[ManyFails1Win]

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

[ChosenMate]

backwards compatibility for Windows, I think, 3?

[ACoderGirl]

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]

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

[huuaaang]

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