We already use MetadataExt and PermissionsExt, so it already requires a Unix system — there’s no point providing fallback implementations if it wouldn’t build on those systems anyway.
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?
This turns `file` into `self.file` and `colours` into `self.colours`, but it means we don’t need to pass arguments everywhere, which will be more of a problem the more functions there are.
Most of the code has just been indented.
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.
exa deals with cells and widths a lot: the items in a grid need to be aligned according to their *contents’* widths, rather than the length of their strings, which often included ANSI escape characters. As an optimisation, it used to calculate this separately based on the filename, and dealing with any extra characters (such as the classify ones) in that function too.
Recently, though, file names have become a lot more complicated. Classification added zero to one extra characters, and now with escaped control characters in file names, it’s not so easy to calculate the display width of a filename.
This commit removes the function that calculated the width, in favour of building the output string (it’s going to be displayed anyway) and just getting the width of what it displays instead.
It's confusing, and `ls` doesn't do this either. We're not prepending
the current path to all of the directory entries, and the user is going
to interpret the symlink target as relative to the directory containing
the symlink.
It’s the only file where its path is the same as its file name, and has been the source of numerous bugs in the past… this special-case isn’t very clean, but it works.
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 non-contrib Debian one doesn’t come with guest additions, meaning it used rsync instead of Virtualbox shared folders to sync files, meaning edits made in the VM didn’t get propogated back to the host, meaning I got very confused for a while.
Thanks to the parent commit, this shouldn’t be an issue at all: the default user name, which is now “ubuntu” instead of “vagrant” is specified in a lot fewer places, making it much easier to change.
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)
