I'm “still afraid to use spaces in file names” years old | Hacker News Reader

I'm “still afraid to use spaces in file names” years old

twitter.com

1,356 pointsdario_satu804 comments

I work on a complex desktop application, and it's been astounding the number of bugs that have appeared over the years triggered by spaces and other unusual characters in file names. If you do anything with subprocesses or path processing, it's absurdly easy to hit in a thousand different ways, over and over again.

Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space and/or special characters in it.

Forces you to deal with this properly, and immediately ensures that every automated test checks this case without you having to remember every time. Hasn't been particularly inconvenient, since I'm autocompleting it 99% of the time anyway, and I haven't shipped a single path parsing bug since.

Seems like MS had the same idea according to an answer in the link:

> Microsoft intentionally made programs install to C:\Program Files on Windows 95+ to force programmers to deal with spaces in filenames.

> Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space and/or special characters in it.

A former co-worker changed his name in our auth system to include an apostrophe, so that whenever we handled names wrong he'd find it.

> it's been astounding the number of bugs that have appeared over the years triggered by spaces and other unusual characters in file names

If you consider spaces “unusual” I would say you haven’t encountered a single average user in your lifetime. Spaces in file-names is the single most common thing people have, outside programming environments.

As a x-plat developer, the only platform where I (still) regularly encounter these kind of bugs are platforms where solving problems through scripting is common, like Linux, where the primary means of operation is through stringly-typed statements getting parsed and processed in a untyped-fashion. It's not very reliable.

On Windows people more often use “real APIs” (because scripting doesn't really work as well), but then these problems just goes away.

Pros and cons, I guess.

It doesn't even have to be complex, often basic automation tasks fail with spaces and special characters. Honestly, treating a file system like a natural language processor is a bad idea. Besides at this point with how digital we have all become who can't understand...

thisismyconfig.txt vs this is my config.txt or this_is_my_config.txt

...i've forced myself to stop using spaces, character, and even cap. They are all constructs that provide minimal value for the extra complexity.

My favorite filename special character bug was when I implemented CD ripping in 2005, and one of our beta testers ripped a CD with a song called "Have You Ever?". My code wasn't prepared to filter out the question mark on Windows.

> Pro tip: rename your development directory

I changed my username to not contain a space because it was too annoying to deal with all the random dev tools breaking. The worst offender was probably npx on Windows [1] (resolved after four years by deprecating npx), but it was far from the only one (though the JS ecosystem was somehow the worst in this regard of all languages I worked with).

1: https://github.com/zkat/npx/issues/100

> other unusual characters in file names

Saw a few hacks where malware authors used the RTL feature (which is baked into Windows) to obfuscate file extensions. It looked like .exe.innocuous-document.docx, but was actually .docx.innocuous-document.exe

My Mac is formatted case sensitive when the default is case insensitive. This will also catch a ton of import related bugs.

League of legends doesn’t run until I sed files for instance.

I maintain a similar system, where a variety of companies submit files that get processed through multiple services - it is astounding how ridiculous people’s naming of files can be; spaces are the least concerning!

> anything with subprocesses

I'm begging software developers to stop using subprocess APIs that take a string argument (system(), child_process.exec(), Process.Start(string)) and start using subprocess APIs that take an array of arguments (execvp(), child_process.execFile(), Process.Start(string, IEnumerable<string>).)

While I agree that we should do this in the ideal world, doing so will inevitably break other necessary tools so it is unworkable for me :(

And add a emoji, a character in a right to left language ( א) and perhaps 太. Maybe italicize one of those too...

Spaces are a pain in the ass when you're using CLI so I'd rather enforce a no space policy

I don't know if it's still a problem, but it used to break Python virtualenv badly. If your working directory had a space anywhere in the path, it would throw a huge fit and not work. Which is problematic when the expected name for a Mac's boot drive is "Macintosh HD" (if you ever had a reason to run a virtualenv outside of your home directory).

Pro tip2: Use std lib path processing utilities

Sometimes / works as a path separator in Windows, sometimes it doesn't. It's not predictable.

I never use / on Windows as a result.

It's easy to tell users to make a folder with no spaces if you're setting up a global path, however if you have an application that runs in user directories things can become painful fast. Changing your user name is a pain and can leave things inconsistent, but having to handle all the variations in people's names with spaces, punctuation, international characters, can just be mind boggling.

I did something similar on accident. I used to keep all my development work synced with Dropbox and I had a work and a personal account. So any of my own projects would have /Dropbox (Personal)/ in the path which did catch some bugs. Dropbox renamed my folder to "Dropbox (Personal)" automatically when connecting a work account.

More importantly than your source files, put your testing data on such a path as well. Nobody uses absolute paths in testing so it doesn't matter how many spaces your absolute path has if your input is "./tests/file1". Put those files in a folder with spaces too and throw in a unicode character for good measure.

> Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space and/or special characters in it.

The problem with that is that YOUR code may handle it, but your tooling may not. If my code formatter break on spaces, I'm not going to change the formatter.

Somewhat related to injecting unusual characters, in my experience in localization efforts:

Inject a Turkish 'I'. I don't know how to type or paste it here, but picture an English lower case 'i' that is upper case. It is a splendid way among many to shake out some loc bugs.

Late '90s I worked on Java software that got installed on several Unix platforms, including Linux for IBM mainframes. When you deal with the default en/de-coding of Unicode to EBCDIC you never have trouble with Java byte encodings ever again.

Someone should provide the OneDrive/SharePoint people some of this religion.

Mysterious character requirements that do not conform with Microsoft’s OS limits, limits on tbe fully qualified pathname length, etc.

Let's not forget return carriages in filenames within apps...

Even capitalization is a pain in the ass thanks to how OSes treat file names. I pretty much stick with either `file-name.ext` or `file_name.ext` exclusively now.

Today I learned that You cannot install Tailscale on windows if installer is inside path with non-latin chars.

In that case, be thorough and insert a Chinese and an Arabic character to enforce a Unicode check.

See the recent article about unicode invisible glyphs in JavaScript or bash.

Naming freedom needs a stdlib module

For those purposes I've found hyphen to be a nice substitute.

Better solution: only allow ASCII, maybe dashes, and up to twelve characters. Problem solved.

Enforce this in LDAP.

Strict convention is better than flexibility and predicting obscure edge cases that can fail.

And yet OneDrive WP t allow fir spaces before or after a file name.

Or not, which when bugs crop up will teach the businessy types to stop putting spaces in their filenames.

> Pro tip: rename your development directory (or even better: the workspace path in CI) to put a space and/or special characters in it.

This will also break any code in external tools that are called during the builds of your application and do not handle spaces correctly for whatever reason, thus making it so that you won't be able to successfully finish the build.

Then again, you probably shouldn't be relying on technologies like that, but when you're struggling to keep an old enterprise system alive, causing yourself more problems is not necessarily what you should do.

Still a good idea in most cases, though.

I have an overly-aggressive function in my .bashrc to rename all files in the current directory:

  # Rename all files in a directory
  rn() {
    rename "s/ /-/g" *
    rename "s/_/-/g" *
    rename "s/–/-/g" *
    rename "s/://g" *
    rename "s/\(//g" *
    rename "s/\)//g" *
    rename "s/\[//g" *
    rename "s/\]//g" *
    rename 's/"//g' *
    rename "s/'//g" *
    rename "s/,//g" *
    rename "y/A-Z/a-z/" *
    rename "s/---/--/g" *
    rename "s/-‎--/--/g" *
  }

I use this all the time, especially when I download files.

Word of warning from hard experience: rn is a really dangerous thing to name a function because it is one char away from rm.

https://github.com/dharple/detox is a nice tool for this. Sane defaults but configurable.

In addition to CLI I use it from emacs dired-mode too:

    (defun my-dired-detox ()
      (interactive)
      (dired-do-shell-command "detox" nil (dired-get-marked-files))
      (revert-buffer))

I bind it to "_" in dired-mode.

Overly aggresive is right! I don't know if this is genius or deranged! I'm leaning towards genius and stealing the idea.

By the way: what's your beef with en dashes? I mean, if it was "everything should be 'HYPHEN-MINUS' (U+002D)", then fine, but why specifically en dashes and not em dashes?

I use this snippet, to change spaces to underscore for directories and files in the current directory and below. Haven't made it a function yet, but should. I got it from stack overflow or somewhere, but no attribution. Thanks to whoever did it first:

   find . -depth -name '* *' | while IFS= read -r f ; do mv -i "$f" "$(dirname "$f")/$(basename "$f"|tr ' ' _)" ; done

Thanks to all the comments in this threads, I now have "sudo apt install rename detox" in my install script, and:

    normalize_names() {
        rename "s/-/_/g" *
        detox -s lower *
    }

in my .bashrc.

I've thrown some edge cases at it, and it handles it super well. It deals with consecutive "_", remove leading garbage, normalize unicode, and even prevents naming conflicts by opting out early.

Thanks you.

If you're a developer you're doing yourself a big disservice by not learning how to deal with special characters.

You might be interested in detox:

https://github.com/dharple/detox

Nice but how do you prevent overwrites? What about directories/folders and the files in that directory/folder?

I have:

  Movie Bla (2020)
    Movie Bla (2020).mp4

But also:

  Movie_Bla_(2020)
    Movie_Bla_(2020).mp4
    Movie_Bla_(2020).srt

Would not like to lose files like the the srt.

Surely you must run into conflicts now and then?

I wonder if rename has an -e flag like sed. It might be worth baking this into one monolithic regex if you call this often

You missed ~ You really don't want to create a directory named "~".....

Define "space". Is the Hangul filler we talked about yesterday a spacing character? Is the zero-width non-breaking space a spacing character? What about the typographic spacing characters?

You should better be very afraid of using spaces in filenames.

You should do everything you can to support them but you have to know you'll invariably encounter countless cases where you'll have this or that tool that won't work properly with them.

I still live in a world where I cannot name a song from the french group L'impératrice with an eacute in the filename or my car's media system will display garbage (it's running QNX and I don't know which filesystem).

FWIW, and it should be food for thought, every single Git repository in the world contains a pre-commit hook sample (disabled by default but it's there) that enforces that every committed file in the repo is named using a subset of ASCII characters.

Every Git repository in the world has that example: let that sink in.

> FWIW, and it should be food for thought, every single Git repository in the world contains a pre-commit hook sample (disabled by default but it's there) that enforces that every committed file in the repo is named using a subset of ASCII characters.

I use Git for documents too, not only code. Why shouldn't I use my native language?

> I still live in a world where I cannot name a song from the french group L'impératrice with an eacute in the filename or my car's media system will display garbage (it's running QNX and I don't know which filesystem).

I have an Android phone and I tell MusicBrainz Picard to save all files with ASCII-only names and Windows-compatible names for the ones that get sent over to the phone. Basically for this reason. Sometimes it's players on Android itself, but even more frequently, whatever bluetooth radio I'm connected to freaking out with non-ASCII characters.

You get all those space characters working and then some jerk comes along and uploads a file like this: ŗ̶̧̢͓̳͍͙͔̳̻̥͉̭͓̫̟͍̞̭͉͓͉̮̹͍͚̳̹̬͉͚̰͈̘̐̊̾̈̀̒͒̀͛̓̋̔͊̏͘̚ę̴̨̛̣͙̤̟̬̩̟͙͖̥̹̱̱̊͑͗̇̇͛̆̈́̃͋̓̀̔̍̍̌̐͊̎̓̅̀̕ͅģ̴̹̜̘͍̱̑͐̉̌̐̄̊͛̎́̐̌̅̈́͂͑̈́̋̔͂̊̊̒̒̔͛͆̚͘̕͠e̶̙͕̫̳̘͐̾́̑͆̓͂̿͊̊̍͛͐̌̆͗̌̅̅̔͊̂͛͗̅̕͝͝͝͝x̵̢̧̦̫͖̝̥̹͓̬͖̤̩͚̝̫̋̃̅̈́̆͋̌͑́̎̈́̊̾͒̀̒̎̓͛͊̿̓͊̀̍͐̆̚͝͝-̴̨̮̯͖͖̠̜̲̪͕̘͈͖̮̈́̓̐̃́̅̄̏́̍̉̐͌́̔̓̄͋͗̐̕͜͝ţ̴̢̧̖̗͖̞̮̫̦̼̝̺̼̱̳͓͉̜̟̤̲͖̻͙́̌̈̌̈͆̾̄͊̿̏̓͗̈́̕͜ͅh̶̢̧̨̥̭̼̟̣͖̯̗̤̖̙͉͕̙͎̰̠̝̖͈̻͙̪̮̘̯̻̼͕͓̖̣͈̽́͊̎͐͌̆̍̎̏̿͐̒́͋͑̍̿̎͆̑͆̄͂̀͐̄͑̀͗̿̽̎̾̊̕͝͝͝͝͝ͅi̴͚͈͍̫̮̝̣͖͉͓̯̠̙̭̟̖̘̾̓̄̈́̒̏̽̆̉̿͛̀́̃̋̒̈́͋̂̇̈́͛̕͜͠͠͝ͅs̶͇̖̳̞͉̱̞͓̖͔͔͍̗͇̖̮̹̅͊̔͋͊̈́̎̐̆̋̒̀̍̕͜ͅ.̴̧͎͇̰͉̼̱̰̦̟̑̋̏͌̍͊͑̄̀͌́̆̓͛̒̆̾̉͐̄̂̈́͆̒̃͗̐̂̎̈́̈͛̿́͛̾̚͘͜͝͝ͅȩ̷̡̲̪̱̪̥̳͍̼̰̘̗̹͙͙͓̣̟̩̥̥̖̠̪̮̹̞̥̻͎͖͍̯̂͑̏̑̆̍͋̎͛̅̑̑̏̎̓̀̓̒̈́͊͌̀̈́̒̌͐͂͛̊̍̐͂́̔̌̾͐̈́̋̇̏̚͜͝͝͝͠ͅx̶̧̛͚̗̜̪͍͖̘̙͎͚͇͙̬̱̟̭͓̺̙͍̖̱͚̣̘̪̭͔͔̮͎̬̪̤̹̟͔̩͍̬͕͔̩͐̈́̒̂͛̂̈̀̿̍̔̓̓̀̃̍͆̈́̍̓̌͐̈́̾̇̎̑͌͒̄̆̿̍͆̅͗͆͘͠͝͝ͅͅͅe̷̢̡̡̨̧̛͕͚̬̮̞̥̼͍͔̝̟̝̯͈̟̥͖̱̹̣̩̼̩̅̌͌̑̎̐̀̽̏́͐̋̏̎̎͛͌̀̊͊͒̑͌̎̎̑͊̌̉͆̾̚͘̚͜͠͠͠͝͝ͅͅͅ

I have an uneasy feeling whenever I see a path parameter declared as string. Path is not a string - it's a sequence of path components and should be treated as such by our APIs. A path should be parsed once - on user input - and then used in its "sequence form" throughout the software stack.

And "path component" is not an arbitrary string either - e.g. appending a path component to the path should first require converting/parsing the string into the path component, and only if that's successful appending it to the path.

"Path is not a string - it's a sequence of path components and should be treated as such by our APIs."

For maximum correctness, you want to turn it into a file handle as soon as possible, and do all operations through the variations of the file functions that end in "at", like: https://linux.die.net/man/2/openat

The downside of this approach is that you still technically have to carry the path around with you if you ever want to present it back to the user, because once you have a directory handle, you can get back to the root directory easily enough by following parent links and seeing what directories you end up in, but that may not be what the user "thinks" the path is, and they want to see their path, not a canonicalized one. And they're mostly right. And it's not easy to correctly track changes to their intended path from this basis either.

Basically, I don't know of a really solid, 100% correct way to handle this with any reasonable degree of effort.

> I have an uneasy feeling whenever I see a path parameter declared as string. Path is not a string

I guess that depends on what you mean by "string". `open` and `fopen` need a char* path to open a file. Whatever fancy Path abstraction you use eventually becomes a char* string, because that's what the kernel needs.

Strings following certain rules are entirely valid representations of paths, just like sequences of path components in the chosen language/framework are. Similarly, the sequences of bits that make up the sequences of your language/framework in memory are an entirely valid representation of said sequences of components.

Yes, paths have structure, but saying "a path is not a string" is equivalent of saying "C source code is not a string". Both are strings, and both are something else, represented by strings according to rules. Different internal representations have different advantages and disadvantages. I fully agree that for things such as "adding components" an internal sequence/list representation is better, but strings can pass arbitrary IPC or even ABI boundaries much easier for example. (And you wouldn't bat an eye for example when you see FQDNs like "www.google.com" passed as a string instead of as ["www","google","com"] because the string representation works pretty well.)

POSIX "Fully portable filenames" allow all characters except 0x2F (/) and 0x00 (NULL). That means file names can include line feeds, backspaces, EOF, etc.

"This is `a

perfectly vali'd.\010! file name\377, despite the weirdness"

things like this are why the Unix philosophy is so bad.

text processing is hard if you must support Unicode, and that means every Unix command line tool must implement or employ a text processor to handle input. it would be much easier if objects were passed back and forth. PowerShell got this right.

I'm hardly afraid but I just think it's poor ergonomics. Same as the move from

   xset m 0 0

    xinput --set-prop 'pointer:Logitech USB Receiver' 'libinput Accel Profile Enabled' 0, 1

Everything seems to be going this way in Linux land. Longer names, harder to type names, camelcase names, spaces... I'm looking forward to an OS that treats command line ergonomics as a first class feature and where camelcase & spaces are verboten.

Well, if you think that's bad, behold the recent trend in network interface names on Linux.

We started out with 'eth0', 'eth1', etc. Which adapter was which could change when adding and removing a network card. That was bad, so that prompted the evolution.

Now we have 'enp1s0', 'enp0s31f6', 'enp13s0' and many similar variations. These are supposedly more stable across device changes. As it turns out, it wasn't.

But wait, there is more! Now we have the "predictable names" scheme that produces interface names that are even longer, and not even slightly easier to remember.

Read about the whole sorry saga here:

https://wiki.debian.org/NetworkInterfaceName

I do get that it is not an easy problem to solve, especially in the face of removable network interfaces (like USB Ethernet / WLAN). But surely this is not the best we can do.

I find this attitude misguided. More descriptive names are more ergonomic for things you only use rarely but they need to be combined with much better autocompletion than most shells provide by default.

Cue nmcli (CLI for Gnome's NetworkManager) which uses UUIDs for everything and (at least a while ago) did not accept partial-but-unique UUIDs. Basically goes "nmcli connection up 5095665a-d82c-4ae6-8964-283623387941".

I could infer a lot about the second and what those params mean and what they do.

The first one is some magical incantation.

The problem is we're optimizing for "easy to learn" rather than "easy to use".

Long option names are more descriptive, more easily distinguished, and easier to remember. Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.

These changes are meant to make it easier to read and understand command-line incantations (and to make them more explicit, which is always good), because the command-line paradigm, being text-based, imposes an unavoidable trade-off between ergonomics and understandability/ease-of-use. It sounds like you prefer ergonomics - although I wouldn't be surprised if most users would prefer ease-of-use.

Of course, if one doesn't write a CLI to begin with, this trade-off doesn't exist - you can have your cake and eat it too.

What's wrong with camelCase? It's easier to type than snake

imho, the fundamental problem is using space as a delimiter. Also, case-sensitivity is a disaster for ergonomics.

If you had comma-delimiting like in an algol-derived language, you wouldn't need to quote things with spaces.

edit: also, code is read more times than it is written, so optimizing for readability over brevity is generally a good move.

I've a feeling you will hate powershell

A lot of my stuff is cross platform so making filenames portable means avoiding spaces.

Ironically, even NASA doesn't like space.

https://www.nas.nasa.gov/hecc/support/kb/portable-file-names...

Touché my friend, had a good laugh

I am also that age, and kebab-case is the best case for filenames.

2021-01-01-some-important-document.pdf gives me the warm fuzzies. On the off chance that some more differentiation is needed, throw in an underscore and a whole new world opens up

I go one step further: 2021-11-11_client_project-name.ext

2021-11-11_client_projectName.ext is also OK. But underscore separates fields, hyphens for space replacement.

I've recently shifted sharply toward the dash from the underscore. I find it more readable, and it doesn't require the shift key. However, I do find it useful to use underscores to create groups, e.g. test-001_2021-10-11.log. Including hours, minutes, seconds is still awkward.

> kebab-case

I hadn't heard that before and I love it.

I'm of the opinion that kebab-case is the best case for all identifiers, because it's easy to read and to type. As always, Lispers were right all along.

Kebab case is the often overlooked benefit of prefix notation and semantic white space in programming languages. Honestly the best case of all cases imo.

I found that some_document_2021-01-01_v03.pdf works best because it keeps the same document next to its other versions alphabetically, keeps them in date order, and keeps them in a sub-day version order.

In my work, today's date would be 21K11, to save space over the longer date.

As a side note, in the good ol' times of ISO9660 level 1-4 and the various mkisofs parameters, an underscore _ which is a CAPITAL -, may have given issues, only for the record/as a curiosity:

https://web.archive.org/web/20151007005513/http://www.911cd....

P.S. should anyone want to see/run the actual batch, a copy has been uploaded here:

http://reboot.pro/index.php?showtopic=18962&page=29#entry204...

> 2021-01-01

Yes on the date format.

Saves you so much time.

This used to be my default, and then I used Matlab, and "-" was interpreted as subtraction.

I use this style:

2021-01-01_what-happened_who-did-it_possible-reason

One of the main reasons why Windows used "Program Files" and "Documents and Settings" was to force the programs (and programmers) to deal with paths with spaces. And you know, for the most part it kinda, more or less worked out although of course even today you will find programs that ask you to install them in a folder without spaces in the path.

And that was a good idea, if only Microsoft also fixed the CreateProcess function, Windows would be somewhat sane in this regard. But somehow nobody seemed to think of it. Seriously, look at it:

https://docs.microsoft.com/en-us/windows/win32/api/processth...

The arguments are a single string. So you want to pass parameters with spaces in them? You've got to add quotes and stuff all of that into a single string. Instead of doing it in a more sane manner, like oh, the arguments to main().

The main culprit for space issues is stuff relying on BAT or CMD files, where escaping variables seems to be a black art.

Sadly such set includes loads of Java programs. If only SUN had shipped a standard way to generate isolated exe files in 1998... but they worked under the presumption that you'd have a JVM already there, because distributing that monster was difficult in dialup times, so you could just hand people a jar; and the enterprise market did not care, since they had webapp servers. Sadly it's an "optimization" that became obsolete very quickly but wasn't rectified until it was too late (java 9+).

That annoys me every time I use a Windows system. It was a terrible decision, especially since both the command prompt and the new powershell doesn't accept like bash a backspace before a space, you have to quote the whole path! I get that most users on Windows don't use the shell, but as a developer I do a lot, and every time it's a pain (no wonder they added the WSL in Windows after the failure of Powershell...)

VFAT and stuff like that actually provided alternate names like PROGRA~1

They may have thought that would happen but I saw just as much stuff end up in C:\Windows or \Users or (always my favorite) those “Documents” that are really just “whatever random crap every app wants to put there”.

Yet in Microsofts own cmd tool I need to put quotes around my path if I want to refer to any files/folders below those folders.

Still way too many libraries and programs can't handle spaces in filenames.

And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'.

Was recently encoding my Stargate: SG-1 DVDs to move them to plex. I was encoding it on a system other than what was serving it, so I had to copy it. It's surprisingly difficult to "scp" a file with a colon in it directly.

I also love when you're using bash and you have a file with ! in the name, and you accidentally fail to correctly backslash it, you not only get "bash: !rest_of_filename: event not found", but it also fails to add that command line to the history, so you can't just hit up and fix it. You have to actually go to the mouse and copy and paste.

If you suspect that the file might be handed to a bash script at any point, being afraid of spaces is very healthy for sure.

yep, I still don't use spaces. I also don't use uppercase characters. Just underscores or hyphens.

> And shells and other programs still have problems with perfectly legal characters in filenames too, like '!' or ':'.

Without asking you to always quote and escape every file name - what alternative is there? If they tried this you'd probably find you didn't like it.

Is "!" legal in Windows? I'm pretty sure it is not, but I'm not on a Windows machine to test.

Colons are a problem on Windows, so it's reasonable to discourage creating files with colons in the name.

> Still way too many libraries and programs can't handle spaces in filenames.

"It's nothing."

"What do you mean?"

"It's nothing... It's empty space. I never taught the computer how to read empty space!"

"I never taught Virgil how to fly."

I'm not young, but I've been using Macintosh computers regularly since 1990, and even back then file names could be up to 31 characters long, and could include any character except colon.¹ So I'm pretty comfortable using spaces, and sometimes even non-ASCII characters, in file names.

Also back then Mac file names typically did not include an extension, because the file's type was stored as part of the metadata in its resource fork. I remember one time a friend of mine was visiting and was playing around with a paint program on my Mac. Being used to DOS, when she went to save her file, she typed a very short name, and then asked me what the proper file extension should be. I smirked and said, "That's not how you name files on a Mac. THIS is how you name files on a Mac." And then I named her file "Ailsa's Cool Picture". Her mind was blown. :-)

¹This is because the colon was the path separator. But since the classic Mac OS had no command line interface, the typical user would never type or even see a file path written out.

All of that was very cool and impressive and extremely user-friendly.

However, I found the lack of a command-line to be restricting.

Well, you should still be afraid! Be very afraid! Seriously: only a few months ago I was confronted with a video encoding tool that didn't work properly when the file names contained spaces - so yes, even in 2021 it's still safer not to use spaces in file names...

Not to mention most naively written bash scripts!

Looks like I'm in the minority. I always use spaces and non-ASCII characters in filenames.

In many languages it's a requirement. For example, in Romanian, there are 8 words that collide with „fata“ if you remove the diacritics (fata, fată, fața, față, făta, făță, fâța, fâță).

Given that we have to use diacritics, spaces don't seem like a big deal.

> Given that we have to use diacritics, spaces don't seem like a big deal.

There is one big difference: CLI utilities don't usually care about diacritics (though encoding issues can throw a wrench in that), but they care a lot about spaces. So putting spaces in filenames requires properly quoting or escaping parameters, whereas diacritics does not. That makes one-off shell snippets and scripts a lot more annoying (though TBH I tend to shy away from those anyway, these days).

So do I. I have a language, and I'm not afraid to use it. My computer should speak it just as well as I do.

We have a few words that depend on diacritics to be unique in Czech as well - though not as bad as this example - but people just manage without. Hell, I don't even bother installing the Czech keyboard, if I REALLY need it (like in names), I just google for words that have the character and copy it

So how did you deal with it in the 80s/90s?

Hmmm, I thought I was fluent in Romanian (born there and lived there for 26 years), but I only know 5 of those 8 words...

>In many languages it's a requirement. For example, in Romanian, there are 8 words that collide with „fata“ if you remove the diacritics

That is what context is for.

I never put spaces, and won't go over 32 characters, preferably less than than 16. even when sending a file to my grand mom. that's how deep rooted the trauma is. and yes, it remains an issue with some parsers and what not.

I still find files on the internet that my browser can't download because too many characters :(.

Edit: can't save, downloading works.

If I'm going to use the file in the command line, I won't use spaces, since I don't know what sick bug I might encounter.

I avoid spaces because they make tab completion more cumbersome in bash.

Same. For documents and stuff that I use in normiespace I give them friendly names with capitalization and spaces and such, but for anything I'm going to be working on via CLI I try to use filenames that will be easily chunked as "words" when doing things like double clicking it in terminal to select, ^w to erase it, tab completion etc.

Somehow the OneDrive clients still refuse to allow leading or trailing spaces in the filenames, along with a few other characters that are not allowed - seems to cause quite a bit of user friction at least with the non-tech guys that I work with who are confused about why OneDrive is one of the few file syncing clients that has these requirements....

Gdrive the same "issue". I think it's on purpose to avoid files that seems to have exactly the same name.

This can cause user confusion

I have had to deal with that nightmare multiple times this year! It was a real head scratcher at first.

This is a UI/UX problem that I only face when dealing with shells and shell scripts. Never had any issues when spawning processes from within languages/runtimes that support sane argument arrays.

sh, bash and cmd.exe are shit. The shell needs serious rethinking.

This is a difference between $@ and "$@" (note the quotes):

  $ cat proba.sh 
  #!/bin/sh
  echo "Using quotes:"
  for i in "$@"; do echo "$i"; done
  echo "No quotes:"
  for i in $@; do echo "$i"; done
  $ ./proba.sh "ho ho ho"
  Using quotes:
  ho ho ho
  No quotes:
  ho
  ho
  ho

I see that there are lots of comments about problems of TAB-completions with filenames with spaces in this comment section and I am frankly puzzled: both Bash and cmd.exe actually TAB-complete those perfectly fine, inserting quoting where it's needed.

Posix makefiles don't support spaces in dependency names. Not sure about gmake.

Cmake doesn't support semicolons, because everything in cmake is a string, and ; is the list item separator.

PATH is separated by colons, so you can't add directories containing : to it.

Every week, I encounter a user - just like I did in the 80's - who cannot explain the difference between a file and a folder.

"What do I use a folder for?", they ask, in the same breath that they request "some way to organize things logically".

The no-filesystem movement has worked hard to eradicate this scourge from user experiences, but I fear that this is the devils work. Computer users should know what a file is, and what its for - and they should know what a folder is for, and why they would want to create one to put their files into it ..

But yet: they don't.

It hasn't improved since the 80's. Taking away the users responsibility to understand these things, only makes computing worse. The fact that "special chars in paths" breaks things, also holds this factor into place, imho.

> The no-filesystem movement

Is that the movement to store all your data as an amorphous pile of crap, and then provide easy-to-use search tools to actually find the content you're looking for?

On one hand, I really like the search tools that come from this. But I still like to actually organize my data, so I can browse it if I want to. Also, these search tools seem to only work well enough on macOS and fall flat on their face in Windows. (and no idea where Linux falls on this)

You think space are bad (and yes I'm old enough that I don't use them)... We work with a company that has forward slashes "/" in their trading name and insist on shared cloud directories involving them to be prefixed with that trading name.

As you as you do anything programmatic in/out of these drives it all hits the fan. So I'd add to the original statement - "Avoid 'technical' companies with special characters in their name", it's just not right...

There was some prior discussion about a generational shift here at https://news.ycombinator.com/item?id=28615884 -- there's an idea that people no longer need to know what files or folders are in order to get things done day-to-day with software ( https://www.theverge.com/22684730/students-file-folder-direc... ).

I'm wondering when the first generation of college students will start who have never used a physical keyboard to input text.

If putting spaces in file names makes you queasy, try punctuation - especially punctuation like semicolon or ampersand or single quote that's meaningful to shells and such. <shudder>

Also, emoji.

You don’t name your files with extensions && rm -rf?

Or for more fun, use language specific characters, like äöüß...

And even more fun is, when it mostly works, but then it doesn't and you notice too late.

Honestly, this still causes a lot of problems with some Software. I've had friends asking for help with obscure errors that were ultimately caused by the files they were using being on a path that contains a space or special character.

I've been stuck for years with a bug in my commercial Electron application where images do not get displayed if the folder path has spaces in it :'(

https://github.com/whyboris/Video-Hub-App/issues/667

Any help would be really appreciated!

Shells are indeed the main culprits for the continued fear of spaces, but not the only ones. A lot of programs that deal with "metadata" which will then generate database tables and stuff like that, still struggle when working with any sort of special character. And the same for anything that, behind the scenes, just feeds text into regexes.

Just this weekend I learned that the Espressif Framework doesn't like it aswell.

Our local development environment has evolved to a complex enough sequence of steps to set up and troubleshoot that I spent 2 weeks creating tooling that you can simply point at source checkout locations and the tool will take care to setup that repo.

It broke on the first try on a jr hire's machine, the source checkout location was `C:\source code`.

Slightly off topic but I find myself stuck at being "please for the love of god don't use spaces in git branch names" old. Anno dazumal this might not even have been an issue and I'm just cargo culting.

And on that topic, git branches are case sensitive but windows filesystem API isn't. Git branches are materialized on the filesystem as files and directories.

I enjoy choosing fun branch names from time to time. A few of them: Russian when a user reported a typo in a Russian translation; emoji (mostly added emoji rather than pure emoji); and my personal favourite, a ~250 character diatribe about a single-character bug I was fixing (~250 after I discovered that Git’s error messages when you cause it to try to use file names too long for the file system are fairly mediocre).

Spaces breaking tab completion is still an issue, so, yeah.

ETA: not broken in a technical sense, but having to escape them isn't the best experience. So it's just easier for me to avoid spaces.

Where? It works fine in bash and I think most shells ….

Where I used to work they had a risk system that created directories on the window server that matched the book name. They had a trader that named one of his books "COM1"...

I saw this and felt old, but then the comments in here made me realize that the fear\ is%20real.

I still find them annoying, doing lots of work on the command line. I use this hack:

  #!/usr/local/bin/sbcl --script
  (load "~/.sbclrc2")
  (require 'replace-all)
  (in-package :replace-all)


  (format t "file is ~s" (second sb-ext:*posix-argv*) (probe-file (second sb-ext:*posix-argv*)))
  (let* ((args sb-ext:*posix-argv*)
    (orig (second args) )
    (newfn (if orig
      (replace-all orig "(" "-") 
      orig))
    (newfn1 (replace-all newfn ")" "_"))
    (newfn2 (replace-all newfn1 " " "-"))
    (newfn3 (replace-all newfn2 "&" "-"))
    (newfn4 (replace-all newfn3 ":" "-")))
    (when orig
 (format t "renaming \"~a\" to \"~a\"~%" orig newfn4)
 (multiple-value-bind (new-name old-truename true-newname)
  (rename-file orig newfn4)
   (format nil "new-name ~a old-true ~a new true ~a" new-name old-truename true-newname))))

Spaces in file names break half of the shell scripts I have encountered.

And it is one of the biggest reason I hate Unix shells as programming languages, it is a minefield. In fact I think that after a dozen lines, Perl is a better option. It has most of what shells are good at (i.e. running commands), but saner and more powerful.

my god, I was simply trying to loop over every file in a dir and zip it in a bash one liner. Of course, some of the inputs had spaces in the file names. What an exercise in frustration!!!

Yes, spaces in filenames introduce edge cases and bugs that people are not always aware of.

E.g. Here's a random StackOverflow q&a about a Git pre-commit hook where the top-voted answer does not properly handle filenames with spaces : https://stackoverflow.com/questions/2412450/git-pre-commit-h...

However, the 2nd and 3rd most upvoted answers do mention "-z" option to handle spaces.: https://stackoverflow.com/questions/2412450/git-pre-commit-h...

Remember when we put + instead of %20? Spaces in URL's are still a nightmare IMO. I still get strange access log entries where some encoding went lose, especially in heavy Javascript enviroments.

Same goes for capitalisation. All filenames should be lowercase.

Maybe it's not strictly necessary, it can avoid headaches.

Plus sign actually came from https://en.wikipedia.org/wiki/Query_string#Indexed_search

I had a guy in my team use forward slashes in filenames. Terrible idea, caused all sorts of weird issues.

But nice for testing. I spend a few month on Windows while doing a Django project and found a number of bugs no one else discovered because they used Mac or Linux.

How was this possible? None of the mainstream operating systems allow this.

Did you mean backslashes? I don't know if any filesystem/OS supports forward slashes in filenames

It's not a matter of being afraid, spaces in filenames are annoying.

I mostly use the shell and navigating in directories with spaces is annoying, you have either to quote it or put a \ before each space. You also have to remember to quote everything, and in bash that can become complex, you start adding quotes everywhere to solve problems caused by spaces (or other special characters like *) in filenames.

So I prefer to not use them, a simple _ is as readable as a space. Only thing is that spaces gets rendered better on graphical file managers, but... that could have been solved (and can still be solved) by simply adding an option to render a _ as a space graphically if there is no ambiguity. I don't care that much since I don't use graphical file managers that much.

Maybe it's just me, but it always seemed like prohibiting spaces and other special characters was a reasonable way to avoid unnecessary complexity (and the bugs that accompany it) when parsing and navigating directory trees and files.

I'm old enough to remember working with 8.3 filenames in DOS, and while the length limitation was maddening, the space part never was. Then Windows 95 came out and all restrictions were thrown out.

Why couldn't we just have a file system that robustly supports long filenames, including variable length extensions, while prohibiting certain special characters - namely spaces, slashes or any directory denoting characters in files, and characters that have special meaning in regex context? (brackets, asterisk, etc.)

Related: David Wheeler's Fixing Unix/Linux/POSIX Filenames

https://dwheeler.com/essays/fixing-unix-linux-filenames.html

By coincidence, I found another reason just two days ago. A web app lists uploaded files’ names, and (in a rarely used context) lets the user search for them. One user has copied a file name from the web page, and pasted it into the search box, but got no results. Turned out that the file name contained two consecutive spaces, which the browser turns into a single space, hence no match. Every layer between the user and file system can do something unexpected.

I nearly gave up on learning newer front-end JavaScript stuff like React & webpack and so on a few years ago because of spaces in paths.

node-gyp doesn't like it when there's a space anywhere in your working path. Stuff I was messing around with was all in ~/Code Projects at the time, and using npm install on some things just broke. Looking back, I definitely could have done a better job parsing the error messages but still...

There's an issue but it was closed in 2018 as "The workaround is to use a path without blanks" https://github.com/nodejs/node-gyp/issues/439

Tangentially, I frequently add dates to filenames to keep things organized. And _always_ in the `YYYYMMDD` format for clarity and technical reasons; `DDMMYYYY` (or God forbid the Americans' `MMDDYYYY`) never made much sense to me.

I do this so often that I have an emacs macro or two that helps me out:

  (defun mdy ()
    (interactive)
    (insert (format-time-string "%04Y-%02m-%02d")))

That inserts the "proper" date format (e.g., 2021-11-11) at the current point.

Then to create a date-stamped file name:

  (defun file-mdy (file-name)
    (interactive "sbasename: ")
    (find-file (format "%s-%s.org" (format-time-string "%04Y-%02m-%02d") file-name))
    (save-buffer))

And a few others.

Nobody seems to misunderstand this date format. US folks might find it annoying, but understand what it means.

I have had a huge music library on my RAID, and naturally it had a lot of spaces, and non-ASCII, in the file names.

It's cumbersome-ish, but can be made to work.

Then there's shell injection via files containing a newline character in their name...

POSIX portable file names were defined not to have spaces, and just contain '[[:alnum:]_./]'.

The findnl script as part of fslint identifies problematic patterns, and has 4 levels of stringency, with "POSIX" being the most stringent. https://github.com/pixelb/fslint/blob/master/fslint/findnl

Spaces in filenames were a mistake to begin with.

Spaces are used to separate parameters in the command line. There's also no real need for filenames to support spaces.

Or, one could claim that the poor parsing of a text interface shouldn't dictate the for-human names of files, especially when an exceedingly small percentage of users deal with that text interface.

But, of course, if you mix the abstractions of metadata (filename) with location, things won't be trivial.

The filename belongs to the user. Therefore, it is incumbent on the computer to adapt, not the other way around.

Even if libraries all handled it, I’d still personally avoid spaces because spaces get semantically used to separate tokens and I see file names as tokens.

acme.sh - a shell script that I use to create "Let's Encrypt" SSL certificates - creates and maintains directories with asterisks in them:

https://github.com/acmesh-official/acme.sh/issues/1408

This is the sysadmin equivalent of piercing your nose just to make your parents mad.

Spaces in file names are a poor idea. File names are identifiers, not titles.

Let's test something: http://example.com/my silly webpage.html.

Hey look, HackerNews just broke a URL with spaces in it. And it's written in a Lisp dialect and all; it's not some Unix job cobbed together with shell, sed and awk. The language has a string data type, and strings are passed to functions without word-breaking interpolations taking place.

You know what else breaks on spaces? Basic everyday gui text manipulation.

Suppose that in a block of text we have the sentence:

> Please look for the Holiday Schedule 2021 file.

If you double click on any part of the name like Schedule, pretty much every text widget on the planet will just select only that word, and not the entire filename.

However, if you have:

> Please look for the holiday-schedule-2021 file.

There is at least a ghost of a chance that a semi-intelligent GUI can pick that out as a word.

There exist good reasons to keep identifiers as clump beyond just command line shells.

It's why we need encoding like %20 in URLs that never pass through a shell script.

I don't use spaces, because I want to be able to run ad-hoc shell one-liners when working with my data without worrying about quotation and similar stuff.

I also don't use :, as I have ran into problems with both Bash and its completion and FAT FS. Unfortunately, I routinely have timestamps in filenames, so I need to use +%F-%H-%M-%S instead of simple +%F-%T.

One thing has improved, though: I have not run into problems with ěščřžýáíé (which my language is full of) for maybe a decade, except on OpenWRT where space seems to be scarce to support non-ascii.

Edit: I now remember one problem, getting images for a website from an OS X user, which used combining characters instead of direct code points (https://en.wikipedia.org/wiki/Unicode_equivalence#Example), but HTTP requests got normalized in some browsers, leading to strange 404s.

That's funny because the first operating system I used (Apple DOS 3.3) was very liberal about file names. There was a 30-character limit which was a lot, and it didn't mind spaces in file names. Even control characters were fair game, which made things fun when you accidentally inserted a ^A in a SAVE command.

File names shouldn't have anything except a-z,0-9,_ and perhaps a -. No unicode, no spaces, no nulls.

It's not fear that keeps me from using spaces in file names, it's habit.

If we're going to play this dangerous game, from now on I'll figure out how to use nulls (\0) in my file names, and make all the C/C++ programmers cry.

I don't use spaces because it's so much faster to type filenames out (including with TAB-completion) in the terminal.

I do, however, use Cyrillic (UTF-8) in filenames, and I regularly try out if moving a file into ASCII-path will let some programs open it (half the time it's that when I am having trouble).

It's just such a pain in the butt to work with files with spaces. In a script it's fine b/c I just surround it in double quotes, but on the command line I hate having to escape the spaces.

This might already exist, but I wonder about a terminal that was really just a multi-line repl to a language. It would be preloaded with libraries that replicated all the features of the gnu core utils, but instead of calling grep like normal, you called a function like grep("args"). The advantage would be that you had access to a full blown programming language at all times. So when you needed to do something more complicated you would still have access to all the standard language features. And when you didn't need that, your canned core utils like functions would work

Coming from web-heavy and perl5 backgrounds, it's insane to me that people don't treat filenames and arguments and environment variables as tainted user input, and just blindly trust properties about them like "does not contain whitespace or control characters".

I had to move my development folders because you can't develop Android apps if your project path contains a space. Not sure where the issue is, if it's gradle or something else.

Edit: thinking about it again, it might not have even been the space but the exclamation mark in my path. Or both.

If any of you reading this have to deal with very large scale data pipelines for data science / ML type processing, and if "don't use spaces and weird chars in file names" hasn't become second nature by now, let me just say: you are very, very brave.

My first job as a SW Eng was in 1989 in the nuclear industry. Our folders and files were limited to 8 letters. So names were effectively acronyms. It was actually pretty awesome. Clean and concise. Years later, I still remembered the whole folder structure.

If you're in tech long enough, you can be traumatized by anything. Like the time a vendor-supplied system decided after an update that nothing could have a hyphen in the title, and a lot of existing content just... broke at once. Fun times.

Spaces in file names are a nightmare in Makefiles.

Not if you are careful (a bit like "$@" vs $@ in shell scripts).

Edit: replace $@ with quoted version which actually changes the behavior (I was wrong that the difference is between $* and $@).

Not exactly spaces, but I have been bitten by something like this at my work quite recently. A Confluence page with special characters in the page title was working fine for a while. At some point there was a Confluence version update which made the page URL broken (and apparently unrecoverable, or at least not easily recoverable).

One way to look at it is that people of a certain generation eschew spaces because the tools of their formative years simply couldn't handle spaces - but another is that the olds have learned that generally erring on the side of KISS ("Keep it simple, stupid!") isn't a bad idea.

Software engineers - particularly of the more embedded variety - absolutely still have this problem.

The main culprit is GNU Make which does not cope with spaces in filenames. As far as it is concerned an array is a string separated by spaces so it gets very confused. Yes there are some partial workarounds, no none of them consistently work. You learn very quickly to check all code out in a file tree with no spaces in it, otherwise builds can randomly break in strange ways. It's not always clear up front whether Make is going to be involved somewhere in the build, so it's just easier to be safe.

My username has been my name which has an accented character and has broken countless Windows apps every year since forever, so I just keep a C:/Programs folder where I run stuff. You should never not fear filenames.

I recently find out a windows folder can't end by a space.. But python for example you can create this folder 'example ' every file you create in this folder will be inaccessible, and impossible to delete.

I've never created a filesystem entry name with a space. Mainly because fear and when fear is not proven, "\" looks so ugly. But I think I'm even worse, I dislike capital letters too.

On a similar note: “it makes sense to add a date to a file name” years old.

Nothing old about that; lots of stuff is still broken. What are the odds Homebrew works if installed to a directory with a space in the name? Maybe the core brew manager itself, but all the packages?

I tend to follow a Postel-like system when it comes to this. When I write a script I'll usually get paranoid and make at least token efforts to handle spaces. Which I will then never, ever use.

I have come back to this thread, which I have spotted and forgotten something like two days ago, to say that just like a minute ago one of new Jenkins jobs that I added failed because I named the item using space and some custom Gradle/Maven magic tool failed to load one of its own auto generated files (I could tell that space was the culprit because error message printed only second half of item name).

How can I not be afraid of spaces if this happens like every other day with every other custom tool ...

Spaces are still not "permitted" in URLs.

Browsers will take http://example.com/some name.pdf and automagically turn it into http://example.com/some%20name.pdf, and deliver the goods without a problem. But having that space in the URL is still out of spec, and will cause your web page to fail validation, even though it works fine.

Let me tell you how much of a pain in the ass that my employer forces spaces in the corporate OneDrive directory.

PS-Microsoft is horrible about stupidly named folders being created and dumped in there.

I'm still afraid of any non-8.3 filename.

https://en.wikipedia.org/wiki/8.3_filename

And honestly, it's a good fear to have; there are contexts where it still just doesn't work.

Last I checked, the standard answer for GNU make is "Spaces are expected to break the tool, that's working as intended, it will never be fixed." And because we build our towering edifices of software on the pillars of the past, I can't guarantee to you that a project of arbitrary complexity won't try to cram a list of filenames through a make script.

I don’t think this is so much an age thing as a programmer thing. Old people will still name files all sorts of things, and a lot of young programmers today avoid spaces.

If you're developing on Windows, I find a good way of dealing with this to convert paths to short format before using them (E.G. GetShortPathName in kernel32.dll).

Not afraid, but typing a dash in the terminal is easier and shorter than typing a reverse slash and a space. Spaces are kind of a pain in the ass in the terminal, tbh.

This seems like a case for an axiom I hear infrequently, but I think comes up a lot - things that seem like they should be simple and easy, but are in fact difficult.

I must be nightmare customer, because I've always been exploiting my ability to use filenames in full UTF-8. I'm that guy that sends .pdf to your website.

Why stop here? Why not put spaces in your variable names also? Allowing spaces only in file names and not in variable names is short-sighted when not inconsistent.

My proposal for a shell on the Mac, in the late 80s, was:

- Spaces in filenames get transformed to non-breaking spaces by the filesystem;

- The filesystem treats nbsp as equal to space (just as case-folding treats A=a, B=b, etc.)

Now, argument parsing, mouse double-clicks, etc. all respect filenames as "words", and the output from things like 'ls' just work.

(Yes, I'm well aware that there are case-sensitive filesystems out there. I'd forgotten that iOS was one of those).

As a software engineer, I require testing of paths and files in spaces, and forbid the use of spaces for any system generated file possible to make cli easier.

It messes with tab completion in bash is why I avoid spaces

I do it the other way around. I used to be afraid of spaces. But I have come to realize that it is better to learn sooner than later which pieces of software is in such a bad state that they aren’t handling spaces correctly.

That being said, even after all these years I sometimes need to try a few times in order to get the quoting and the escapes right when communicating names of files with spaces through multiple layers of software.

I like to store data on USB flash drives. After being left to mature for a few years in a humidity and temperature environment, you get some really interesting and complex byte streams where your original file names used to be.

Often they are not even valid UTF8 which, when you uncork the filesystem for the first time in a decade causes the most delightful crashes. The more years the better the aroma.

I'm »still tempted to write umlauts like 'Mot"orhead' old.«

But also a "use a font that has a proper capital ß" hipster.

Spaces in file names are a bad idea because spaces delimit the name of separate distinct files,

At least in my crazy old illogical head anyway.

I'm hoping to one day be "Windows adds user root folder to the quick links in explorer by default" years old.

I always format my filesystems (macOS) as case sensitive and I'm surprised by the software that has a hard time with that.

On Unix/Linux we've grown up with case sensitive by default but everywhere else it still seems to be a problem now and again.

I should qualify this...I'm en-US so I have no idea what the experience is like for anyone else.

You need them for URL's. Running a stand-alone web page maker using Rust. Document structure:

    [Introduction](./Introduction.md)\\
    [Chapter One](./chapter one.md)\\

Crashed on trying to deal with building html when there are spaces in the file name. It is still an issue.

I have been following the guidelines from this presentation for all my filenames, everywhere and it has been working well so far - https://speakerdeck.com/jennybc/how-to-name-files

Today, WSL will try to add PATH in Windows to PATH in Linux. So if you install something like NodeJS in Windows, and run node in Linux, it will try to call /mnt/c/Program Files/nodejs/node.exe and say "no such file or directory: /mnt/c/Program".

I had half a feeling that the warning against using spaces in names pre-dates computing, but after a little research into library call numbers and archive accession numbers, which turn out to have both historically included spaces, I have found no evidence to support this feeling.

It seems to me that many of the problems associated with spaces in filenames are due the OS assuming that a space signals the end of a command or filename.

Maybe we ought have to a different character signify the end of a name? Or signfiy a option section, or the next option section of a command?

In the shell spaces have to be escaped which is annoying. This doesn't change with age I think

And I'm older than Google. If you want some hilarity, newlines are allowed in filenames as well (\n, \r, \r\n). Try getting bash to handle that! (It's possible, though annoying. try redirecting to `while read line` in addition to xargs -print0 hackery)

I've never had any problems with this. At this point, it's second nature for me to either use underscores for spaces, or camel caps if there aren't any single character words like 'i' or 'a' in my desired file name.

Yes, but working with filenames with spaces in them is a huge PITA in command-line tools, because you have to quote everything. The ergonomics is just really annoying.

Personally I wish console shells had chosen another delimiter than space, but here we are.

Not obeying the "Robustness Principle" in software is just poor engineering.

https://en.wikipedia.org/wiki/Robustness_principle

I'm apparently in the minority of people who know how to write shell scripts that have a chance of working correctly with filenames with spaces in them... and that's not the only reason I avoid spaces in filenames. :)

I have experienced a person using a space in a password for Windows login.

I still don't know how to process this emotionally. Either it is somehow naively really genius, or stupid.

In any case, it scares me, mostly because it is a non-IT person.

Reminds me of the time I watched a coworker's head explode when he tried to extract an archive (from a 'Nix environment) on his Windows machine and was indignant about getting duplicate filename errors.

I work in Azure Data Factory, and there are places where a space in a name will cause you difficult to troubleshoot errors. But I can never remember where. It's not universal. So I just avoid them entirely.

I still use the "web safe palette" when choosing color codes for CSS

So, born today, eh?—says the guy who still regularly runs into build scripts that cheerily command that they be run from directories without spaces, since that's easier than proper quoting in the script.

I'm newly afraid to use emojis in domain names: https://tinyprojects.dev/projects/mailoji

The meta point here is that spaces are the type of thing that work fine ... until they don't. This class of bug is best avoided entirely, especially if there is an easy workaround (not using spaces).

But it still breaks in so many situations and becomes a pain in the ass in so many other ones! I HATE people who use spaces in file names. For me it is a sign of a "deeply nontechnical person".

Oh, yeah. Me too!

Except nowadays I worry more about user names that get fed into collaborating applications (with different edit criteria) and password characters (again for systems with differing, strange edit rules.)

I name almost everything with underlines still. I think it’s a programming habit.

Although lately I have started saving my Logic Pro files with spaces, simply because I prefer it to be the name of the song as-is.

I still use the Netbios limitations (15 Characters) when naming servers

I'm “still afraid to use spaces in file names” wise, dammit!

No way I would put anything but a-z, 0-9, and underscore in any file name. Too many stupid ways it can go wrong. I guess I have very little trust in my fellow programmers!

Spaces in path are a pain for the shell autocompletion, since you have to escape them by using either "" for the whole string or use the "\ " instead.

Me too. Afraid of dashes too as they might be interpreted as minus. I use a lot of underscores __ _____ _ _ _

Weirdly, my friend hates underscores. But he's a baseball fan

I know I can put spaces in file names, but \ is one of the characters I still can't touch type, so I still hate dealing with them in the terminal.

ascii, no spaces for me

i still get issues with old one-off scripts, that still work, and I forgot to properly quote stuff... plus the urls are pain in the ass with the %20;s.

I wonder why "space" wasn't always simply treated as another character. To save a couple bytes back in the 50s (when it mattered) I assume?

Any shell script that uses files should use double quotes for at least the variables: `mv $1 $2` is not safe, should be `mv "$1" "$2"`

I'm 19 now and learned this advice from my dad growing up. Still run into situations in my IT work and programming stuff where it makes a difference.

Our tool has no issues with spaces in fields, but we still advise users not to do it because other systems OFTEN STILL DO, in the year of our lord 2021.

I try to avoid spaces and special characters because issues still happen to this day (just yesterday, I had an issue with a file with an accent in it).

My coworkers still don't quote strings in their bash scripts, even when they're paths... and yet they wonder why everything falls apart.

There was a Discussion yesterday at work about allowing quotation marks and semicolons in some user-set titles. We use Mongo. But I empathize.

I'm not "afraid" of it, I just think it's unnecessarily compicated to work with spaces in filenames on the command line.

You should be still afraid. Many commands such as Unix "xargs" don't work properly with spaces if the right flag is omitted.

If you're working on cli this is reasonable

Why stop at spaces?

An old prof of mine used to send emails where the subject line was always a valid identifier in C.

Hello_dear_students_where_are_your_reports_

All because we use programmatically interfaces that were intended for humans to write: command line, sql, html, email headers.

This is why \Program Files, and \Program Files(x86) exist as they do. With spaces, and strange characters, in the name.

Can someone convince me to not use spaces in music, film, and book files where they have a "standard title"?

Some react scripts freaked out on me recently because my login (and thus user folder) in windows contained a space.

I think people who use a terminal interface, regardless of OS, don't like spaces in file names. I avoid them.

Then you must also be "still afraid to write Python instead of Bash scripts" years old, too.

I dislike constantly having to backslash escape files on the command line, so I use dashes instead.

I won't use a space if I think I may need to address that file from the command line...

I'm "still afraid to use more than 8.3 characters in file names" years old!

I'm "8 characters max plus a 3 character extension in your file names" old.

Kids these days will say “What’s a file name?” and mean it. Typing? That’s for the olds.

Never use spaces in file names. It shouldn't depend on age, it's common sense.

Yep. Me too. Early bad experience with spaces in file name and Unix cured me of that.

Sort of related, but here's a joke: Windows 95 does support long filena~1

I\ am\ not\ afraid,\ I\ just\ do\ not\ see\ how\ it\ benefits\ my\ quality\ of\ life.

The nice thing about spaces is there are so many to choose from, thanks to Unicode.

I still feel slight unease sometimes when using more characters than 8.3

Damn, I feel old now :P

Maybe if we'd do it more software would actually learn to deal with it.

"You need to add --print0 to your find call and -0 to your xargs."

Literally just fixed a bug in our software because of an issue with spaces.

I'm still afraid to use national specific characters in file names...

Keep%20the%20names%40and%20links%20readable%20or%20submit%20to%20encoding

Without exception, I never ever ever use spaces in filenames. Ever.

2021-11-11_I_have_absolutely_no_idea_what_you_are_talking_about.txt

I don't know that this is really hacker news material guys...

This is a general issue to this day. So that isn't very old.

I'm "whitespace as syntax is stupid" years old

Python has made me afraid to use hyphens in file names

The Amiga supported spaces in filenames in 1985... =-)

Admittedly trite/unhelpful comment: avoid xargs

I\'m%20still%20afraid%20to%20use%spaces%20too.

Years of Java has me seeing the world in camel case

If a filename doesn't match \w+\.\w+ I hate it

I love it when characters like | break OneDrive

I don’t even use spaces in csv column names

Yet another reason to ditch Make /s

Heck, I'm still afraid to use caps!

Anything more than 8.3 is for sissies.

What about long filenames and paths?

Instead of spaces I just use U+2215

You mean, I'm linux years old?

Well, I'm using makefiles old

Wait, what's a file? :P

Base64 is your best friend!

I_promise_I'm_not.

Me too, I never do it.

I’m 15. I am as well.

I can relate! :)

me too… still use underscore all the time.

Yep. Yep yep.

You can now?

or Capital letters

i feel so seen

tbh using spaces in file names is still stupid.

Anyone else totally fine with spaces in filenames? I use to rip a lot of CDs back in the day, and never had an issue with the spaces in the file names.

01 - Metallica - Metallica - For Whom the Bell Tolls.mp3

Names like that were common, and had many spaces.

Reply on news.ycombinator.com