2015-09-04 10:17:59 +00:00
|
|
|
|
#![warn(trivial_casts, trivial_numeric_casts)]
|
2015-11-15 19:26:58 +00:00
|
|
|
|
#![warn(unused_qualifications)]
|
2015-09-04 10:30:46 +00:00
|
|
|
|
#![warn(unused_results)]
|
2015-09-04 10:17:59 +00:00
|
|
|
|
|
2014-07-01 18:00:36 +00:00
|
|
|
|
extern crate ansi_term;
|
2015-02-09 16:33:27 +00:00
|
|
|
|
extern crate datetime;
|
2015-01-31 16:10:40 +00:00
|
|
|
|
extern crate getopts;
|
2015-05-16 12:17:50 +00:00
|
|
|
|
extern crate libc;
|
2015-02-10 16:08:10 +00:00
|
|
|
|
extern crate locale;
|
2015-01-31 16:10:40 +00:00
|
|
|
|
extern crate natord;
|
2015-04-03 22:14:49 +00:00
|
|
|
|
extern crate num_cpus;
|
2014-12-18 07:00:31 +00:00
|
|
|
|
extern crate number_prefix;
|
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
|
|
|
|
extern crate scoped_threadpool;
|
2015-06-23 09:54:57 +00:00
|
|
|
|
extern crate term_grid;
|
2015-04-23 12:46:37 +00:00
|
|
|
|
extern crate unicode_width;
|
2015-06-08 20:33:39 +00:00
|
|
|
|
extern crate users;
|
2016-02-10 19:02:20 +00:00
|
|
|
|
extern crate zoneinfo_compiled;
|
2015-04-23 12:46:37 +00:00
|
|
|
|
|
2015-11-15 19:26:58 +00:00
|
|
|
|
#[cfg(feature="git")] extern crate git2;
|
|
|
|
|
#[macro_use] extern crate lazy_static;
|
2015-06-08 20:33:39 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
use std::ffi::OsStr;
|
|
|
|
|
use std::io::{Write, Result as IOResult};
|
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
|
|
|
|
use std::path::{Component, Path};
|
2014-05-04 20:33:14 +00:00
|
|
|
|
|
2016-04-16 17:59:25 +00:00
|
|
|
|
use fs::{Dir, File};
|
2015-02-24 16:05:25 +00:00
|
|
|
|
use options::{Options, View};
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub use options::Misfire;
|
2014-12-12 11:17:55 +00:00
|
|
|
|
|
2016-04-16 17:59:25 +00:00
|
|
|
|
mod fs;
|
2016-04-16 21:05:50 +00:00
|
|
|
|
mod info;
|
2015-05-07 21:20:24 +00:00
|
|
|
|
mod options;
|
|
|
|
|
mod output;
|
|
|
|
|
mod term;
|
2014-05-04 16:01:54 +00:00
|
|
|
|
|
2015-06-05 02:04:56 +00:00
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
/// The main program wrapper.
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub struct Exa<'w, W: Write + 'w> {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
|
|
|
|
/// List of command-line options, having been successfully parsed.
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub options: Options,
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
|
|
|
|
/// The output handle that we write to. When running the program normally,
|
|
|
|
|
/// this will be `std::io::Stdout`, but it can accept any struct that’s
|
|
|
|
|
/// `Write` so we can write into, say, a vector for testing.
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub writer: &'w mut W,
|
|
|
|
|
|
|
|
|
|
/// List of the free command-line arguments that should correspond to file
|
|
|
|
|
/// names (anything that isn’t an option).
|
|
|
|
|
pub args: Vec<String>,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-01-12 18:44:39 +00:00
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
impl<'w, W: Write + 'w> Exa<'w, W> {
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub fn new<S>(args: &[S], writer: &'w mut W) -> Result<Exa<'w, W>, Misfire>
|
|
|
|
|
where S: AsRef<OsStr> {
|
|
|
|
|
Options::getopts(args).map(move |(opts, args)| Exa {
|
|
|
|
|
options: opts,
|
|
|
|
|
writer: writer,
|
|
|
|
|
args: args,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub fn run(&mut self) -> IOResult<()> {
|
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
|
|
|
|
let mut files = Vec::new();
|
|
|
|
|
let mut dirs = Vec::new();
|
2015-03-04 02:48:36 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
// List the current directory by default, like ls.
|
|
|
|
|
if self.args.is_empty() {
|
|
|
|
|
self.args.push(".".to_owned());
|
2015-11-15 15:52:55 +00:00
|
|
|
|
}
|
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
for file_name in self.args.iter() {
|
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
|
|
|
|
match File::from_path(Path::new(&file_name), None) {
|
|
|
|
|
Err(e) => {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(writeln!(self.writer, "{}: {}", file_name, e));
|
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
|
|
|
|
},
|
|
|
|
|
Ok(f) => {
|
|
|
|
|
if f.is_directory() && !self.options.dir_action.treat_dirs_as_files() {
|
|
|
|
|
match f.to_dir(self.options.should_scan_for_git()) {
|
|
|
|
|
Ok(d) => dirs.push(d),
|
2016-04-18 17:39:32 +00:00
|
|
|
|
Err(e) => try!(writeln!(self.writer, "{}: {}", file_name, e)),
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
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
|
|
|
|
else {
|
|
|
|
|
files.push(f);
|
2015-03-04 03:41:30 +00:00
|
|
|
|
}
|
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
|
|
|
|
},
|
2015-06-05 02:04:56 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
2014-12-12 11:17:55 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
// We want to print a directory’s name before we list it, *except* in
|
|
|
|
|
// the case where it’s the only directory, *except* if there are any
|
|
|
|
|
// files to print as well. (It’s a double negative)
|
|
|
|
|
|
2015-09-05 16:40:02 +00:00
|
|
|
|
let no_files = files.is_empty();
|
2016-04-11 06:48:23 +00:00
|
|
|
|
let is_only_dir = dirs.len() == 1 && no_files;
|
|
|
|
|
|
2015-09-05 16:40:02 +00:00
|
|
|
|
if !no_files {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(self.print_files(None, files));
|
2015-09-05 16:40:02 +00:00
|
|
|
|
}
|
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
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
self.print_dirs(dirs, no_files, is_only_dir)
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
fn print_dirs(&mut self, dir_files: Vec<Dir>, mut first: bool, is_only_dir: bool) -> IOResult<()> {
|
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
|
|
|
|
for dir in dir_files {
|
2015-02-05 14:39:56 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
// Put a gap between directories, or between the list of files and
|
|
|
|
|
// the first directory.
|
2015-02-05 14:39:56 +00:00
|
|
|
|
if first {
|
|
|
|
|
first = false;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(write!(self.writer, "\n"));
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
if !is_only_dir {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(writeln!(self.writer, "{}:", dir.path.display()));
|
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
|
|
|
|
}
|
2015-08-25 14:04:15 +00:00
|
|
|
|
|
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
|
|
|
|
let mut children = Vec::new();
|
|
|
|
|
for file in dir.files() {
|
|
|
|
|
match file {
|
|
|
|
|
Ok(file) => children.push(file),
|
2016-04-18 17:39:32 +00:00
|
|
|
|
Err((path, e)) => try!(writeln!(self.writer, "[{}: {}]", path.display(), e)),
|
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
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2015-11-14 23:32:57 +00:00
|
|
|
|
self.options.filter.filter_files(&mut children);
|
|
|
|
|
self.options.filter.sort_files(&mut children);
|
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
|
|
|
|
|
|
|
|
|
if let Some(recurse_opts) = self.options.dir_action.recurse_options() {
|
|
|
|
|
let depth = dir.path.components().filter(|&c| c != Component::CurDir).count() + 1;
|
|
|
|
|
if !recurse_opts.tree && !recurse_opts.is_too_deep(depth) {
|
2015-08-25 14:04:15 +00:00
|
|
|
|
|
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
|
|
|
|
let mut child_dirs = Vec::new();
|
|
|
|
|
for child_dir in children.iter().filter(|f| f.is_directory()) {
|
|
|
|
|
match child_dir.to_dir(false) {
|
|
|
|
|
Ok(d) => child_dirs.push(d),
|
2016-04-18 17:39:32 +00:00
|
|
|
|
Err(e) => try!(writeln!(self.writer, "{}: {}", child_dir.path.display(), e)),
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-02-01 02:14:31 +00:00
|
|
|
|
}
|
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(self.print_files(Some(&dir), children));
|
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
|
|
|
|
|
|
|
|
|
if !child_dirs.is_empty() {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(self.print_dirs(child_dirs, false, false));
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
continue;
|
2014-07-22 21:19:51 +00:00
|
|
|
|
}
|
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
|
|
|
|
}
|
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
try!(self.print_files(Some(&dir), children));
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
|
|
|
|
Ok(())
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-07-22 21:19:51 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
/// Prints the list of files using whichever view is selected.
|
|
|
|
|
/// For various annoying logistical reasons, each one handles
|
|
|
|
|
/// printing differently...
|
2016-04-18 17:39:32 +00:00
|
|
|
|
fn print_files(&mut self, dir: Option<&Dir>, files: Vec<File>) -> IOResult<()> {
|
2015-02-05 14:39:56 +00:00
|
|
|
|
match self.options.view {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
View::Grid(g) => g.view(&files, self.writer),
|
|
|
|
|
View::Details(d) => d.view(dir, files, self.writer),
|
|
|
|
|
View::GridDetails(gd) => gd.view(dir, files, self.writer),
|
|
|
|
|
View::Lines(l) => l.view(files, self.writer),
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
}
|
2014-07-05 21:36:43 +00:00
|
|
|
|
}
|