Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm “still afraid to use spaces in file names” years old

twitter.com

Post reply on HN
Print view View original

321–330 of 817 posts

Re: I'm “still afraid to use spaces in file names” years old

#321

Post by akovaski »

Joker_vD wrote: post #171
tremon wrote: post #126

Earlier quoted context omitted.

And where it isn't needed. If you have a path that contains a variable and a space, bash will happily escape the $, making the path invalid. See the following: $ cd $HOME $ mkdir my\ dir $ ls my[tab] $ cd / $ ls $HOME/my[tab] ls: cannot access '$HOME/my dir/': No such file or directory That error is because when you press [tab], bash changed the path to \$HOME/my\ dir/ but that isn't obvious from the output and I cou…

Depends on the Bash version, I guess? Mine is 4.4.20(1) and when I do "cd $HOME/my[TAB]", it replaces the input line with "cd /home/joker/my\ dir/", and pressing [ENTER] changes the directory to '/home/joker/my dir', as can be seen from the prompt.

The variable escaping behavior has existed for a while https://stackoverflow.com/questions/32463052/bash-tabbing-fo... https://askubuntu.com/questions/70750/how-to-get-bash-to-sto... https://askubuntu.com/questions/41891/bash-auto-complete-for...

And I experience the problematic behavior on my Ubuntu VM. However, I can get the above describe expansion behavior if I run: shopt -s direxpand

Re: I'm “still afraid to use spaces in file names” years old

#323

Post by dwheeler »

VWWHFSfQ wrote: post #300
dahfizz wrote: post #213

Earlier quoted context omitted.

> I have an uneasy feeling whenever I see a path parameter declared as string. Path is not a string I guess that depends on what you mean by "string". `open` and `fopen` need a char* path to open a file. Whatever fancy Path abstraction you use eventually becomes a char* string, because that's what the kernel needs.

yeah. it's a string.

On POSIX systems file names are not strings, they are sequences of bytes. They might not be UTF-8 or have any meaning. Python3 had to hack around this, they thought they could force everything to Unicode and discovered that doesn't work.

Re: I'm “still afraid to use spaces in file names” years old

#324

Post by foxfluff »

ansible wrote: post #287
foxfluff wrote: post #17

I'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…

Well, if you think that's bad, behold the recent trend in network interface names on Linux. We started out with 'eth0', 'eth1', etc. Which adapter was which could change when adding and removing a network card. That was bad, so that prompted the evolution. Now we have 'enp1s0', 'enp0s31f6', 'enp13s0' and many similar variations. These are supposedly more stable across device changes. As it turns out, it wasn't. But w…

I was actually ranting about this on IRC last night (yeah now my laptop has two enp* interfaces and enx[MAC])..

One thing I like about OpenBSD is that buses are scanned and drivers probe in order and there's no race between drivers coming up. Unless your hardware is physically tampered with or broken, all interfaces come up with the same name across reboots. Linux isn't like that (even if you don't touch your hardware, interfaces could swap across reboots), so you need to do something about it.

As is typical on Linux, the default is unergonomic and if you want something nice, you're on your own to make it so.

If you already have userspace daemons responsible for device insertion and naming, it really wouldn't have been so hard for it to e.g. automatically add a config file / database entry for each interface the first time is seen. So the devices that came up as eth0 and eth1 are still eth0 and eth1 on the next boot; if I unplug eth0 and add a new card, the new one would be eth2 because eth0 is still reserved for the first card I had.

Re: I'm “still afraid to use spaces in file names” years old

#325

Post by Jiro »

nomorecommas wrote: post #77
foxfluff wrote: post #17

I'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…

Long option names are more descriptive, more easily distinguished, and easier to remember. Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.

Long option names are more difficult to remember because a long option name can be spelled multiple ways and it is difficult to remember which spelling is correct.

Re: I'm “still afraid to use spaces in file names” years old

#326

Post by sysadm1n »

pimterry wrote: post #106

I 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

Re: I'm “still afraid to use spaces in file names” years old

#328

Post by davidjgraph »

You think space are bad (and yes I'm old enough that I don't use them)... We work with a company that has forward slashes "/" in their trading name and insist on shared cloud directories involving them to be prefixed with that trading name.

As you as you do anything programmatic in/out of these drives it all hits the fan. So I'd add to the original statement - "Avoid 'technical' companies with special characters in their name", it's just not right...

Re: I'm “still afraid to use spaces in file names” years old

#329

Post by mikewarot »

File names shouldn't have anything except a-z,0-9,_ and perhaps a -. No unicode, no spaces, no nulls.

It's not fear that keeps me from using spaces in file names, it's habit.

If we're going to play this dangerous game, from now on I'll figure out how to use nulls (\0) in my file names, and make all the C/C++ programmers cry.

Re: I'm “still afraid to use spaces in file names” years old

#330

Post by blackboxlogic »

inanutshellus wrote: post #283
blackboxlogic wrote: post #174

Earlier quoted context omitted.

How do you distinguish 21K111 and 21K111?

Are you trying to catch GP on differentiating hours, were it to be appended to his time format (1st @ 11 vs 11th @ 1am)? Notably he didn't promise any, but presumably one'd need a separator... Maybe, per his "K" usage of the month, one'd use the alphabet again. 11am would be "K" again... or lowercase just for giggles? I don't think it reads very well, but I also think one'd get used to it pretty quickly.

I was thinking January 11th vs November 1st. Maybe their "date" doesn't need/support day-of-month? Or they typod and I should just focus on my work.
Post reply on HN