I get this on Unix, where the pissweak tooling is a disaster, but as a user, I own the file name. If I can’t use every character I want to, that’s a total fail on the part of the platform.
I agree that you own the filename and should be able to use any characters you want, but there has to be some trade off regarding what filenames you can use in a comfortable manner and which require some form of escaping/quoting.
Another weird character would be the tilde (~). Technically a valid character in a filename, but whenever I see one I begin to fear that I might delete or mess with my home folder.
The tilde is a perfectly fine character to use in a filename, it’s just the shell that does the expansion to your home directory if you give “~ “ (or “ ~ /” at the start of a path). My preferred editor marks the backup file with “~” (at the end of the filename).
Edit: ~ is a “special” Markdown character. No comment on that.
I mean, I don’t use spaces, or tildes, or dollar signs (or colons, for HFS+) in any files that I create or expect to manipulate on the command line, but that doesn’t mean it’s OK. I want the compromises that my computer and I make to live with one another to be largely the province of the computer.
Unlike on other operating systems (well, file systems to be precise), you actually can use any character - even newline or NULL if you so wish. The problem is that you also have to use something as a separator - it so happens that a blank is a natural way to split words apart :^)
So yes, you have to escape or quote blanks and other characters which are extra special ;^)
Or just use spaces and escape them? It’s not hard, and escaping occurs literally everywhere strings are used.
zsh tab completion auto-escapes. GUI programs don’t need to worry about it. I have plenty of filenames with spaces in them, and they don’t cause problems for me.
Non breakable spaces were (are?) often used in HTML to avoid text reflows around punctuation (good typography actually), and too many other hacks to avoid line breaks.
No, and no. Surely you are being aggressive here? I don’t see a case where I would actually believe that someone would want to confuse themselves.
What I do believe is that - hey!- someone who knows how to use a terminal and can even code a bit has spaces in their filenames. Maybe, since they already know how to use a computer, they would realize “Oh, this is definitely an issue I could potentially run into later! I wonder what the best way to solve it is?” and decided that the best way was to write more code to maintain.
Surely that is easier than maybe considering not having spaces in filenames in the extremely rare cases where they may actually matter in a program that makes bad assumptions or a shell if you don’t know how to use intermediately well.
[ Below removed comment follows]
I should also add that the issue exemplified in the article is actually a non-issue. That is, the syntax of how things work is different after the tab character when defining a target:
It just means that someone forgot to quote filenames in the areas of the Makefile which define the target. This is not only a common mistake, but another great reason not to use spaces in filenames!
I guess now that we’ve come full circle and for some reason think having a space is a good idea, we could again say - “well, a null character solves that too!”. The new problem we’ve created is now unidentified AND potentially nebulous, because adding another character to think about is going to cause issues somewhere.
One example issue that I can think of and believe would be very common if something adopted this idea is that the benefit of the words you’ve accidentally introduced a much bigger issue when someone working on your code doesn’t realize that’s a non-breaking space character and rewrites the line to be a space.
What is the value that the space is even adding? Is it considered aesthetically pleasing? I don’t think so, and maybe I’m biased by that, but it’s hard for me to accept that the benefits don’t outweigh the cons here.
Part of that is the unique nature of the space character. In ASCII, it’s grouped next to the information separator characters and thus, could be treated as another type of separator character (and on input, it usually is considered such).
This is sort of true but leads to an incorrect justification. Space is next to information separator characters (properly: “control characters”) but is grouped with the printable characters. It’s next to the control characters to make sorting easier (“a a” ahead of “aa”), not so that it’s a quasi-control character. Look at an old chart and it’s apparent ASCII’s designers were thinking in terms of bit twiddling for ranges, not proximity. Yes, space has long been used as a separator, but it’s definitely not designated as such in ASCII - compare to the tab character (HT in that chart).
This post is a fun workaround for a limitation in make, though.
For me, the space-in-filenames issue is the main thing preventing me from using Make for everything. The limitations on pattern rules make scaling up Makefiles difficult, too.
I’ve long thought that a prolog-like DSL would be perfect; makefiles are basically already logical specifications—I just needed something that worked with spaces and could perform some sort of unification-like process for smarter pattern rules. I nearly started writing my own.
But then I discovered that someone already created such a tool: biomake. I’ve recently started using biomake to automate a large data science research project. It has been absolute bliss! Not only does it those two pain-points with using Make (and countless other pain-points), it features GridEngine integration out-of-the-box, and fantastic debugging information for when things don’t work as expected. I cannot see myself using any other tool.
Not everywhere. The original post mentioned make having a difficult time with spaces, and no amount of quoting or escaping seemed to work with it. Not that I go around making source files with spaces in the name, but that’s one place where your solution doesn’t work.
Technically, yes, it counts as a solution.
Let us never speak of it again.
Personally, I’d rather avoid quirks like this and just use
_or-.How about not using spaces in filenames in the first place?
I get this on Unix, where the pissweak tooling is a disaster, but as a user, I own the file name. If I can’t use every character I want to, that’s a total fail on the part of the platform.
I agree that you own the filename and should be able to use any characters you want, but there has to be some trade off regarding what filenames you can use in a comfortable manner and which require some form of escaping/quoting.
Another weird character would be the tilde (
~). Technically a valid character in a filename, but whenever I see one I begin to fear that I might delete or mess with my home folder.The tilde is a perfectly fine character to use in a filename, it’s just the shell that does the expansion to your home directory if you give “~ “ (or “ ~ /” at the start of a path). My preferred editor marks the backup file with “~” (at the end of the filename).
Edit: ~ is a “special” Markdown character. No comment on that.
I mean, I don’t use spaces, or tildes, or dollar signs (or colons, for HFS+) in any files that I create or expect to manipulate on the command line, but that doesn’t mean it’s OK. I want the compromises that my computer and I make to live with one another to be largely the province of the computer.
You can say that about other characters, too -
*,;,?, etc. not just~.If in doubt, quote or escape :^)
Unlike on other operating systems (well, file systems to be precise), you actually can use any character - even newline or NULL if you so wish. The problem is that you also have to use something as a separator - it so happens that a blank is a natural way to split words apart :^)
So yes, you have to escape or quote blanks and other characters which are extra special ;^)
Obviously not Null :^P - I was thinking of Null as used by
find ... -print0andxargs -0. I should probably get some sleep ;^)Or just use spaces and escape them? It’s not hard, and escaping occurs literally everywhere strings are used.
zshtab completion auto-escapes. GUI programs don’t need to worry about it. I have plenty of filenames with spaces in them, and they don’t cause problems for me.Can you imagine the debugging caused by someone using this hack.
https://github.com/reinderien/mimic
Non breakable spaces were (are?) often used in HTML to avoid text reflows around punctuation (good typography actually), and too many other hacks to avoid line breaks.
Not sure I’d welcome these in a terminal. 🤔
What if they were coloured differently?
Wouldn’t that defeat the purpose?
Yes, if the purpose is to annoy and confuse people.
Do you believe the only reason people have spaces in filenames is to annoy and confuse?
Do you believe it is even a common reason?
No, and no. Surely you are being aggressive here? I don’t see a case where I would actually believe that someone would want to confuse themselves.
What I do believe is that - hey!- someone who knows how to use a terminal and can even code a bit has spaces in their filenames. Maybe, since they already know how to use a computer, they would realize “Oh, this is definitely an issue I could potentially run into later! I wonder what the best way to solve it is?” and decided that the best way was to write more code to maintain.
Surely that is easier than maybe considering not having spaces in filenames in the extremely rare cases where they may actually matter in a program that makes bad assumptions or a shell if you don’t know how to use intermediately well.
[ Below removed comment follows]
I should also add that the issue exemplified in the article is actually a non-issue. That is, the syntax of how things work is different after the tab character when defining a target:
This is a common mistake, but also can be shown in this example - which works: https://gist.github.com/monokrome/24e1c739b93a72ba5ef35b961b945e6c
It just means that someone forgot to quote filenames in the areas of the Makefile which define the target. This is not only a common mistake, but another great reason not to use spaces in filenames!
I guess now that we’ve come full circle and for some reason think having a space is a good idea, we could again say - “well, a null character solves that too!”. The new problem we’ve created is now unidentified AND potentially nebulous, because adding another character to think about is going to cause issues somewhere.
One example issue that I can think of and believe would be very common if something adopted this idea is that the benefit of the words you’ve accidentally introduced a much bigger issue when someone working on your code doesn’t realize that’s a non-breaking space character and rewrites the line to be a space.
What is the value that the space is even adding? Is it considered aesthetically pleasing? I don’t think so, and maybe I’m biased by that, but it’s hard for me to accept that the benefits don’t outweigh the cons here.
This is sort of true but leads to an incorrect justification. Space is next to information separator characters (properly: “control characters”) but is grouped with the printable characters. It’s next to the control characters to make sorting easier (“a a” ahead of “aa”), not so that it’s a quasi-control character. Look at an old chart and it’s apparent ASCII’s designers were thinking in terms of bit twiddling for ranges, not proximity. Yes, space has long been used as a separator, but it’s definitely not designated as such in ASCII - compare to the tab character (HT in that chart).
This post is a fun workaround for a limitation in
make, though.For me, the space-in-filenames issue is the main thing preventing me from using Make for everything. The limitations on pattern rules make scaling up Makefiles difficult, too.
I’ve long thought that a prolog-like DSL would be perfect; makefiles are basically already logical specifications—I just needed something that worked with spaces and could perform some sort of unification-like process for smarter pattern rules. I nearly started writing my own.
But then I discovered that someone already created such a tool: biomake. I’ve recently started using biomake to automate a large data science research project. It has been absolute bliss! Not only does it those two pain-points with using Make (and countless other pain-points), it features GridEngine integration out-of-the-box, and fantastic debugging information for when things don’t work as expected. I cannot see myself using any other tool.
There is very little difficult with spaces in filenames. Learn to quote. Learn to escape. Then everything is very easy.
It seems like you either didn’t read the linked post or didn’t understand it.
The issue there was with
makenot being able to handle spaces in file names - neither quoted nor escaped.In that case:
The title is incorrect.
Still nothing difficult.
make ‘hello world’ g++ “hello world.cpp” -o “hello world”
With a Makefile:
Maybe the OP was making a joke about using UTF8 NBSP and I just didn’t get it.
Quotes and backslashes seem to solve this problem without special characters
Not everywhere. The original post mentioned
makehaving a difficult time with spaces, and no amount of quoting or escaping seemed to work with it. Not that I go around making source files with spaces in the name, but that’s one place where your solution doesn’t work.Maybe the solutions they attempted just didn’t work.
http://savannah.gnu.org/bugs/?712