Hacker News Reader

Comment by keepamovin | Hacker News Reader

Ahahaha, I love this! I love how this new fandango thing harkens back to the earliest days of MS-DOS when it ran on a 086 or 286, back in the early (very early) 90s.

Have to respect MS' backwards compatibility fanaticism. Impossibly as if a native port of MS Teams would be created for MS-DOS 3.1 (hahahaha). When more plausibly the MS Teams servers run on an ancient crazy proprietary MS-DOS 3.1 mainframe (still implausible, but hey).

I know that this device name restriction also applies to Windows file names, so it's not that surprising (if you are inclined to be less fun than possible), but if you like fun, you can pretend the former.

Relevant frag link: https://learn.microsoft.com/en-us/microsoftteams/limits-spec...

View on HN

earliest days of MS-DOS when it ran on a 086 or 286, back in the early (very early) 90s.

About a decade off: MS-DOS was running on 8086 in the early 80s.

Oh my god. Well i didn’t receive my first one until the 90s. And i grew up thinking i was middle class, my oh my.

depending on your country they might not have been availible before

Well, it's surprising. You can create those files from WSL, but you cannot create or delete them from Windows, that just make no sense. It's more like MS doesn't care to fix those issues. There is no DOS layer anymore in Windows 10 or 11.

Agree BC is a laundable goal and appreciate their efforts. Though I do wish it didn't include limiting passwords to obscenely short lengths or absurd subsets of characters.

Yeah those 8+3 file names sure birthed some creative abbreviations. Necessity, mother, all that

Whenever I create a filename that is long or has spaces, I still pause and worry "okay, what might break if I do this", even though such concerns probably died a couple decades ago.

Actually scripts breaking if files or paths have a space in them seems to be a thorn in the side of dev/ops/it folks that never goes away, does it?

Unix shell scripts will break when filenames/paths have spaces if variable expansions are not quoted, resulting in word splitting and filename expansion (globbing). This is something that is drilled into learners by all good teachers, e.g., https://mywiki.wooledge.org/Quotes#When_Should_You_Quote.3F

Wait until you hear about `make`, completely cementing the idea of '_' as space for decades to come [1]!

Related, any time I join a new group, that uses bash in any capacity, I introduce them all to the `shellcheck` utility [2], and run a shell script of the person with the largest ego through, as a "demo".

[1] https://stackoverflow.com/a/9838604/1487072

[2] Online version: https://www.shellcheck.net/

Awesome! Thanks for introducing me to this. I mean my ego ha

On Unix perhaps. Windows forced IT folks to deal with the issue by having folders like "Program Files". Even the user's folder used to be in "Documents and Settings" (but they backed down from that eventually and now it's just "Users").

To this date one needs to be careful with executing applications and spaces in the path.

For example:

    D:\test>dir
    ...
    08/10/2023  09:29 AM    <DIR>          .
    08/10/2023  09:30 AM    <DIR>          Foo Bar
    08/10/2023  09:35 AM                79 Foo.bat
    ...

    D:\test>dir "Foo Bar"
    ...
    08/10/2023  09:30 AM    <DIR>          .
    08/10/2023  09:29 AM    <DIR>          ..
    08/10/2023  09:35 AM                79 Foo.bat
    ...
        
    D:\test>type Foo.bat
    @echo off
    echo Executable: %0
    echo Path to executable: %~dp0
    echo Params: %*

    D:\test>type "Foo Bar\Foo.bat"
    @echo off
    echo Executable: %0
    echo Path to executable: %~dp0
    echo Params: %*

    D:\test>Foo.bat hello
    Executable: Foo.bat
    Path to executable: D:\test\
    Params: hello
    
    D:\test>Foo Bar\Foo.bat hello
    Executable: Foo
    Path to executable: D:\test\
    Params: Bar\Foo.bat hello
    
    D:\test>"Foo Bar\Foo.bat" hello
    Executable: "Foo Bar\Foo.bat"
    Path to executable: D:\test\Foo Bar\
    Params: hello

    D:\test>

Mess up the quotes and you're executing something one level up.

Right, but my point is that "Program Files" &co were so common that it forced IT people (and everybody else) to handle this correctly. Executing something one level up is not the kind of bug that's going to be unnoticed when it'll be hit so often.

(btw most IT folks prefer powershell, if only because all the management tools are powershell modules)

Nice example!

> but they backed down from that eventually

Only because they were started to hit MAX_PATH there:

    C:\Users\Johnathan Aparecido da Silva\AppData\Local\ASUS\ASUS System Control Interface\AsusSoftwareManager
    C:\Documents and Settings\Johnathan Aparecido da Silva\AppData\Local\ASUS\ASUS System Control Interface\AsusSoftwareManager

The `subst` command provides an easy way around that. Link the last folder somewhere closer to the root, to make longe-than-255 paths accessible. Then, when you're done, remove the link and your files are protected from pesky things like virus/malware scanners.

I used it to hide my old virus/malware collection, made from what my computer was infected with through the years.

This was actually genius, though it was/is so annoying typing these verbose paths

Agree. Those short abbreviations have a kind of crunchy sonic quality when you say them that’s satisfying.

Brevity forces thought, which I prefer to "Putting a Sentence in a File Name.docx".

FORTRAN originally had the same limitation for function names, and that lead to some classics such as GEMM and SAXPY.

When it comes to file names, I disagree that brevity serves a useful purpose. I name my files like I’m an Amazon reseller so that I’m sure to find it with Search later no matter which detail I remember. “Budget Spreadsheet (worked on with Jane) with projections with and without buying a new Tesla Model Y or Chevy Chevrolet Bolt - 2023 2024 2025.xlsx” that’s my idea of a file name.

If it floats your boat, you do you my dude.

But that being said, you're the reason why file systems are abstracted away more and more with all file system queries force fed through some kind of search engine.

> you're the reason why file systems are abstracted away more and more

Citation needed. I'm pretty sure the reason that happened is that Gen Z (and heck, definitely a good chunk of my millennial generation too) weren't ever taught what files and directories even are, so for them to be able to manage, product designers moved to a combo of "Your documents live inside the app you made them with" and "You search for your documents and they'll come up." Notably though, they never solved the other problems the filesystem solves, such as "but where are my files actually, I need to move them between devices or give them to another person."

Modern OSes can search within files for text, which mostly obviates using the filename for keywords.

I bet there are some that do a good job, but my "modern" OS (hint: it's the one that probably has 10x the engineers working on 'cool' UI animations than on the search backend) is absolute trash at relevance when searching contents. Not to mention slow.

A spotlight search for Chevy I get every document on my system that ever mentioned Chevy in random order. Maybe 1000 documents (or 10,000 if it helpfully decides to pull in e-mail, and thus picks up 9,000 marketing emails). If I search names for Chevy I am going to find the file I mentioned and any others where a human decided the file was about a Chevy. Same for Jane. If that's my partner, adding her name will just pull in every document that's ever mentioned her, like every tax form ever. But files named after her is a much smaller set.

They can also search images for subjects, location, etc.

Still, it would have been nice if a standard metadata format could be included with each file, in a way that survives file transfers.

Hahaha! That’s my idea of a file name, too!

Those two are obviously GetExtendedMemoryMap and Saxophone.

I agree with that too. If it works it’s like ideograms or iconography.

Woah, your examples: https://www.ibm.com/docs/en/essl/6.2?topic=vss-saxpy-daxpy-c...

Very loosely related, but I really dislike the excepted design pattern for that cases where functions names are something like AssertThatOnePlusOneIsReturnAlwaysTwoAndNeverFive. It looks ridiculous, smells like a hack, and I cannot think of any reason why giving a description of the test couldn't be handled by the testing framework in a more graceful way.

Me too, I prefer function names like “assert_that_one_plus_one_is_return_always_two_and_never_five.”

All kidding aside, but I gave up on this argument because I think people either get it or don’t and aside from trying a little conversation or something with guidance it’s a “can’t fix stupid” situation.

People usually want to explain why it’s so important and that’s worse than suffering their long function name.

I think it’s better to just accept ridiculous than to try to get consensus on what’s ridiculous and a spiral of wasted time.

The upside is that it doesn’t matter any more since long function names are supported and work. And autocomplete means it’s just as easy to use as “ATOPOIRA” or whatever madness they would name it with some restrictions.

Reply on news.ycombinator.com