Dotfiles with spaces don't work

[waynehoover]

With the latest version do:

cd ~ touch .this\ is\ a\ dotfile\ with\ spaces.rc

then do mkrc .this\ is\ a\ dotfile\ with\ spaces.rc

You get this error:

mv: rename .this to /Users/wayne/.dotfiles/this: No such file or directory
mv: rename is to /Users/wayne/.dotfiles/is: No such file or directory
mv: rename a to /Users/wayne/.dotfiles/a: No such file or directory
mv: rename dotfile to /Users/wayne/.dotfiles/dotfile: No such file or directory
mv: rename with to /Users/wayne/.dotfiles/with: No such file or directory
mv: rename spaces.rc to /Users/wayne/.dotfiles/spaces.rc: No such file or directory

So I suppose https://github.com/thoughtbot/rcm/pull/44 didn't get it all. Is it possible for mkrc to support spaces in dotfiles?

[mike-burns]

Maybe. It's really, really hard to get perfect.

However, I'm surprised you have a dotfile with a space in its name. Which program uses that?

[waynehoover]

Sublime Text 3, Package Control.

I have created a failing test and am looking into it. Basically it looks like the for loop causes the issues, starting around here. https://github.com/thoughtbot/rcm/blob/master/bin/mkrc.in#L85

It could be doable maybe by changing the for loop to a find while read loop instead, as explained here for example: http://askubuntu.com/questions/343727/filenames-with-spaces-breaking-for-loop-find-command

This would also allow for any utf-8 character in the filename, which I think would be useful too.

This actually might point us in a better direction: http://unix.stackexchange.com/questions/9496/looping-through-files-with-spaces-in-the-names

[mike-burns]

Thanks for the research there. I'll try to fix this within these next two weeks, but feel free to hack on the code yourself in the meantime.

[pbrisbin]

I'm very interested in the solution you come up with.

In my experience, handling this 100% correctly is difficult if not impossible in POSIX without restructuring the entire program (specifically options parsing) to pass "$@" and use for x; do everywhere (in any array-supporting shell, you can assign foo=( "$@" ) and use "${foo[@]}" wherever you want, thus keeping your modularity/sanity). I'd imagine quite a bit of trouble due to the way the tools invoke each other and need to pass any odd-character-containing arguments along. I've seen a number of places that rely on a space-separated string representing a list of arguments.

The linked solution is nice but does have its own trade-offs. In certain shells, I think the find | while read approach will put the code inside the loop in a sub-shell which will change behavior in a subtle way (e.g. exit doesn't exit) -- this may or may not cause issues.

[waynehoover]

I don't think its impossible with POSIX, just hard. Here is another good answer that gives some options:

http://stackoverflow.com/a/7039579

They are all using find which I'm not sure how to get working with filename arguments, at least for now.

[ryanseys]

Yeah I just ran into this issue with Sublime Text 3 too. :( Phooey.

[pablox-cl]

Guess it's time for another thought about using C or a more low-level language? Being POSIX compatible is a PITA :/

[bturrubiates]

@ryanseys @waynehoover I experienced this issue with Sublime as well and found a workaround. I can't remember at the moment. I briefly thought about adding functionality for handling spaces but it's difficult to do in this project. IMO using plain sh for POSIX compatibility doesn't get you much and just makes everything more difficult.

If I recall correctly I think my workaround was letting it copy the sublime-settings files (which have spaces in the name, but you can get around it using globbing e.g. *.sublime-settings) to my home folder and manually managing symlinking with pre-up/post-down hooks.

[mike-burns]

We have a terrifying fix in #155. I don't have very concrete worries about it, so if someone here can try this fix and assure me that everything is going to be OK, and that it solves your problem, I'll be thrilled to merge it.

[mike-burns]

This should be fixed by #193.