I'm “still afraid to use spaces in file names” years old
541–550 of 817 posts
Re: I'm “still afraid to use spaces in file names” years old
#542I'm hardly afraid but I just think it's poor ergonomics. Same as the move from xset m 0 0 to 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…
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.
The amount of time that has been wasted by Windows using "C:\Program Files" instead of "C:\Program_Files" far outweighs any highly questionable aesthetic benefit IMO.
Re: I'm “still afraid to use spaces in file names” years old
#543Earlier quoted context omitted.
Word of warning from hard experience: rn is a really dangerous thing to name a function because it is one char away from rm.
One char away also physically on the keyboard (maybe that's what you meant?).
Re: I'm “still afraid to use spaces in file names” years old
#544Earlier quoted context omitted.
You’re clearly a more capable user than me, but even so, take care. The time I accidentally moved /etc has scarred me for life.
Early on in my Linux-using-life I made the mistake of deleting /etc. That was a learning experience like no other :)
Probably the easiest way to experiment these days is to create a VM and make snapshot, then start knocking down walls, just to see when and where the house collapses. Then revert and try something new.
Re: I'm “still afraid to use spaces in file names” years old
#545Earlier quoted context omitted.
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.
only allow ASCII, maybe dashes, and up to twelve characters. Problem solved ...and only hire people from the exact same background as you, who will never have unusual characters or accents in their name. And also make sure not to have any users who aren't exactly like you, and conform to this very narrow requirement. Surely, excluding 90% of the world won't hurt revenue in any way.
Re: I'm “still afraid to use spaces in file names” years old
#546Earlier quoted context omitted.
Ugh, we have the 15 character Active Directory limit now with hostnames, and a previous IT administration has imposed a convention that every name had to follow [prod|dev]-[ph|vm]-[service]-[nn]. So basically every production service is prod-vm-owtf-01— you get exactly four characters to actually describe what the machine does. Works great when the service is "jira" or "wiki", but there are a lot that are pretty myst…
I kind of like that honestly. No doubt you need some documentation so everyone knows what the service abbreviations are, but after you've been working there for a month you get it. Makes everything clean, consistent, and informational. You can quickly ascertain what a specific host is doing just from the name.
Anyway, all this was fine when we were on LDAP rather than Active Directory. So basically it's all Windows' fault.
Re: I'm “still afraid to use spaces in file names” years old
#547Re: I'm “still afraid to use spaces in file names” years old
#548Re: I'm “still afraid to use spaces in file names” years old
#549Earlier quoted context omitted.
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?
> By the way: what's your beef with en dashes? Of all the changes in that list, removing the character that doesn't appear on a standard keyboard seems like the least controversial...