• Greg (unregistered)

    This is going to work fantastically well if someone creates a file on unix that contains a backslash in it's name.

  • A.N.O Nymos (unregistered)

    Just use / for all your path-separators, Windows can handle those just fine.

  • Rainer Deyke (unregistered)

    User code with backslashes as path separators is an abomination. Low level C/C++ file operations support, and have always supported, backslashes.

    Slight exception for the presentation layer, because users expect backslashes. But only the presentation layer. Convert to backslashes on output, convert to forward slashes on input.

  • (nodebb)

    In my decades of software development, different file IO systems were always a pain in the butt. Now these days a lot of people only think there are two but in the past there were many different ones and all of them had a quirk here and there.

    Still, while Windows supports both directory separators, it's very important to note that this support means that all alternative directory separators are actually get converted (normalized) before usage internally and since all functions support const literals that means allocating a buffers. So there is a significant cost involved with using alt directory separators and you still should always use the native versions over the common '/'.

    Now is there a good way to get around this? Nah. There is actually way more to it than just the directory separator since file systems are often completely different in terms of structure and features. Linux is real links and ignoring that could end up in an endless recursion why enumerating directories. Windows had drives, which are not only not bound to letters that can change, they actually often will when you work with multiple removable devices. And finally the whole permission system is completely different, down to what classifies as an executable. And I just mentioned here a few pitfalls on the top of the iceberg. So just using an directory separator macro isn't enough in a well thought out software, you really need to abstract away the OS in a way more involved way to the point that it's really hard to pull this off on a zero cost basis; which means it's often better to do it inline. Sucks for readability, sure, but beats using a bloated, slow, resource hungry IO framework.

    Addendum 2026-06-29 08:01: Linus is real links? Ha, I guess it has them but eh, I blame the heat wave here :-).

  • Frodo Brömmelkamp (unregistered)

    If we're compiling for unix, append a "/" to the filename. Otherwise, append a "". Then we append a path out of an array. Then, if we're on Windows, find all the "/" in our filename and replace them with "". Otherwise, find all the "" in our filename and replace them with "/".

    Ah, the good old XKCD 1638...

  • (nodebb)

    You people had it soft. Welcome to the world of VMS, a.k.a. OpenVMS, in which the directory separator is a period but the entire directory name had to be enclosed in square brackets.

    DISK1:[USERS.JOHNR]README.TXT

    And that's just getting started. There was a limit of subdirectory levels (8) but a "logical name" could be defined to sneak around that --- for example, DISK1 might expand to a physical hard drive like DKA0 but it could easily expand to DKA0:[CLIENTS.BESTBUY.CONTRACTS.MAINTENANCE.2020.] instead. Loads of fun for the entire family!

  • (nodebb)

    And somehow, there are still code paths that output the wrong path separator sometimes, though at least modern Windows is forgiving about that

    Indeed, although it is stretching the definition of "modern" a bit, seeing as how all versions of Windows in the NT line supported it, all the way back to 3.1, and the 9x line also supported it. It probably worked (it has been too long since I've needed to know this) on MS-DOS as early as 2.0. (Before that, directory structures weren't a thing on MS-DOS, nor on PC-DOS.)

  • (author) in reply to dpm

    Don't forget the file versions! README.TXT;3 lets you see what the file looked like three versions ago.

    Back when I worked helldesk in college, our mailserver ran off a VAX running VMS. They added a webmail interface in 1998 or 1999 (before that you were expected to just use IMAP or POP), but it was still the same mailserver. And due to the way it worked, you'd get locked out of your account if you exceeded your quota, which meant you couldn't log into the webmail to delete your emails. One of the main tickets for the helldesk drones was telneting into the mailserver using the user's credentials and using the mail CLI tool to clear out old messages.

  • Officer Johnny Holzkopf (unregistered)

    It's not just about the path separator. Things that also matter are maximum directory depth, maximum file name length, forbidden characters (like "screenshot_2026-06-29_16:28:03.jpg" could be a problem), as well as possible displaying problems with mangled character sets and encodings (UTF-8 vs. ISO-8859-1 vs. CP-1252 vs. maybe even CP-850), as well as entirely "forbidden" filenames (such as "CON:"). Also characters can have special meanings, but still could be allowed in filenames elsewhere ("3*3 matrix.pdf", "What's up?.Doc", "yes|no.txt", "My $5.png", "read THIS »handbook«.xlsx", "sys1.stupid.tasks(gohome).jcl", "LOGIN.COM;1" and so on). Being truly cross-platform with paths and filenames is not easy if you want to leverage the "strange" (but valid) possibilites...

  • MRAB (unregistered) in reply to A.N.O Nymos

    There are a couple of exceptions. (1) Command line options start with "/". (2) Dialog boxes insist on backslashes.

  • Hmmmm (unregistered)

    Seems like a backslash backlash flashback!

  • Randal L. Schwartz (github) in reply to Greg

    I often worked very carefully to make sure my shell scripts worked ok even for names containing spaces, backslashes, shell wildcards, and the dreaded "newline". Perl made it much easier, as you got globbing only in very specific circumstances.

  • Wendy (unregistered) in reply to Remy Porter

    In VMS README.TXT;3 is the third version, not the version 3 back.

  • (author) in reply to Wendy

    Entirely possible. I haven't actually used it since 2002. Which is honestly, kinda shockingly late to be using a VAX.

  • A Human (unregistered) in reply to A.N.O Nymos

    Yep, just use a forward slash.

  • Duke of New York (unregistered) in reply to A.N.O Nymos

    "Windows" might handle it, but you can bet that the non-standard filename will leak into some context that won't. When in Redmond, do as the Redmonders do.

  • (nodebb)

    Actually, README.TXT;-3 would give you "three versions back".

  • Peter of the Norse (unregistered)

    I’m also worried about that ReplaceAll, which is a normal CS 102 assignment, but I’ve seen poorly implemented versions that somehow break on simple things

  • Your Name (unregistered)

    In my file abstraction on Windows I'm converting everything to UNC format at the file API layer. Internally paths and files are always regular slashes as they work mostly. Some APIs unfortunately won't like them, so it's a bit hit and miss.

    Also, for funny file systems, there's Guardian on the HPE Nonstop (formerly known as Tandem): $<drive name>.<volume>.<filename>

    I don't know about drive names, but both volume (a single sub folder) and filename are 8 characters max. No Z or digit as first file name letter (Z is reserved)

  • (nodebb) in reply to Remy Porter

    Not at all. I worked at a company in late 1999 which had their whole production like controlled by a VAX. In fact, for strategic reasons they used Windows, Linux & VMS for different parts of their business to not rely on a single vendor. After that job I was always baffled how risky other IT infrastructures were in comparison. But to be fair, most of them weren't businesses that lost millions if the production was standing still for a minute.

  • Greg (unregistered) in reply to MaxiTB

    Does that many that any of those 3 vendors could cause a disruption of their production?

  • (nodebb) in reply to Officer Johnny Holzkopf

    as well as entirely "forbidden" filenames (such as "CON:")

    It's quite possible to create a file called "CON" on Windows. The mapping from names like CON to actual device drivers is done by the top-level file system parser, and you can, using documented methods (the infamous backslash-backslash-dot-backslash thing), bypass the top-level parser, and if you do that, two big things happen:

    First, the limit of 260 characters for the whole pathname goes "poof", replaced by a limit of 32767 (wide) characters.

    Second, those "special" names are no longer special.

    The price is that you have to do a bunch of the other work the top-level parser does, such that you present the APIs with a full absolute path name, with no elements called "." or "..", and backslashes everywhere - no forward slashes allowed, etc.

  • Kotarak (unregistered)

    TRWTF happens when people pass a path with backslashes as a regex pattern without properly quoting it. They even tried to be clean and used os.path.sep to append the proper separator to the "pattern". Of course <eof> is not a proper escape sequence for a regex pattern....

  • (nodebb) in reply to Greg

    Ah no. As I said, different parts of the business used different OS. They used VMS for the production line, Linux for R&D and Windows for the less important people like administration, office and management. They did that also with other software, they used MS Office but used a Lotus Notes mail cluster f.e.

    They only downside you have is that you need a bigger pool of experts maintaining the infrastructure, but you are not vendor locked because the biggest hurdle of migrations is lack of expert know-how. And people like 20yr old me with experience in all three OS were useful as well, that's how I got the job back then. So you end up with a healthy mix of experts and generalists.

    But yeah, it's not the cheapest solution. However that has been a world-wide operating company which a brand portfolio everyone has already heard of, so for them a few thousand bucks is just a rounding error.

  • (nodebb) in reply to dpm

    Fun thing about the VMS paths: you could access a disk on a different machine

    DIR MAVEN::Disk1:[dir.subdir]file.ext;-2

    and the ;-2 means "get the version that two versions out of date", which was a hoot and a half. You can also put in a user name and password

    DIR MAVEN"myname password::Disk$1:[dir.subdir]file.ext

  • (nodebb)

    Last time I used a VAX was 1989 at Kodak Japan. The versioned files were both a blessing and a curse. It was nice being able to revert, but with a minuscule disk quota we'd have to carefully choose which versions to keep around.

  • (nodebb)

    Windows may be forgiving about this, but Linux absolutely is not, and it doesn't even have the courtesy to punish you right. It will accept your UNC path and blindly try to access the file in some subdirectory of your current directory (heaven help you if you were calling mkdir()) rather than tell you UNC paths are not supported.

  • Duke of New York (unregistered) in reply to Medinoc

    Oh sure, let's turn every filesystem call into Clippy.

  • (nodebb)

    macOS is even more fun, since for a lot of its history, the path separator was the colon ("Macintosh HD:Folder1:Folder 2:...". I remember getting bugs on why they were seeing paths with colons in them, but I couldn't do anything about it because that's what the macOS APIs used. And yes, this was OS X - you could use /, but many APIs internally convert it to a colon when dealing with HFS+.

  • Tim (unregistered) in reply to Duke of New York

    since / is not valid in a windows filename, if you do come across something that doesn't accept / as a separator, you can safely replace / with \

  • Duke of New York (unregistered) in reply to Tim

    POSIX does not restrict Unix system from having backslashes in filenames, and block devices are migratable. Second-guessing backslashes at the OS level or above would be perverse and harmful.

  • (nodebb) in reply to dpm

    Archimedes and family (RISC OS) also used dots as file separators. Also, each file had a hidden file type (similar to a file extension). These were not part of the file name per se, so you had to add this in the conversion if you copied them to other systems.

  • MRAB (unregistered) in reply to ochrist

    If a filename needed an extension (because the file had come from a MS-DOS), a slash was used, so MS-DOS "ReadMe.txt" became "ReadMe/txt".

  • (nodebb) in reply to Duke of New York

    POSIX does not restrict Unix system from having backslashes in filenames

    That's precisely the reproach. IIRC it also allows control codes, for extra insanity.

    Addendum 2026-07-02 12:12: I'd add that anyone who willing puts a backslash or a control code in a UNIX filename is looking for trouble.

  • Duke of New York (unregistered) in reply to Medinoc

    It's a foolish reproach. Backslashes are part of ASCII, and the user is entitled to use them if the file system doesn't.

  • Duke of New York (unregistered)

    PS: yes, there are ASCII characters that "may be asking for trouble" in a filename, which is why POSIX defines a safe character set, but such "trouble" in userland programs is the burden of those programs, not of the OS.

  • (nodebb) in reply to Medinoc

    Windows may be forgiving about this, but Linux absolutely is not, and it doesn't even have the courtesy to punish you right. It will accept your UNC path and blindly try to access the file in some subdirectory of your current directory (heaven help you if you were calling mkdir()) rather than tell you UNC paths are not supported.

    Using foreign path formats, like Windows-specific UNC paths, as-is and expecting them to just work like in their native environments is misguided at best. It's like entering cmd.exe/batch-file commands in bash and wondering why you're getting a ton of errors.

    The correct way is to mount the remote share, by way of samba (where the UNC path is used, though with forward slashes), and then the mount point is simply used.

    However, In most modern file managers on Linux, like Dolphin, you can enter UNC paths as smb://host/share/path, optionally with user@ before the host part. Note that backslashes need to changed to the forward variety, just like when mounting.

Leave a comment on “Off the Path”

Log In or post as a guest

Replying to comment #701288:

Log Out

« Return to Article