Kids these days will say “What’s a file name?” and mean it. Typing? That’s for the olds.
I'm “still afraid to use spaces in file names” years old
771–780 of 817 posts
Re: I'm “still afraid to use spaces in file names” years old
#772Earlier quoted context omitted.
Docker relies on LXC, so it's Linux-only. On other platforms it runs in a Linux VM. The host for Docker, then, is Linux no matter where you are.
> Docker relies on LXC, so it's Linux-only. Docker hasn't supported LXC since 2016, and stopped relying on it in 2014 https://www.docker.com/blog/docker-0-9-introducing-execution...
I thought the name for the collection of kernel features was LXC, I didn't realize (until just now) that was the name only for the also-kernel-level wrapper for those features, which name does not cover the features themselves. That is, I didn't realize that LXC is to Cgroups+Namespaces as Libvirt is to KVM—I thought LXC, as a label, covered the whole feature-set—but regardless, it's still married to Linux kernel features and runs on other platforms under virtualization, no?
Re: I'm “still afraid to use spaces in file names” years old
#773Earlier quoted context omitted.
Having used a lot of all the formats, it's argue it's a lot easier to read an a tiny bit harder to type. For typing it's basically just an extra `-` because unless your alternative is nocase. For reading, CamelCase has 2 significant ambiguity issues: similarity between I and l, and what do you do with acronyms. Acronyms wouldn't actually be a problem if everybody just wrote them would in snake_case (i.e. only capital…
Adding an underscore everywhere is horrible! The spacebar is huge, and gets your thumbs basically to itself because space will be one of, if not the most commonly typed key. To replace that with one of the least ergonomic keys makes no sense. And if CamelCase is so hard to read, why is it the norm for "high level languages"? Shouldn't those be optimized for ease of use?
> And if CamelCase is so hard to read, why is it the norm for "high level languages"
That's over-selling it a bit. It's more common, but not dramatically so. Outside of class names, CamelCase isn't the norm for Python, PHP, CSS, HTML. It's also not the norm for shell scripting, but shell scripting has horrible readability for other reasons.
I believe CamelCase is more common for languages like Go, C#, and Java because they grew up in large organizations where having god objects/classes with 400 methods is kinda normal and having aMethodWithAReallyLongName is pretty common. One of the advantages of CamelCase is that it does shorten really long names.
Re: I'm “still afraid to use spaces in file names” years old
#774Earlier quoted context omitted.
>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…
OK, I didn’t put this completely correctly. The original separation of /usr to hold user home directories (!) and / to hold everything else was because the first RK05 disk ran out, but it makes sense in any case. The additional hierarchy under /usr was created some time later when space on the first RK05 disk ran out again , and while this can be a perfectly sensible decision for a single installation on a single sit…
Interesting stuff. Thanks for sharing it!
Re: I'm “still afraid to use spaces in file names” years old
#775Earlier quoted context omitted.
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.
Too many characters on Linux? Quite difficult to reach to be fair. Do you have an example?
Re: I'm “still afraid to use spaces in file names” years old
#776Earlier quoted context omitted.
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.
You state that as if that were objective.. but that's not my subjective experience at all. Somehow I have a hard time remembering these long names, (is it --conf or --config or --config-file or --config-path? -c would've done it for me. --set or --set-prop or --set-property or --prop or --property?), and I need to look them up in a man page anyway, and I make more typos typing them, and shell completion rarely works…
I like long form version. It helps me remembering what it does and why. Eg: `iptables --insert INPUT --protocol tcp --jump ACCEPT` was more helpful to me than `iptables -i INPUT -p tcp -j ACCEPT` when told how to allow TCP traffic.
For everyday command like `ls -l` I don't mind but anything more serious I take a more cautious approach.
Re: I'm “still afraid to use spaces in file names” years old
#777Earlier quoted context omitted.
No, it's also a Linux issue.
Too many characters on Linux? Quite difficult to reach to be fair. Do you have an example?
I have been trying to repro with a small nodejs server but either the server cut off the content-disposition filename or firefox truncates it. When I get that in the wild I'll post an update.
In the meantime:
$ touch 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
touch: impossible de faire un touch '1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111': Nom de fichier trop long
Firefox cut off at ~217, httpie at 255.
Re: I'm “still afraid to use spaces in file names” years old
#778Earlier quoted context omitted.
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.
You state that as if that were objective.. but that's not my subjective experience at all. Somehow I have a hard time remembering these long names, (is it --conf or --config or --config-file or --config-path? -c would've done it for me. --set or --set-prop or --set-property or --prop or --property?), and I need to look them up in a man page anyway, and I make more typos typing them, and shell completion rarely works…
The few scripts that I've written for personal use generally lack documentation or help commands of any sort; instead, they take all possible straightforward variants I can think of for each command (`--config`, `--config-file`, `--cfg`, `--conf`, etc). They usually convert everything to lowercase before processing, too. It's easier to fail safely on too much/too little input than it is to provide actual help.
Re: I'm “still afraid to use spaces in file names” years old
#779Still 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 a…
WinSCP currently has a bug that crashes if it tries to sync a folder with a space in the name
Re: I'm “still afraid to use spaces in file names” years old
#780Earlier quoted context omitted.
That's the most beautiful part! After running this script there are no more conflicts, because it just silently overwrites all but one version of the "cleaned" filename. (Also—that entire function is super inefficient and could be replaced with a single invocation of "rename".)
Totally inefficient. But for me it's readable and practical. This is mostly just a convenience function for me to help store files in a format I like rather than something I need optimized. If it ever started to feel slow, sure I could optimize. But for now, when I still occasionally download a file that has some weird character and I just prefer to add another line to my function.
Without changing the design too much, you could rearrange it like so to avoid renaming multiple times and still have the option to just "add another line":
# Rename all files in a directory
rn() {
rename \
-e "s/ /-/g" \
-e "s/_/-/g" \
-e "s/–/-/g" \
-e "s/://g" \
-e "s/\(//g" \
-e "s/\)//g" \
-e "s/\[//g" \
-e "s/\]//g" \
-e 's/"//g' \
-e "s/'//g" \
-e "s/,//g" \
-e "y/A-Z/a-z/" \
-e "s/---/--/g" \
-e "s/---/--/g" \
*
}
# Rename all files in a directory
rn() {
rename \
-e 's/[ _—]/-/g' \
-e 's/[:\(\)\[\]",]//g' \
-e "s/'//g" \
-e 'y/A-Z/a-z/' \
-e 's/--+/--/g' \
*
}