It’s also really good practice to account for weird characters in programs and shell scripts you write because then you don’t have injection vulnerabilities or unicode problems.
Seriously, what’s an example of spaces in filenames causing a problem?
Will error for example. It works fine for filenames without space, but if the filename has space in it, it will be interpreted wrong. But if your testing batch doesn’t have spaces in the filename, you won’t see the issue until it’s used on a file that does.
Note ‘cat’ is a placeholder, any function/script that can be used on a file here will have the same issue.
Something similar to that caught me last week while I was unzipping multiple mods in bulk for a game.
The point I guess I was getting at was that even having “come up” with Slackware and a whole os that’s just 69 half baked scripts in a trenchcoat I adopted a more universal mindset and specific skill set when using scripts over ten years ago and find it hard to justify expecting sanitary inputs nowadays when it is harder and harder with Unicode and is a serious security threat to treat variables as passable strings.
I wasn’t trying to suggest that there isn’t a way to make a space in a filename cause an error, but that I can’t think of an example where allowing a space to affect things was a good or right way to do something.
In the specific example of the op, no spaces is a scene rule from the days of ftp and irc/usenet. The idea behind having only a subset of the ascii character set was to allow those services to work with the files and commands around them. There’s no reason to treat my own scripts and programs as if they’ll never encounter the galaxy of other characters that are flying around now and to be honest, theres no reason not to work in sane handling of non ascii characters in filenames even for code I only expect to touch scene stuff.
It used to be an unavoidable mistake when we dug up buried utilities. Now that there’s a number to call first it’s only the fault of the knucklehead with the shovel.
Please don’t read this as some kind of an argument. I think we basically agree and I’m not trying to get one over on you.
To be fair, I didn’t really focus on the biggest annoyance I’ve had with spaces in the file name: going between terminals and the GUI, most filenames you can copy and paste with wild abandon, but filenames with spaces always require special care, sometimes stripping the auto completed escaped space from file names from the terminal, or quoting or escaping the space when taking one from the GUI.
That can be a struggle. There used to be a context menu option in maybe xterm or the kde terminal emulator that would copy the wd and maybe even the highlighted file but I might be gpt hallucinating that last one.
After fucking up bad copying from the internet into a terminal about fifteen years ago I have tried to review and understand what’s happening when copying from or to the terminal even in part. It would be bad for me if there weren’t the possibility of (at best) having shit not work when I use middle click with abandon.
I been thinking a lot about designing technology to discourage people from using it. For example it’s a serious mistake when wearable displays are made to look like wayfarers. The danger of people accepting them socially to the point of being manipulated into a state of flow, dissociating from their reality through a combination of sight and sound augmented reality, is too high. Good design of wearable displays should prioritize function over form 100% and make the user look like an insane freak that no one wants to be around, forcing people to remove them in order to maintain social interactions.
I think copying to and from the terminal is like that. When going between an interface which is a very high level mediator of interaction with the machine and one that’s a very low level mediator, we should be alert, on guard and proofreading everything twice. It’s good that we have to check ourselves before we wreck ourselves copying and pasting into the terminal.
Escape characters and autocomplete exist.
It’s also really good practice to account for weird characters in programs and shell scripts you write because then you don’t have injection vulnerabilities or unicode problems.
Seriously, what’s an example of spaces in filenames causing a problem?
for f in *.txt; do cat $f; doneWill error for example. It works fine for filenames without space, but if the filename has space in it, it will be interpreted wrong. But if your testing batch doesn’t have spaces in the filename, you won’t see the issue until it’s used on a file that does. Note ‘cat’ is a placeholder, any function/script that can be used on a file here will have the same issue.
Something similar to that caught me last week while I was unzipping multiple mods in bulk for a game.
I’m not at a bash terminal, but I think “$f” fixes that. I’ll look tonight.
You are correct, that is how I worked around the issue and why I mentioned that work around in my original post
I didn’t notice that part of your post. 🙏
The point I guess I was getting at was that even having “come up” with Slackware and a whole os that’s just 69 half baked scripts in a trenchcoat I adopted a more universal mindset and specific skill set when using scripts over ten years ago and find it hard to justify expecting sanitary inputs nowadays when it is harder and harder with Unicode and is a serious security threat to treat variables as passable strings.
I wasn’t trying to suggest that there isn’t a way to make a space in a filename cause an error, but that I can’t think of an example where allowing a space to affect things was a good or right way to do something.
In the specific example of the op, no spaces is a scene rule from the days of ftp and irc/usenet. The idea behind having only a subset of the ascii character set was to allow those services to work with the files and commands around them. There’s no reason to treat my own scripts and programs as if they’ll never encounter the galaxy of other characters that are flying around now and to be honest, theres no reason not to work in sane handling of non ascii characters in filenames even for code I only expect to touch scene stuff.
It used to be an unavoidable mistake when we dug up buried utilities. Now that there’s a number to call first it’s only the fault of the knucklehead with the shovel.
Please don’t read this as some kind of an argument. I think we basically agree and I’m not trying to get one over on you.
To be fair, I didn’t really focus on the biggest annoyance I’ve had with spaces in the file name: going between terminals and the GUI, most filenames you can copy and paste with wild abandon, but filenames with spaces always require special care, sometimes stripping the auto completed escaped space from file names from the terminal, or quoting or escaping the space when taking one from the GUI.
That can be a struggle. There used to be a context menu option in maybe xterm or the kde terminal emulator that would copy the wd and maybe even the highlighted file but I might be gpt hallucinating that last one.
After fucking up bad copying from the internet into a terminal about fifteen years ago I have tried to review and understand what’s happening when copying from or to the terminal even in part. It would be bad for me if there weren’t the possibility of (at best) having shit not work when I use middle click with abandon.
I been thinking a lot about designing technology to discourage people from using it. For example it’s a serious mistake when wearable displays are made to look like wayfarers. The danger of people accepting them socially to the point of being manipulated into a state of flow, dissociating from their reality through a combination of sight and sound augmented reality, is too high. Good design of wearable displays should prioritize function over form 100% and make the user look like an insane freak that no one wants to be around, forcing people to remove them in order to maintain social interactions.
I think copying to and from the terminal is like that. When going between an interface which is a very high level mediator of interaction with the machine and one that’s a very low level mediator, we should be alert, on guard and proofreading everything twice. It’s good that we have to check ourselves before we wreck ourselves copying and pasting into the terminal.