This upgrades the versions of everything, including upgrading almost all outdated dependencies.
• number_prefix had some backwards-incompatible changes. It now feels more Rustful, and spells "Mebi" correctly.
• term_grid stopped working when I upgraded it, worryingly, so I reverted it back.
This commit removes the env_logger dependency, replacing it with a simple implementation. Doing so removes like ten other transitive dependencies that no longer need to be included in the build.
It also gains the ability to enable trace-level logging. The users crate, which contains such logging statements as of the version I published a few days ago, has been upgraded to celebrate.
Also, change the log imports to globs. I'm only interested that a file doing logging, not what level it's logging at.
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
It doesn't seem right to use the EXIT_SUCCESS constant in one place, and a hard-coded 2 in another. What if they overlap?
Changing the success value to 0 should be OK, though, because the standard defines 0 as success, regardless of whether EXIT_SUCCESS is 0 or not.
Also, the values have become i32s. The Rust function std::process::exit takes an i32, so there's not much point using anything else.
This was an unintended consequence of #653. The Files iterator stopped using IgnoreCache and started using GitCache, which would always populated when the `--git` option was passed, without checking whether files were meant to be ignored. This meant that passing `--git` started ignoring files even without `--git-ignore`.
The solution for now is to explicitly pass the flag around, which probably should be a better type than bool but isn't. This makes the git-ignoring-related extended tests pass.
Instead of defaulting immediately to /etc/filename for the timezone, we can first check whether the TZ environment variable is set. If so, we can pull the corresponding timezone file from /usr/share/zoneinfo. Closes#453.
Using --octal_permissions will insert another column before the existing
permissions where permissions are encoded using octal values as
requested in #316
Added the following imemdiate file types for PHP:
- `composer.json` for [Composer](https://getcomposer.org/), the defactor standard package manager for PHP;
- `RoboFile.php`, for [Robo](https://robo.li/), the PHP task runner.
Note: [Phing]() uses `build.xml`, which was already included in the list.
Previously if a timestamp was unavailable, it defaulted to the epoch.
Prior to this it defaulted to a zero duration.
Switch to an Option<SystemTime> and move the handling of unavailable
timestamps to rendering.
Fix an off-by-one on the seconds when subseconds are present, and
correct display of nenoseconds, which are of course inverted due to the
internal value being negative.
Instead of returning a Duration since the epoch from file metadata,
which cannot represent times before it, return the SystemTime directly.
Move conversion closer to where it's needed, and perform it infallibly.
pom.xml (Maven) is popularly used for Java projects, along with the
already existing build.xml (Ant) and build.gradle (Gradle) immediate
files.
zwc stands for Zsh Word Code and contains compiled Z Shell scripts or
functions.
