"~" in file paths isn't expanded to $HOME on POSIX platforms

[kxz]

arc_unpacker --out=~/foo/bar ... creates a directory literally called ~ in the working directory.

Version 0.11, macOS though I'm sure it's not restricted to that.

[rr-]

This is a shell problem; if you're using zsh, you can set magic_equal_subst. In bash, this is on by default.

rr-@tornado:~$ echo $SHELL
/bin/zsh
rr-@tornado:~$ setopt nomagic_equal_subst
rr-@tornado:~$ echo blabla=~/test
blabla=~/test
rr-@tornado:~$ setopt magic_equal_subst 
rr-@tornado:~$ echo blabla=~/test      
blabla=/home/rr-/test

rr-@tornado:~$ echo $SHELL
/bin/bash
rr-@tornado:~$ echo blabla=~/test      
blabla=/home/rr-/test

[kxz]

I think POSIX stipulates that ~ is only expanded at the start of words and after the = for environment variable assignments, so a path that's part of a long option like --out=~/foo/bar (or even -o~/foo/bar) won't be expanded by the shell and has to be handled by the program.

[rr-]

True, but we have workarounds such as the ones I've mentioned.

I'm a bit reluctant to add support for this because if I were to code it, I'd just check for path == "~" or path.startswith("~/"). (boost::path as well as std::experimental::filesystem::path do not support such expansion so it'd need to be dealt with manually like that.) But such checking feels fragile - it doesn't make much sense for at least one platform (Windows), so it'd probably need to be guarded with #ifs.

Do you think this is a reasonable implementation?

[kxz]

Sounds reasonable, yeah. There's wordexp as well, but that'd still require #if-guarding.