There was a problem when displaying . and .. in directory listings: their names would normalise to actual names! So instead of literally seeing `.`, you’d see the current directory’s name, inserted in sort order into the list of results. Obviously this is not what we want.
In unrelated news, putting `.` and `..` into the list of paths read from a directory just takes up more heap space for something that’s basically constant.
We can solve both these problems at once by moving the DotFilter to the files iterator in Dir, rather than at the Dir’s creation. Having the iterator know whether it should display `.` and `..` means it can emit those files first, and because it knows what those files really represent, it can override their file names to actually be those sequences of dots.
This is not a perfect solution: the main casualty is that a File can now be constructed with a name, some metadata, both, or neither. This is currently handled with a bunch of Options, and returns IOResult even without doing any IO operations.
But at least all the tests pass!
exa assumed that the COLUMNS environment variable being present always meant that the output was to a terminal, so it should use colours. But because this variable can be overridden, colours were being incorrectly set!
The ‘fix’ is to stop trying to be clever while only calculating the terminal width once, and instead just stick it in a lazy_static so it’s usable everywhere.
By parsing OsStrings rather than Strings, it’s the getopts crate that’s doing the UTF-8 checking rather than us, so if one of them isn’t valid, it’ll just fail to parse rather than crash exa.
Also, save a few allocations here and there.
Fixes#134, a bug that showed symlinks incorrectly as broken, but only when the file was listed directly on the command-line *and* the file was in a different directory to the one exa was being run in.
I’m not sure why the old code used `String::new()`, but it doesn’t seem to affect anything.
For some reason, the code that calculated the width of a cell with a path in counted the width of the path twice: once from the ANSIStrings containing it, and once more added on afterwards. This meant that the grid view thought that columns were wider than they really were, meaning fewer could be fit into a grid.
Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module.
This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
Rather than the *entire* file name.
The current method is extremely inefficient, but having control characters in file names is also extremely uncommon; it’s something that should be fixed, only eventually.
I think I took this off to see how the output was different. Which means there should really be a better way to check how the output is different, other than running the command and looking!
This name more accurately reflects which code is being tested (things like .png and Makefile, rather than pipes and sockets), freeing up file-types for *actual* file types to be tested.
The Vagrant tests assumed that there’d be a user called “vagrant” that would run the tests and create the files by default. Files would be owned by vagrant:vagrant by default, and this worked, until it came time to change that username. The naïve method was a search-and-replace, but this caused problems when the new user’s name wasn’t exactly the same length as the previous one.
So to fix this, we now have our own user, named after the first animal I thought of, that makes the files’ owners and groups independent of the default user of whichever VM image the xtests are running on.
Another place where it was hard-coded was the home directory, which was “/home/vagrant”, where the awkward testcases live. That last one has been changed to just “/testcases”, which has no mention of the user in it.
There was a problem with the Vagrant tests where the year 2016 was hard-coded in as the modified date. This had to be done to make the --long tests use the correct date format, which varies depending on whether the timestamp is in the current year.
Unfortunately, time progresses [citation needed], and what was once 2016 is now 2017, so the date format changed and the tests broke.
Because the Vagrantfile is just a Ruby script, we can look up the current year at runtime and use that instead. There’s also a check added to the test runner that makes sure none of the files are more than 365 days old, because if any are, then it’s time to update the timestamps (or it’s the last day of a leap year)
See #97 and recently #130 too.
This allows the user to pass in options such as "--ignore '*.pyc'" to not list any files ending in '.pyc' in the output. It uses the Rust glob crate and currently does a simple split on pipe, without any escaping, so it’s not really *complete*, but is at least something.
Fixes#123. The code assumes that every File that has its link_target() method called would first have been checked to make sure it’s actually a link first. Unfortunately it also assumed that the only thing that can go wrong while following a link is if the file wasn’t a link, meaning it crashes when given a link it doesn’t have permission to follow.
This makes the file_target() method able to return either a file or path for displaying, as before, but also an IO error for when things go wrong.
This changes the way that views are used to display the actual lists of files. It used to pass empty vectors to the view methods, which most of the time would not print anything because there are no files to list — except when there’s a header row which gets printed for no files.
By not calling the view method at all when there’s nothing to print, exa won’t ever print extra things in the view unless it needs to for a file.
This fixes#106 “Don’t print the header if the result set is empty”
See the README section for more details. Basically, with this way, we can store a bunch of existing valid exa outputs, change a VM's environment to match our values, then check that exa still works by comparing outputs.
