4 ms·

Wait. Did I read it wrong or didn't an article a few days back say that we can use make with file names consisting of spaces, its just that we shouldn't? Althou

Wait. Did I read it wrong or didn't an article a few days back say that we can use make with file names consisting of spaces, its just that we shouldn't? Although that article talked about using a non-breaking space as a hack.

spc476 9y ago
Make doesn't handle filenames with spaces (ASCII 32) at all! I wrote the article (http://boston.conman.org/2018/02/28.2 http://boston.conman.org/2018/02/28.2) about using the non-breaking space (NBSP, Unicode 160) in filenames, and make (as well as nearly everything else I tried) accepted it just fine. But popular consensus (from here and Lobsters) seemed to be "avoid any type of space at all cost and do not speak of it again!". Pity.
- abhishekjha 9y ago
  Oh yes. I got so pumped up by your article(and partially by losters' comments of never using it again) that I went on my own to replicate the scenario. Only then I was able to understand what you meant by : > It also requires a filesystem that can support Unicode (or in my case, UTF-8) and a command line that also supports Unicode (or again in my case, UTF-8). > And it was also not that easy to create the filename and Makefile with the non-breaking space.. Looks like setting up the compose key on linux did the trick. I posted my own recipe for naming files using non-breaking spaces[0] after someone asked for it. A beginner here so the steps may look a little too primitive but it gets the work done. Thanks for introducing me to a hack. Now I can have a folder with two files whose name look exactly the same(ASCII 32, NBSP). [0]https://news.ycombinator.com/item?id=16494394 https://news.ycombinator.com/item?id=16494394
- dasyatidprime 9y ago
  I think the main point of handling file names with character code 0x20 in them is for situations where you don't get to pick the file names. I have a project in which I'm juggling a large amount of files imported from external sources, which need to be variably processed and used as-is and in either case must have their names preserved. I wanted to use Make to handle the dependency chaining, but munging file names when inducting them means that I have to unmunge them on every output. Suddenly you can't just zip or grep -H a selection of some of the files anymore; you have to do a whole dance of copy-and-unmunge-name, clean-up-the-temporary-directory, and so on and so on and. If I could just assign my own names, I could just as well avoid spaces, if it were purely an aesthetic issue. But it really isn't. You don't often need “something that displays as a space but you still get to decide its representation”, you need “passing through exactly the ASCII space without having to worry about it”, or the interoperability concerns still explode in your face one way or another (if they exist in the first place).
  - lolikoisuru 9y ago
    If I were to write a makefile for something where I can't restrict the filenames beforehand I'd probably just have a target for running `detox` and then at the very end possibly an another target that changes underscores to spaces and creates some dummy file as the real target.
    - dasyatidprime 9y ago
      But how does this address anything like the zip or grep cases I mentioned? File names go everywhere. You will have spurious nonbreaking spaces (or underscores, or whatever else) in outputs from here to /dev/null and back. Yes, it is theoretically possible to work around it, but it's hardly ergonomic for either the writer or the user of the Makefile.
rcxdude 9y ago
It's not generally possible to do with hand-coded makefiles, because you want to use variables. If you are generating your makefiles, like with cmake, then you can deal with spaces (at least, you can build in a path with spaces in it, and deal with input filenames which contain spaces) because all the paths wind up hardcoded in the makefile (this is one contributing reason to why you cannot move a cmake build directory).

spc476 9y ago

Make doesn't handle filenames with spaces (ASCII 32) at all! I wrote the article (http://boston.conman.org/2018/02/28.2 http://boston.conman.org/2018/02/28.2) about using the non-breaking space (NBSP, Unicode 160) in filenames, and make (as well as nearly everything else I tried) accepted it just fine. But popular consensus (from here and Lobsters) seemed to be "avoid any type of space at all cost and do not speak of it again!". Pity.

abhishekjha 9y ago
Oh yes. I got so pumped up by your article(and partially by losters' comments of never using it again) that I went on my own to replicate the scenario. Only then I was able to understand what you meant by : > It also requires a filesystem that can support Unicode (or in my case, UTF-8) and a command line that also supports Unicode (or again in my case, UTF-8). > And it was also not that easy to create the filename and Makefile with the non-breaking space.. Looks like setting up the compose key on linux did the trick. I posted my own recipe for naming files using non-breaking spaces[0] after someone asked for it. A beginner here so the steps may look a little too primitive but it gets the work done. Thanks for introducing me to a hack. Now I can have a folder with two files whose name look exactly the same(ASCII 32, NBSP). [0]https://news.ycombinator.com/item?id=16494394 https://news.ycombinator.com/item?id=16494394
dasyatidprime 9y ago
I think the main point of handling file names with character code 0x20 in them is for situations where you don't get to pick the file names. I have a project in which I'm juggling a large amount of files imported from external sources, which need to be variably processed and used as-is and in either case must have their names preserved. I wanted to use Make to handle the dependency chaining, but munging file names when inducting them means that I have to unmunge them on every output. Suddenly you can't just zip or grep -H a selection of some of the files anymore; you have to do a whole dance of copy-and-unmunge-name, clean-up-the-temporary-directory, and so on and so on and. If I could just assign my own names, I could just as well avoid spaces, if it were purely an aesthetic issue. But it really isn't. You don't often need “something that displays as a space but you still get to decide its representation”, you need “passing through exactly the ASCII space without having to worry about it”, or the interoperability concerns still explode in your face one way or another (if they exist in the first place).
- lolikoisuru 9y ago
  If I were to write a makefile for something where I can't restrict the filenames beforehand I'd probably just have a target for running `detox` and then at the very end possibly an another target that changes underscores to spaces and creates some dummy file as the real target.
  - dasyatidprime 9y ago
    But how does this address anything like the zip or grep cases I mentioned? File names go everywhere. You will have spurious nonbreaking spaces (or underscores, or whatever else) in outputs from here to /dev/null and back. Yes, it is theoretically possible to work around it, but it's hardly ergonomic for either the writer or the user of the Makefile.

rcxdude 9y ago

It's not generally possible to do with hand-coded makefiles, because you want to use variables. If you are generating your makefiles, like with cmake, then you can deal with spaces (at least, you can build in a path with spaces in it, and deal with input filenames which contain spaces) because all the paths wind up hardcoded in the makefile (this is one contributing reason to why you cannot move a cmake build directory).