Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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).



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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: