Hacker News Reader

Comment by nicetryguy | Hacker News Reader

As a related anecdote, you NEVER want to put whitespace in filepaths. Ever. Tons of programs will just break, even in 2023, even Microsoft ones (looking at you Powershell), and i'd imagine forevermore.

Your life will end up as a series of awful MYPATH~1\ kludges. You have been warned.

EDIT: There seems to be different camps here and perhaps a generational divide. Maybe the kids haven't (or never will be) burned with this one, but i've seen too much, wasted too many hours, wrote too many workarounds, and will forever remain #TeamNoWhiteSpace.

View on HN

Counterpoint: Nearly all of my (thousands of) users use whitespace in basically every single folder name and file name every single day (which are usually titles of papers or experiments), and none of them ever have any problems.

When writing software I always make sure that all my test data has spaces - and not just the normal one but weird unicode ones too - in paths and filenames.

This is a fascinating weekly topic for me :-)

I grew up in days of DOS 3 and onward, so I am basically physically incapable of using whitespace in filenames. And frequently I'll replace white spaces with underscores on files shared with me.

Fascinatingly though (and sometimes irritatingly), several of my mentors have cautioned me to drop this habit as I get promoted. At management level, they all use white space and dots haphazardly, and they apparently perceive underscored filenames negatively. This goes up drastically at executive level.

Interesting observation. I can exactly see where the low status comes from.

That's... definitely not as dramatic as you try to make it sound. "Program Files" and "Documents and Settings" have been around for almost three decades, and most programs work just fine with files living somewhere inside those paths.

I mean, let’s go past “Program Files” to “Program Files (x86)” which has both spaces and special characters, and which was moved from the former.

And most programs are able to handle that just fine.

And the "cherry on top" is there's an env-var named `%ProgramFiles(x86)%` (aka `${env:ProgramFiles(x86)}` in PS) that points to where that directory actually lives since AFAIK it's controlled by a registry entry

Sure, but that's because everyone uses SHGetFolderPath or Environment.GetFolderPath to get these paths instead of hardcoding them. Right? Right??

> maybe the kids

Really? You posted a divisive and absolute statement and people pointed out how it's not accurate. Considering "Program Files", a very common Windows path, was introduced back in Windows 95 (https://devblogs.microsoft.com/oldnewthing/20120307-00/?p=81...), almost 30 years ago, it's pretty hard to blame it on "the kids".

That doesn't sound like "those damn kids and their newfangled apps that can handle spaces, they'll never know the pain I went through!!!" and more like "I said something that was clearly not accurate and people pushed back".

The whole thing reeks of https://www.mouser.com/blog/Portals/11/mrb-singularity-f1.pn...

I've had lots of programs, libraries and scripts freak out from having whitespace in a file path.

> I said something that was clearly not accurate and people pushed back

Is my life experience invalid? It's a needless error that i never want to deal with again. I cover my mouth when i cough, i use my turn signal when changing lanes, and i don't put whitespace in a filepath or a URL. It's that simple.

What i cannot fathom for the life of me, on HN of all places, is vehemently defending a practice that is not guaranteed to work 100% of the time: "Well iiiive never grazed an oven coil pulling a potroast out of the oven so obviously this guy is an idiot for advocating oven mitts." Give me a break dude.

It’s almost as if, get this, it’s not a problem, let alone anywhere even remotely in the vicinity of a problem of the scale and magnitude you claim it to be.

It’s almost as if people in 2023 get by fine with spaces in their filenames whereas you seem to be stuck squarely in the 1980s.

I know, it’s a crazy idea. Those kids and their insanity. /s

> you seem to be stuck squarely in the 1980s.

You know, my main hobby is writing ASM for classic video game consoles, and my opinions and experience involves lots of janky / homemade / antiquated programs, so honestly you're not wrong =p

Microsoft called the directory where programs are installed "Program Files" and documents in "My Documents" specifically so that developers would have to learn to deal with spaces immediately.

Curious about PowerShell misbehaving there. Care to share any details? Typically you never want to handle paths to files as strings, or at least resolve them to File/DirectoryInfo objects as soon as possible. But the only real blunder regarding paths in PowerShell I'm aware of is the Path parameter to various cmdlets and having [] in file names (which is why LiteralPath always exists alongside Path parameters).

$args[x] breaks. Get-Content breaks. probably more.

...admittedly i'm not the best with Powershell. There are probably workarounds or things that i did wrong.

Just put them in quotes. PowerShell is infinitely better than bash/zsh/... at handling spaces. You're spreading nonsense.

> Just use quotes bro

Man, it's never that simple. How about generating Powershell scripts with quotes? Sometimes you are dealing with escape characters \", sometimes you aren't. Why bother with all that? Hell, versions of software and compilers change such behaviors either on purpose or by accident all the time. It just gets messy dude. C:\NEVER_~1\AGAIN_~1.NOP

Perhaps i'm a dinosaur still scarred by the golden olden days, but, there is no convincing me that whitespace in filenames or URLs is ever a good idea.

I don't know what to tell you. You gave two examples that aren't actually issues. But if there's no convincing you, I won't bother. Have a nice day.

> You gave two examples that aren't actually issues.

Man, i've had config files break because i saved them in UTF-8 instead of ANSI. I hope to god you never have to experience the horror... You also have a nice day.

This is getting less and less relevant.

> Man, i've had config files break because i saved them in UTF-8 instead of ANSI.

Isn't this because random Windows tools add garbage bytes to the start of the file (a "byte order marker") and then don't tell you they did this?

It's not the encoding that's the problem, it's the garbage bytes.

P.S. I do know of exactly one program that only accepts UTF-16 for its config file, and won't accept UTF-8 or ANSI.

Came here to mention []. For those who haven't looked it up, in addition to * and ? as wildcard characters, PowerShell supports "[xyz]" and "[a-z]", meaning "x y or z" and "anything from a to z", so "[a-z]alls" would match calls, falls, walls, etc.

I knew the guy who tested the feature in PowerShell and he was deeply frustrated over the fact that there was no way to escape some sequences. For example, you can loosely match "[abc]" with something like "?abc?" or "[[]abc?" because the [[] indicates exactly one opening square bracket but there's no way (as far as I know) to say "this section ends with a square bracket".

The PM really wanted that feature, though, even though you could probably count on one hand how many times it's been used in real life.

Edit: That guy down there corrected my example.

Uh... You can escape these sequences. But the escape character isn't the backslash for obvious reasons (it's the path separator). It's the backtick.

    > ni '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi '[abc]'

    # no output - would have matched files named a, b, or c

    > gi '`[abc`]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi -LiteralPath '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi -lp '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

As far as I know that's been in powershell forever.

Ah, OK. This works because you're using single quotes on your strings, meaning the escape sequence `[ is preserved until it reaches the globbing layer. This will not work, for example...

  gi "`[abc`]"

...because the `[ will be processed before the string gets sent to globbing, meaning the back tick will be removed. This would work with double quotes:

  gi "``[abc``]"

...because at the command line level this will evaluate to `[abc`] and the globbing will know that the square brackets are literal. So I will concede and downgrade my complaint from "impossible" to merely "overly complicated for the layman".

Anyone used to scripting languages knows there's a difference between single quotes and double quotes for escaping.

> Anyone used to scripting languages knows there's a difference between single quotes and double quotes for escaping.

Not necessarily. There are all sorts of scripting languages where single and double quotes are identical.

It is, however, super common for there to be escaping differences in shell scripting languages.

Tools in the Unix world aren't too robust in that regard either. Gnu Make is particularly egregious.

There is also gnu patch: the filenames in the unified patch file format can't contain spaces and can't be quoted so... just don't use spaces, I guess.

how old is your copy of patch?

    $ cat > my.patch <<PATCH
    diff --git a/alpha beta/charlie b/alpha beta/charlie
    new file mode 100644
    index 0000000..3b18e51
    --- /dev/null
    +++ b/alpha beta/charlie        
    @@ -0,0 +1 @@
    +hello world
    PATCH
    $ patch -p1 < my.patch 
    patching file 'alpha beta/charlie'

    $ patch --version
    GNU patch 2.7.6

EDIT2: IT JUST HAPPENED AGAIN trying to add a Windows Environment Variable in Program Files from Visual Studio 2022. UGH!!!!

Feast your eyes on this abomination doubters:

C:\PROGRA~1\MICROS~4\2022\COMMUN~1\VC\Tools\MSVC\1435~1.322\bin\Hostx64\x64\ml64.exe

This is using a Microsoft development program with a Windows Environment Variable, mind you...

Non-ASCII characters too, if situation allows. Lots of apps aren’t tested to work with that whatever “new” API.

I know someone with an é in his name. He once made the mistake of using that character in his username.

Windows broke. Programs broke. The registry broke. Special characters work well enough, but never use them in standard directory paths.

If you want your folder to be written correctly in your own language, you can use desktop.ini to correct the name of the folder in Windows Explorer:

    [.ShellClassInfo]
    LocalizedResourceName=Fàñćŷ Näm̀é

Put that into a desktop.ini file, assign it the right attributes (`attrib +S +H desktop.ini`) and your folder will look right in any program that uses the shell API without any risk of breaking programs.

Reply on news.ycombinator.com