2015-12-15 21:47:37 +00:00
|
|
|
|
use std::io::{self, Result as IOResult};
|
Use new io + path + fs libraries (LOTS OF CHANGES)
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
2015-04-23 12:00:34 +00:00
|
|
|
|
use std::fs;
|
|
|
|
|
use std::path::{Path, PathBuf};
|
2015-08-25 10:27:08 +00:00
|
|
|
|
use std::slice::Iter as SliceIter;
|
Use new io + path + fs libraries (LOTS OF CHANGES)
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
2015-04-23 12:00:34 +00:00
|
|
|
|
|
2017-09-01 18:13:47 +00:00
|
|
|
|
use fs::File;
|
2015-06-08 20:33:39 +00:00
|
|
|
|
|
|
|
|
|
|
2015-01-24 12:38:05 +00:00
|
|
|
|
/// A **Dir** provides a cached list of the file paths in a directory that's
|
|
|
|
|
/// being listed.
|
|
|
|
|
///
|
|
|
|
|
/// This object gets passed to the Files themselves, in order for them to
|
|
|
|
|
/// check the existence of surrounding files, then highlight themselves
|
|
|
|
|
/// accordingly. (See `File#get_source_files`)
|
2014-11-26 07:40:52 +00:00
|
|
|
|
pub struct Dir {
|
2015-09-03 17:48:53 +00:00
|
|
|
|
|
|
|
|
|
/// A vector of the files that have been read from this directory.
|
Use new io + path + fs libraries (LOTS OF CHANGES)
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
2015-04-23 12:00:34 +00:00
|
|
|
|
contents: Vec<PathBuf>,
|
2015-09-03 17:48:53 +00:00
|
|
|
|
|
|
|
|
|
/// The path that was read.
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
pub path: PathBuf,
|
2017-08-28 17:11:38 +00:00
|
|
|
|
}
|
|
|
|
|
|
2014-11-26 07:40:52 +00:00
|
|
|
|
impl Dir {
|
2015-03-26 00:37:12 +00:00
|
|
|
|
|
2015-01-24 12:38:05 +00:00
|
|
|
|
/// Create a new Dir object filled with all the files in the directory
|
2017-06-27 00:13:50 +00:00
|
|
|
|
/// pointed to by the given path. Fails if the directory can’t be read, or
|
|
|
|
|
/// isn’t actually a directory, or if there’s an IO error that occurs at
|
|
|
|
|
/// any point.
|
|
|
|
|
///
|
|
|
|
|
/// The `read_dir` iterator doesn’t actually yield the `.` and `..`
|
|
|
|
|
/// entries, so if the user wants to see them, we’ll have to add them
|
|
|
|
|
/// ourselves after the files have been read.
|
2017-09-01 18:13:47 +00:00
|
|
|
|
pub fn read_dir(path: PathBuf) -> IOResult<Dir> {
|
2017-08-20 17:14:40 +00:00
|
|
|
|
info!("Reading directory {:?}", &path);
|
2017-08-26 22:53:47 +00:00
|
|
|
|
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
let contents: Vec<PathBuf> = try!(fs::read_dir(&path)?
|
2017-09-01 18:13:47 +00:00
|
|
|
|
.map(|result| result.map(|entry| entry.path()))
|
|
|
|
|
.collect());
|
2015-08-26 11:19:23 +00:00
|
|
|
|
|
2017-09-01 18:13:47 +00:00
|
|
|
|
Ok(Dir { contents, path })
|
2014-06-16 23:27:05 +00:00
|
|
|
|
}
|
|
|
|
|
|
2015-08-26 11:19:23 +00:00
|
|
|
|
/// Produce an iterator of IO results of trying to read all the files in
|
|
|
|
|
/// this directory.
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
pub fn files(&self, dots: DotFilter) -> Files {
|
2015-08-25 10:27:08 +00:00
|
|
|
|
Files {
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
inner: self.contents.iter(),
|
|
|
|
|
dir: self,
|
|
|
|
|
dotfiles: dots.shows_dotfiles(),
|
|
|
|
|
dots: dots.dots(),
|
2014-06-20 20:07:53 +00:00
|
|
|
|
}
|
2014-06-16 23:27:05 +00:00
|
|
|
|
}
|
|
|
|
|
|
2015-01-24 12:38:05 +00:00
|
|
|
|
/// Whether this directory contains a file with the given path.
|
2014-06-16 23:27:05 +00:00
|
|
|
|
pub fn contains(&self, path: &Path) -> bool {
|
2017-03-31 16:09:32 +00:00
|
|
|
|
self.contents.iter().any(|p| p.as_path() == path)
|
2014-06-16 23:27:05 +00:00
|
|
|
|
}
|
2015-01-26 17:26:11 +00:00
|
|
|
|
|
|
|
|
|
/// Append a path onto the path specified by this directory.
|
Use new io + path + fs libraries (LOTS OF CHANGES)
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
2015-04-23 12:00:34 +00:00
|
|
|
|
pub fn join(&self, child: &Path) -> PathBuf {
|
2015-01-26 17:26:11 +00:00
|
|
|
|
self.path.join(child)
|
|
|
|
|
}
|
2014-06-16 23:27:05 +00:00
|
|
|
|
}
|
2015-08-25 10:27:08 +00:00
|
|
|
|
|
|
|
|
|
|
2015-09-03 17:48:53 +00:00
|
|
|
|
/// Iterator over reading the contents of a directory as `File` objects.
|
2015-08-25 10:27:08 +00:00
|
|
|
|
pub struct Files<'dir> {
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
|
|
|
|
|
/// The internal iterator over the paths that have been read already.
|
2015-08-25 10:27:08 +00:00
|
|
|
|
inner: SliceIter<'dir, PathBuf>,
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
|
|
|
|
|
/// The directory that begat those paths.
|
2015-08-25 10:27:08 +00:00
|
|
|
|
dir: &'dir Dir,
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
|
|
|
|
|
/// Whether to include dotfiles in the list.
|
|
|
|
|
dotfiles: bool,
|
|
|
|
|
|
|
|
|
|
/// Whether the `.` or `..` directories should be produced first, before
|
|
|
|
|
/// any files have been listed.
|
|
|
|
|
dots: Dots,
|
2015-08-25 10:27:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
impl<'dir> Files<'dir> {
|
|
|
|
|
fn parent(&self) -> PathBuf {
|
|
|
|
|
// We can’t use `Path#parent` here because all it does is remove the
|
|
|
|
|
// last path component, which is no good for us if the path is
|
|
|
|
|
// relative. For example, while the parent of `/testcases/files` is
|
|
|
|
|
// `/testcases`, the parent of `.` is an empty path. Adding `..` on
|
|
|
|
|
// the end is the only way to get to the *actual* parent directory.
|
|
|
|
|
self.dir.path.join("..")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Go through the directory until we encounter a file we can list (which
|
|
|
|
|
/// varies depending on the dotfile visibility flag)
|
|
|
|
|
fn next_visible_file(&mut self) -> Option<Result<File<'dir>, (PathBuf, io::Error)>> {
|
|
|
|
|
loop {
|
|
|
|
|
if let Some(path) = self.inner.next() {
|
2017-06-29 12:17:26 +00:00
|
|
|
|
let filename = File::filename(path);
|
|
|
|
|
if !self.dotfiles && filename.starts_with(".") { continue }
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
|
2017-06-29 12:17:26 +00:00
|
|
|
|
return Some(File::new(path.clone(), self.dir, filename)
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
.map_err(|e| (path.clone(), e)))
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
return None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// The dot directories that need to be listed before actual files, if any.
|
|
|
|
|
/// If these aren’t being printed, then `FilesNext` is used to skip them.
|
|
|
|
|
enum Dots {
|
|
|
|
|
|
|
|
|
|
/// List the `.` directory next.
|
|
|
|
|
DotNext,
|
|
|
|
|
|
|
|
|
|
/// List the `..` directory next.
|
|
|
|
|
DotDotNext,
|
|
|
|
|
|
|
|
|
|
/// Forget about the dot directories and just list files.
|
|
|
|
|
FilesNext,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2015-08-25 10:27:08 +00:00
|
|
|
|
impl<'dir> Iterator for Files<'dir> {
|
2015-08-25 14:04:15 +00:00
|
|
|
|
type Item = Result<File<'dir>, (PathBuf, io::Error)>;
|
2015-08-25 10:27:08 +00:00
|
|
|
|
|
|
|
|
|
fn next(&mut self) -> Option<Self::Item> {
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
if let Dots::DotNext = self.dots {
|
|
|
|
|
self.dots = Dots::DotDotNext;
|
2017-06-29 12:17:26 +00:00
|
|
|
|
Some(File::new(self.dir.path.to_path_buf(), self.dir, String::from("."))
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
.map_err(|e| (Path::new(".").to_path_buf(), e)))
|
|
|
|
|
}
|
|
|
|
|
else if let Dots::DotDotNext = self.dots {
|
|
|
|
|
self.dots = Dots::FilesNext;
|
2017-06-29 12:17:26 +00:00
|
|
|
|
Some(File::new(self.parent(), self.dir, String::from(".."))
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
.map_err(|e| (self.parent(), e)))
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
self.next_visible_file()
|
|
|
|
|
}
|
2015-08-25 10:27:08 +00:00
|
|
|
|
}
|
2017-06-27 00:13:50 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/// Usually files in Unix use a leading dot to be hidden or visible, but two
|
|
|
|
|
/// entries in particular are "extra-hidden": `.` and `..`, which only become
|
|
|
|
|
/// visible after an extra `-a` option.
|
|
|
|
|
#[derive(PartialEq, Debug, Copy, Clone)]
|
|
|
|
|
pub enum DotFilter {
|
|
|
|
|
|
|
|
|
|
/// Shows files, dotfiles, and `.` and `..`.
|
|
|
|
|
DotfilesAndDots,
|
|
|
|
|
|
|
|
|
|
/// Show files and dotfiles, but hide `.` and `..`.
|
|
|
|
|
Dotfiles,
|
|
|
|
|
|
|
|
|
|
/// Just show files, hiding anything beginning with a dot.
|
|
|
|
|
JustFiles,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Default for DotFilter {
|
|
|
|
|
fn default() -> DotFilter {
|
|
|
|
|
DotFilter::JustFiles
|
|
|
|
|
}
|
|
|
|
|
}
|
Override the names of . and ..
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!
2017-06-28 17:41:31 +00:00
|
|
|
|
|
|
|
|
|
impl DotFilter {
|
|
|
|
|
|
|
|
|
|
/// Whether this filter should show dotfiles in a listing.
|
|
|
|
|
fn shows_dotfiles(&self) -> bool {
|
|
|
|
|
match *self {
|
|
|
|
|
DotFilter::JustFiles => false,
|
|
|
|
|
DotFilter::Dotfiles => true,
|
|
|
|
|
DotFilter::DotfilesAndDots => true,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Whether this filter should add dot directories to a listing.
|
|
|
|
|
fn dots(&self) -> Dots {
|
|
|
|
|
match *self {
|
|
|
|
|
DotFilter::JustFiles => Dots::FilesNext,
|
|
|
|
|
DotFilter::Dotfiles => Dots::FilesNext,
|
|
|
|
|
DotFilter::DotfilesAndDots => Dots::DotNext,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|