This patch adds a Makefile that will build and install exa along with
its recently added manual page. This provides a little bit of a nicer
installation path while we wait for Cargo to, hopefully, provide its own
built-in installation method for packages that contain binaries.
Signed-off-by: David Celis <me@davidcel.is>
In cases where symlink targets were more than a single directory down,
exa did not print the '/' targets when separating directories, resulting
in the following output:
symlink => dirAdirBdirC/file
Instead of
symlink => dirA/dirB/dirC/file
By adding a '/' character after each component of the filename, this
error is fixed.
This patch adds a manual page that can be parsed and outputted by the
`man` command. The help command is useful, but many UNIX users have a
certain reflex to check for manual pages. It would be awesome to be able
to type `man exa` and see some output! Some notes:
* This manual page was hand crafted. I had hoped to find some Rust
utility that could generate manual pages to prevent having to change
this file whenever changes to options are made. There are tools to
write manual pages in a nicer syntax and then convert them into the
groff syntax, but I hesitated to add more tools to the build process.
This might make the file more difficult to maintain, but unless exa's
signature changes frequently, it should be okay.
* The manual page isn't automatically copied into the
/usr/local/share/man/man1 directory, where it would need to be for
`man` to read it. My first inkling to have installation be a nice
process would be to craft a Makefile that will run `cargo build
--release`, copy the binary into /usr/local/bin, and copy the man
page into the aforementioned directory. I can handle that in this PR
or another one if you like the idea of a Makefile to ease
installation!
Signed-off-by: David Celis <me@davidcel.is>
The old implementation blindly assumed that a symlink target would have a directory compoment, which the current directory, parent directory, and root directory technically don't have.
Fixes#20.
The logic of the previous version wasn't correct. Also, presuming
natural ordering of full filenames is still reasonable when the
extensions are identical.
