While trying to provide a tool built with sub as a gem, I learned that symlinks aren't maintained while building gems. This meant that bin/sub would be flattened into a copy of libexec/sub rather than remaining a symlink. This was problematic because the bin file within a gem must be a ruby script.
This change execs libexec/sub instead of symlinking, which removes a roadblock when gemifying sub projects.
Exec libexec/sub from bin/sub instead of symlinking.
Symlinks aren't maintained while building gems, so bin/sub would be
flattened into a copy of libexec/sub rather than remaining a symlink.
This change execs libexec/sub instead of symlinking, which make it easier
to gemify sub projects.
I got bitten by this today after copying the file directory via scp. I hadn't ran into the problem with rsync or tar, so I wasn't expecting a problem with scp, but the version of scp I have didn't support symlinks, resulting an "command not found" error on the other end, because the top level command was found, but none of the sub-commands were found.
Short of avoiding symlinks, it would nice if this issue was detected-- the main script should be able to detect the right symlink is in place and throw a more helpful message if the symlink is expected but has been flattened.