Me too, I never do it.
I'm “still afraid to use spaces in file names” years old
731–740 of 817 posts
Re: I'm “still afraid to use spaces in file names” years old
#732Earlier quoted context omitted.
Yeah, except that tells me nothing useful... The question is exactly the same: So where do I install this random binary I downloaded from the internet or compiled myself? Is it /opt, /usr/bin, /usr/local/bin, or /bin? Where do I put the dependencies I compiled for this software - /usr/lib, /usr/local/lib, /lib, /opt/lib, /opt/ /lib, or what?
The standard is, indeed, excessively vague because it was written to let many existing implementations be conformant as is, though I’d say it’s still more helpful than many other standards with that deficiency. There’s a method to it, however: - Things installed in /, if it’s different from / usr , are generally not to be touched; - Things installed in / usr are under the distro’s purview or otherwise under a package…
>the original separation of / and /usr happened for intensely silly reasons
As I recall, there were very good reasons for separating / and /usr (as well as /home and /var). The biggest one was that various Unix kernels would panic[0] if / was full. But that issue was almost universally fixed by 1990 or so.
And netmounts of pretty much everything other than / were pretty common for many years, due to the high cost of storage.
So no, the reasons weren't silly, they just don't apply to more modern systems.
Re: I'm “still afraid to use spaces in file names” years old
#733Earlier quoted context omitted.
I still find files on the internet that my browser can't download because too many characters :(. Edit: can't save, downloading works.
This is a Windows-only issue AFAIK. It's the same reason why people decide to put their projects in something like C:\dev Apparently it's quite easy to reach the 260 chars limit
No, it's also a Linux issue.
Re: I'm “still afraid to use spaces in file names” years old
#734I 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 an…
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.
Could you please link the reference?
Re: I'm “still afraid to use spaces in file names” years old
#735Today, 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".
Re: I'm “still afraid to use spaces in file names” years old
#736Earlier quoted context omitted.
That helps, but be warned that there are still programs running around that just hardcode their paths
Cries in nixpkgs (Anyone who tried to package a program that hardcodes the “usual” binary paths know the pain)
Doesn't nix itself hardcode the nix store path though?
Re: I'm “still afraid to use spaces in file names” years old
#737Earlier quoted context omitted.
Early on in my Linux-using-life I made the mistake of deleting /etc. That was a learning experience like no other :)
A couple of weeks after moving to UNIX from MSDOS, I thought I'd remove lots of unnecessary 'dot-directories' from the /tmp directory. I was root as I had no concept of being a 'normal user'. So I ran two simple commands: cd /tmp rm -fr .* and wondered why it was taking so long.
At least that doesn't happen today anymore. From bash:
> When a pattern is used for pathname expansion, the character ``.'' at the start of a name or immediately following a slash must be matched explicitly, unless the shell option dotglob is set. The filenames ``.'' and ``..'' must always be matched explicitly, even if dotglob is set.
Re: I'm “still afraid to use spaces in file names” years old
#738I 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 an…
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.
Re: I'm “still afraid to use spaces in file names” years old
#739Earlier quoted context omitted.
As a programming noob, I'm wondering what would be the better way to pass or return a unix time value as opposed to an integer?
If you need to keep the timezone with it, then use an ISO8601 [0] string: "2021-11-11T15:32:35-07:00". Otherwise, use an integer unix timestamp, the number of seconds since 1970-01-01T00:00:00Z: 1636673555. Use an unsigned 32-bit integer or a 64-bit integer to avoid the 2038 problem [1]. JSON's maximum safe integer value is a signed 53-bit integer, so if you're using HTTP JSON RPC, you'll have to check for overflow.…
ISO8601 is a serialisation format. You wouldn't want to use it in internal function calls simply for performance reasons. You also wouldn't want to pass it around as just a "string" type. I think the question was asking about internal function calls. For external data interchange, ISO8601 is the only sane option and deals with all known timezone and leap second bollocks.
Re: I'm “still afraid to use spaces in file names” years old
#740I 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 an…
> 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
This exact vulnerability in most modern code editors just made the rounds, allowing smuggling malicious code right through review.