13 ms·

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for us

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on using make with files with spaces in their names is simply "don't even try." In the 21st century, this is not an acceptable answer.

hzhou321 9y ago
Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as reasons for inflating complexities. Without rein on complexity (whether it is hidden or not), the future is doomed, whatever you are building. While I am not saying we should avoid complexity at all cost, I am insisting that all complexity should be balanced with merits. The merits of filenames with spaces is they read better in a GUI explorer. Whether that merit balances out all the complexity it brings is individual dependent. For me, that merit ranks very low and I avoid spaces in my filenames at all opportunities. For some, they need those filenames to be readable. And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Another solution would be to add an additional pre-step of copying/renaming/linking/aliasing. With the latter solution, the complexity is confined. I guess for some, it only matters with "I do work" or "they do work" rather than the big picture. That is fine. However given the context of you are working with Makefiles, then you are a developer at some level, you are supposed to do some work.
- andrew_wc_brown 9y ago
  get out of here spaces.
- debaserab2 9y ago
  What does the merit of spaces in file names matter? You still will need to deal with files with spaces in the real world. If your tooling doesn't support it, it's a non-starter for many.
  - hzhou321 9y ago
    What about real world is that in real world, it is not context-free. There are real world situations -- such as selling a word processor to general public (especially) including clueless -- you need to deal with files with spaces, period. But there are real world situations -- such as Makefiles -- requires users to learn the tool, to be able to handle certain tricky situations themselves and excludes incompetents. And then there are real world situations that the application only concerns within a company, or within an office, or within one-self. What about real world is, it is complicated.
    - to3m 9y ago
      I'm bemused by this repeated insistence that supporting spaces in file names is somehow difficult.
      - JustSomeNobody 9y ago
        The word was complicated, not difficult. It is not difficult to handle spaces, it is more complicated.
        to3m 9y ago
        That's a worthwhile clarification - thank you. While that's certainly true in the strict sense, I remain bemused.
      - scbrg 9y ago
        I'm bemused by this repeated insistence that supporting colon in file names is somehow difficult.
- zer00eyz 9y ago
  > At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. I don't understand why one would think that make would be a good tool for this... > Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? Yes this is a limitation of make, but not a million other tools out there. Make is not a panacea, no tool is - pressing a tool into a job it is un-suited for because you understand it is "Not good" (trade mark and copy right pending). This is the classic case of having a hammer and a screw -
  - scbrg 9y ago
    > I don't understand why one would think that make would be a good tool for this... Why not? To me, it sounds like a perfect use of Make. You have a number of files that should be processed somehow (presumably by invoking a certain tool for each and every file) and produce another set of files. Whether it's C-files to compiled binaries, or some source files to PDF:s, make seems very well suited for the job. Except yeah, perhaps, spaces.
    - CogitoCogito 9y ago
      Yeah make seems like a great first tool to grab in this case. But apparently some of the requirements of this current usecase don't play well with make. Too bad, but it doesn't mean make is somehow a bad tool...it just doesn't fit all problems. Given that make isn't working well in this case due to spaces, I would personally probably use something like find and sed in a bash script to just get all the files and convert them to pdf. (Obviously this won't work if your system doesn't have these tools though...)
- deleted 9y ago
  [deleted]
- Kenji 9y ago
  I hate hearing people using 21st century or modern as reasons for inflating complexities. No. He's right, you're wrong, hzhou321. We want spaces in filenames. We even want UTF-8 if possible. We don't want crude tools that cannot handle the most basic names. You can argue all you want, this is a very very basic demand that could be met with very very basic tools but make is just too crude. People like you are exactly the cancer in the developer community that argues away reasonable demands like spaces in filenames and perpetuates the garbage legacy tools we have.
- com2kid 9y ago
  > And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one more way that computers are scary and unpredictable. Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.
  - hzhou321 9y ago
    > Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years. That is an excellent example that deserves a second look from a different aspect. ... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.
    - coldtea 9y ago
      Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs). And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.
      - Chlorus 9y ago
        Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
- reificator 9y ago
  Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human beings have been using spaces to delimit words since long before computers existed.
  - gdwatson 9y ago
    On the command line, using spaces to delimit words is also quite natural; that's why they get used as a delimiter: mv old-file new-file Spaces separate the verb, the direct object, and the indirect object. Using commas or colons instead would painfully artificial. So the question is whether you will favor naturalness on the command line or in the GUI. It's no surprise that a Unix build tool favors the command line.
    - reificator 9y ago
      True, but on the command line I don't have to worry about the spaces. I'm just going to tab-complete to simultaneously ensure I'm in the context I expect to be in, ensure I'm not making any typos, and save some time to boot.
    - jtolmar 9y ago
      What if your file system didn't distinguish between underscores and spaces, your GUI displayed them as spaces, and your command line displayed underscores? Then this problem goes away entirely and you instead have the problem of not being allowed to have "this_file" and "this file" in the same directory. A problem which probably doesn't matter.
      - lucideer 9y ago
        That hides the problem from the user, and will consequently lead to command line users typing spaces where they should be typing underscores.
- oblio 9y ago
  You solution is a “boil the oceans” one typically proposed by engineers. You can re-program computers. You can’t re-program millions of people. Every natural language uses spaces to separate things. You can accept that or you can keep tilting at windmills. In every branch of science, reality wins. If your model can’t accomodate reality it’s either completely wrong or it needs adjustments, at least.
  - scbrg 9y ago
    > Every natural language uses spaces to separate things. Exactly. To separate things. Which, incidentally, happens to also be precisely what make, and the traditional UNIX shells do :-) The problem isn't that space in itself is a particularly difficult character. The problem is that its meaning is overloaded and ambiguous. No matter what you do, computers will have difficulty with ambiguity. You'll always have the problem that the separator is special, but hey, I'd be all for using 0x1C instead ;)
    - ljm 9y ago
      How exactly is this different to, say, maths, where there is an assumed precedence and when you need to either make that clear or change the order you use parentheses to encapsulate the inner calculation? What it sounds like is that the Unix shell syntax was established how it was, everyone built on it with all of its syntactical conveniences, and suddenly there's 100% buy-in to the idea that a computer just can't handle a filename with spaces in a shell. ./cmd do-something-with --force file with spaces ./cmd do-something-with --force 'file with spaces' That's one of the main problems solved. If you're expecting to run an executable with spaces in it, like this: ./do something with cmd --force 'file with spaces' Then it's another problem but one that can be solved by convention. A GUI can happily execute `./do\ something\ else` but if you're in the shell you've got completions, aliases, functions, symbolic links... And if that's not ideal, then `./'do something with' cmd …` should be good enough right?
  - gonvaled 9y ago
    You can prevent your tools from having to deal with the fact, by preprocessing.
- flavio81 9y ago
  >Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works Wow. So human beings should stop using allowed file names because it's too hard for you?
- pcwalton 9y ago
  The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.
  - v_lisivka 9y ago
    Unix tools have no trouble with space in file names. "-", "\0", "\n" and bad Unicode are troublesome. Lazy programmers can forget to put quotes around variables in shell scripts, but it's not a problem of the tool.
    - eigengrau 9y ago
      Additionally, not every shell expands variables the way Bourne-based shells do.
  - eigengrau 9y ago
    I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell, as opposed to the program being invoked?
    - mnarayan01 9y ago
      There's this program called make...
      - eigengrau 9y ago
        My question was aimed at ops generic statement. As for Make, it originally wasn’t clear to me where the issue was supposed to lie. Lines in rule bodies are handed off to the shell, and that whitespace in rule dependencies need escaping didn’t seem surprising since it’s a list (though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon). But I see now that the expansion of list-valued automatic variables is probably a real Make-endemic issue.
- tomc1985 9y ago
  Nothing an intake script and a little gsub() can't handle
- intrasight 9y ago
  I am old-school and hate spaces. They do occasionally show up on my computer. But never in anything I'd be touching with a Makefile.
- Daycrawler 9y ago
  You're talking about implementation complexity. The only argument you can throw at the user is feature complexity. Handling spaces in filename isn't a complex feature at all, and users don't care that the simplistic implementation you're using makes it a problem.
- rcxdude 9y ago
  Not handling spaces is a symptom of a much deeper problem in common with a lot of 'unix' utilities: not actually structuring data apart from in ad-hoc string encodings. The fact that data can be so easy conflated with program structure is the cause of so many obscure bugs and overhead in using utilities that suffer from it it's a wonder anyone is defending this approach going forward.
- lcedp 9y ago
  > The merits of filenames with spaces is they read better in a GUI explorer. Even this merit is debatable. Is foo bar two things or one? I know foo-bar is one.
  - sduclos 9y ago
    yeah and then is 田中 one or two things? It all depend on the domain. To me 'é' and 'ê' mean different thing that are both outside the make domain. In French you also have half white space (diacritic that latex can handle) for terminal '?!..' Those are simply outside make domain .. so bothering about space encoding as: ' ', '+', "%20" or '_' seem futile. It all depend of domain convention. Make align on variable naming convention .. that is all
- wodenokoto 9y ago
  I've been working with strings with spaced since before the 21st century. I've also worked with strings with special characters. I've even worked with variables with spaces and special characters. I don't see why filenames are so much more special, except a lot of old tools never got updated to world beyond ASCII
xamuel 9y ago
Solution: create the pdfs with spaces replaced by underscores. Then as the very last command in the relevant makefile section, insert a bash command to replace those underscores with spaces.
- Zofren 9y ago
  What if the filename is a mixture of underscores and spaces?
  - scbrg 9y ago
    Escaping an escape character is not a new problem in programming. There are solutions :-)
  - xamuel 9y ago
    "Premature generalization is the root of all evil."
spc476 9y ago
I was able to to it. Here's the source code "hello world.c": #include <stdio.h> int main(void) { puts("Hello, world!"); return 0; } And here's the minimal Makefile to generate the output: hello world: Of course, I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) to get this to work, but hey, spaces!
- abhishekjha 9y ago
  >I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) How? EDIT: Ok, now I got it. Boy that was a wild ride.
  - coldsauce 9y ago
    Could you explain how you did it?
    - abhishekjha 9y ago
      Replacing breaking space with non-breaking space : 1. Set up your compose key on linux(Top right corner settings->system settings->keyboards->shortcut->typing->Compose key(choose an appropriate one)). 2. Whenever you need to type breaking space instead type (compose key + spacebar + spacebar). This puts a non-breaking space there instead. That's it. 3. Create file -> sudo nano hello(compose key + spacebar + spacebar)world.c 4. Paste the code to execute. 5. Makefile-> hello(compose key + space + space)world: 6. make 7. ./hello world (pressing tab will recognise the executable automatically). NOTE: Don't do this ever in any production code or just ever. This hack can take up hours to resolve and a lot of frustration which could have better been spent on fixing something meaningful. This is a frowned upon practice. The only cool part is that your directory can have two files with whose name look exactly the same.
  - spc476 9y ago
    I did not do the method below. Instead, I wrote a script to generate the filename with the non-breaking space where I needed it. Edit: rewording and typos.
tomn 9y ago
I deal with this shape of problem quite a bit. After using scons and make in the past I recently tried using ninja, and it really works well. Specifically, a python configure script using the ninja_syntax.py module. This seems like it's a bit more complicated, but has a lot of nice attributes. File names with spaces should just work (unlike make). The amount of hidden complexity is very low (unlike make or SCons); all the complexity lives in your configure script. It's driven by a real, non-arcane language (unlike make). Targets are automatically rebuilt when their rules/dependencies change (unlike make). It's more difficult to install than make, but only marginally.
jmts 9y ago
Perhaps you just chose the wrong tool for the job. Just because you are able to do similar things with make, doesn't mean it is has to be suited to your chosen use case. It's a tool that was created with a specific purpose in mind, with specific constraints, and it works fine for thousands (I assume) of people every day. You can't blame it for not being a general-purpose programming language. Make isn't beyond building other tools that you can write yourself - and use in the very same makefiles - to assist in handling cases like this, however.
gkya 9y ago
Spaces in filenames create troubles with almost every command line tool. cut(1), awk(1), find(1), xargs(1), what not. How do you quote them, do you need to use \0 as a separator instead, do other commands on the pipeline support \0 separators? What happens after a couple expansions, passing stuff from one script to another? And what the heck happened on 31 dec 1999 that the world became a different place where suddenly people realised: there were these space things, quite useful they were, why don't we tuck them into every file name and URL and who knows what? People have better things to do than dealing with these things.
- josteink 9y ago
  > Spaces in filenames create troubles with almost every command line tool Then that's a shortcoming which should be addressed with the tools, because humans everywhere use spaces in filenames. For every command-line tool I make (Windows & Linux), I ensure it handles such trivial use-cases. I can't see why such a simple task is seemingly impossible to get done in GNU coreutils.
  - gkya 9y ago
    Very good of you indeed, but it's a hard task to retroactively change how a system and the greater community around it behaves and how standards like POSIX have defined field separation syntax for decades. I wouldn't mind if make supported spaces in filenames, but the thing is it's a bit late now and the problem is too unimportant to bother solving, frankly.
CookieMon 9y ago
Is there any clone of make that's aiming to address the issues with file name spaces? Being incapable of handling spaces is a bug that's been marked Minor since 2002 - https://savannah.gnu.org/bugs/?712 https://savannah.gnu.org/bugs/?712 (plus I find double quotation marks easier to read and write than escaping every space in a path) Edit: https://stackoverflow.com/questions/66800/promising-alternatives-to-make https://stackoverflow.com/questions/66800/promising-alternat... (they aren't really clones tho)

hzhou321 9y ago

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches. I hate hearing people using 21st century or modern as reasons for inflating complexities. Without rein on complexity (whether it is hidden or not), the future is doomed, whatever you are building. While I am not saying we should avoid complexity at all cost, I am insisting that all complexity should be balanced with merits. The merits of filenames with spaces is they read better in a GUI explorer. Whether that merit balances out all the complexity it brings is individual dependent. For me, that merit ranks very low and I avoid spaces in my filenames at all opportunities. For some, they need those filenames to be readable. And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Another solution would be to add an additional pre-step of copying/renaming/linking/aliasing. With the latter solution, the complexity is confined. I guess for some, it only matters with "I do work" or "they do work" rather than the big picture. That is fine. However given the context of you are working with Makefiles, then you are a developer at some level, you are supposed to do some work.

andrew_wc_brown 9y ago
get out of here spaces.
debaserab2 9y ago
What does the merit of spaces in file names matter? You still will need to deal with files with spaces in the real world. If your tooling doesn't support it, it's a non-starter for many.
- hzhou321 9y ago
  What about real world is that in real world, it is not context-free. There are real world situations -- such as selling a word processor to general public (especially) including clueless -- you need to deal with files with spaces, period. But there are real world situations -- such as Makefiles -- requires users to learn the tool, to be able to handle certain tricky situations themselves and excludes incompetents. And then there are real world situations that the application only concerns within a company, or within an office, or within one-self. What about real world is, it is complicated.
  - to3m 9y ago
    I'm bemused by this repeated insistence that supporting spaces in file names is somehow difficult.
    - JustSomeNobody 9y ago
      The word was complicated, not difficult. It is not difficult to handle spaces, it is more complicated.
      - to3m 9y ago
        That's a worthwhile clarification - thank you. While that's certainly true in the strict sense, I remain bemused.
    - scbrg 9y ago
      I'm bemused by this repeated insistence that supporting colon in file names is somehow difficult.
zer00eyz 9y ago
> At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. I don't understand why one would think that make would be a good tool for this... > Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? Yes this is a limitation of make, but not a million other tools out there. Make is not a panacea, no tool is - pressing a tool into a job it is un-suited for because you understand it is "Not good" (trade mark and copy right pending). This is the classic case of having a hammer and a screw -
- scbrg 9y ago
  > I don't understand why one would think that make would be a good tool for this... Why not? To me, it sounds like a perfect use of Make. You have a number of files that should be processed somehow (presumably by invoking a certain tool for each and every file) and produce another set of files. Whether it's C-files to compiled binaries, or some source files to PDF:s, make seems very well suited for the job. Except yeah, perhaps, spaces.
  - CogitoCogito 9y ago
    Yeah make seems like a great first tool to grab in this case. But apparently some of the requirements of this current usecase don't play well with make. Too bad, but it doesn't mean make is somehow a bad tool...it just doesn't fit all problems. Given that make isn't working well in this case due to spaces, I would personally probably use something like find and sed in a bash script to just get all the files and convert them to pdf. (Obviously this won't work if your system doesn't have these tools though...)
deleted 9y ago
[deleted]
Kenji 9y ago
I hate hearing people using 21st century or modern as reasons for inflating complexities. No. He's right, you're wrong, hzhou321. We want spaces in filenames. We even want UTF-8 if possible. We don't want crude tools that cannot handle the most basic names. You can argue all you want, this is a very very basic demand that could be met with very very basic tools but make is just too crude. People like you are exactly the cancer in the developer community that argues away reasonable demands like spaces in filenames and perpetuates the garbage legacy tools we have.
com2kid 9y ago
> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one more way that computers are scary and unpredictable. Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.
- hzhou321 9y ago
  > Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years. That is an excellent example that deserves a second look from a different aspect. ... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.
  - coldtea 9y ago
    Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs). And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.
    - Chlorus 9y ago
      Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
reificator 9y ago
Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake. But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings. And human beings have been using spaces to delimit words since long before computers existed.
- gdwatson 9y ago
  On the command line, using spaces to delimit words is also quite natural; that's why they get used as a delimiter: mv old-file new-file Spaces separate the verb, the direct object, and the indirect object. Using commas or colons instead would painfully artificial. So the question is whether you will favor naturalness on the command line or in the GUI. It's no surprise that a Unix build tool favors the command line.
  - reificator 9y ago
    True, but on the command line I don't have to worry about the spaces. I'm just going to tab-complete to simultaneously ensure I'm in the context I expect to be in, ensure I'm not making any typos, and save some time to boot.
  - jtolmar 9y ago
    What if your file system didn't distinguish between underscores and spaces, your GUI displayed them as spaces, and your command line displayed underscores? Then this problem goes away entirely and you instead have the problem of not being allowed to have "this_file" and "this file" in the same directory. A problem which probably doesn't matter.
    - lucideer 9y ago
      That hides the problem from the user, and will consequently lead to command line users typing spaces where they should be typing underscores.
oblio 9y ago
You solution is a “boil the oceans” one typically proposed by engineers. You can re-program computers. You can’t re-program millions of people. Every natural language uses spaces to separate things. You can accept that or you can keep tilting at windmills. In every branch of science, reality wins. If your model can’t accomodate reality it’s either completely wrong or it needs adjustments, at least.
- scbrg 9y ago
  > Every natural language uses spaces to separate things. Exactly. To separate things. Which, incidentally, happens to also be precisely what make, and the traditional UNIX shells do :-) The problem isn't that space in itself is a particularly difficult character. The problem is that its meaning is overloaded and ambiguous. No matter what you do, computers will have difficulty with ambiguity. You'll always have the problem that the separator is special, but hey, I'd be all for using 0x1C instead ;)
  - ljm 9y ago
    How exactly is this different to, say, maths, where there is an assumed precedence and when you need to either make that clear or change the order you use parentheses to encapsulate the inner calculation? What it sounds like is that the Unix shell syntax was established how it was, everyone built on it with all of its syntactical conveniences, and suddenly there's 100% buy-in to the idea that a computer just can't handle a filename with spaces in a shell. ./cmd do-something-with --force file with spaces ./cmd do-something-with --force 'file with spaces' That's one of the main problems solved. If you're expecting to run an executable with spaces in it, like this: ./do something with cmd --force 'file with spaces' Then it's another problem but one that can be solved by convention. A GUI can happily execute `./do\ something\ else` but if you're in the shell you've got completions, aliases, functions, symbolic links... And if that's not ideal, then `./'do something with' cmd …` should be good enough right?
- gonvaled 9y ago
  You can prevent your tools from having to deal with the fact, by preprocessing.
flavio81 9y ago
>Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works Wow. So human beings should stop using allowed file names because it's too hard for you?
pcwalton 9y ago
The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.
- v_lisivka 9y ago
  Unix tools have no trouble with space in file names. "-", "\0", "\n" and bad Unicode are troublesome. Lazy programmers can forget to put quotes around variables in shell scripts, but it's not a problem of the tool.
  - eigengrau 9y ago
    Additionally, not every shell expands variables the way Bourne-based shells do.
- eigengrau 9y ago
  I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell, as opposed to the program being invoked?
  - mnarayan01 9y ago
    There's this program called make...
    - eigengrau 9y ago
      My question was aimed at ops generic statement. As for Make, it originally wasn’t clear to me where the issue was supposed to lie. Lines in rule bodies are handed off to the shell, and that whitespace in rule dependencies need escaping didn’t seem surprising since it’s a list (though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon). But I see now that the expansion of list-valued automatic variables is probably a real Make-endemic issue.
tomc1985 9y ago
Nothing an intake script and a little gsub() can't handle
intrasight 9y ago
I am old-school and hate spaces. They do occasionally show up on my computer. But never in anything I'd be touching with a Makefile.
Daycrawler 9y ago
You're talking about implementation complexity. The only argument you can throw at the user is feature complexity. Handling spaces in filename isn't a complex feature at all, and users don't care that the simplistic implementation you're using makes it a problem.
rcxdude 9y ago
Not handling spaces is a symptom of a much deeper problem in common with a lot of 'unix' utilities: not actually structuring data apart from in ad-hoc string encodings. The fact that data can be so easy conflated with program structure is the cause of so many obscure bugs and overhead in using utilities that suffer from it it's a wonder anyone is defending this approach going forward.
lcedp 9y ago
> The merits of filenames with spaces is they read better in a GUI explorer. Even this merit is debatable. Is foo bar two things or one? I know foo-bar is one.
- sduclos 9y ago
  yeah and then is 田中 one or two things? It all depend on the domain. To me 'é' and 'ê' mean different thing that are both outside the make domain. In French you also have half white space (diacritic that latex can handle) for terminal '?!..' Those are simply outside make domain .. so bothering about space encoding as: ' ', '+', "%20" or '_' seem futile. It all depend of domain convention. Make align on variable naming convention .. that is all
wodenokoto 9y ago
I've been working with strings with spaced since before the 21st century. I've also worked with strings with special characters. I've even worked with variables with spaces and special characters. I don't see why filenames are so much more special, except a lot of old tools never got updated to world beyond ASCII

xamuel 9y ago

Solution: create the pdfs with spaces replaced by underscores. Then as the very last command in the relevant makefile section, insert a bash command to replace those underscores with spaces.

Zofren 9y ago
What if the filename is a mixture of underscores and spaces?
- scbrg 9y ago
  Escaping an escape character is not a new problem in programming. There are solutions :-)
- xamuel 9y ago
  "Premature generalization is the root of all evil."

spc476 9y ago

I was able to to it. Here's the source code "hello world.c": #include <stdio.h> int main(void) { puts("Hello, world!"); return 0; } And here's the minimal Makefile to generate the output: hello world: Of course, I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) to get this to work, but hey, spaces!

abhishekjha 9y ago
>I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) How? EDIT: Ok, now I got it. Boy that was a wild ride.
- coldsauce 9y ago
  Could you explain how you did it?
  - abhishekjha 9y ago
    Replacing breaking space with non-breaking space : 1. Set up your compose key on linux(Top right corner settings->system settings->keyboards->shortcut->typing->Compose key(choose an appropriate one)). 2. Whenever you need to type breaking space instead type (compose key + spacebar + spacebar). This puts a non-breaking space there instead. That's it. 3. Create file -> sudo nano hello(compose key + spacebar + spacebar)world.c 4. Paste the code to execute. 5. Makefile-> hello(compose key + space + space)world: 6. make 7. ./hello world (pressing tab will recognise the executable automatically). NOTE: Don't do this ever in any production code or just ever. This hack can take up hours to resolve and a lot of frustration which could have better been spent on fixing something meaningful. This is a frowned upon practice. The only cool part is that your directory can have two files with whose name look exactly the same.
- spc476 9y ago
  I did not do the method below. Instead, I wrote a script to generate the filename with the non-breaking space where I needed it. Edit: rewording and typos.

tomn 9y ago

I deal with this shape of problem quite a bit. After using scons and make in the past I recently tried using ninja, and it really works well. Specifically, a python configure script using the ninja_syntax.py module. This seems like it's a bit more complicated, but has a lot of nice attributes. File names with spaces should just work (unlike make). The amount of hidden complexity is very low (unlike make or SCons); all the complexity lives in your configure script. It's driven by a real, non-arcane language (unlike make). Targets are automatically rebuilt when their rules/dependencies change (unlike make). It's more difficult to install than make, but only marginally.

jmts 9y ago

Perhaps you just chose the wrong tool for the job. Just because you are able to do similar things with make, doesn't mean it is has to be suited to your chosen use case. It's a tool that was created with a specific purpose in mind, with specific constraints, and it works fine for thousands (I assume) of people every day. You can't blame it for not being a general-purpose programming language. Make isn't beyond building other tools that you can write yourself - and use in the very same makefiles - to assist in handling cases like this, however.

gkya 9y ago

Spaces in filenames create troubles with almost every command line tool. cut(1), awk(1), find(1), xargs(1), what not. How do you quote them, do you need to use \0 as a separator instead, do other commands on the pipeline support \0 separators? What happens after a couple expansions, passing stuff from one script to another? And what the heck happened on 31 dec 1999 that the world became a different place where suddenly people realised: there were these space things, quite useful they were, why don't we tuck them into every file name and URL and who knows what? People have better things to do than dealing with these things.

josteink 9y ago
> Spaces in filenames create troubles with almost every command line tool Then that's a shortcoming which should be addressed with the tools, because humans everywhere use spaces in filenames. For every command-line tool I make (Windows & Linux), I ensure it handles such trivial use-cases. I can't see why such a simple task is seemingly impossible to get done in GNU coreutils.
- gkya 9y ago
  Very good of you indeed, but it's a hard task to retroactively change how a system and the greater community around it behaves and how standards like POSIX have defined field separation syntax for decades. I wouldn't mind if make supported spaces in filenames, but the thing is it's a bit late now and the problem is too unimportant to bother solving, frankly.

CookieMon 9y ago

Is there any clone of make that's aiming to address the issues with file name spaces? Being incapable of handling spaces is a bug that's been marked Minor since 2002 - https://savannah.gnu.org/bugs/?712 https://savannah.gnu.org/bugs/?712 (plus I find double quotation marks easier to read and write than escaping every space in a path) Edit: https://stackoverflow.com/questions/66800/promising-alternatives-to-make https://stackoverflow.com/questions/66800/promising-alternat... (they aren't really clones tho)