2015-09-04 10:17:59 +00:00
|
|
|
|
#![warn(trivial_casts, trivial_numeric_casts)]
|
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;
|
2016-10-30 14:43:33 +00:00
|
|
|
|
extern crate glob;
|
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;
|
2017-08-05 06:09:26 +00:00
|
|
|
|
extern crate term_size;
|
2015-04-23 12:46:37 +00:00
|
|
|
|
|
2015-11-15 19:26:58 +00:00
|
|
|
|
#[cfg(feature="git")] extern crate git2;
|
2015-06-08 20:33:39 +00:00
|
|
|
|
|
2017-08-19 09:06:07 +00:00
|
|
|
|
#[macro_use] extern crate lazy_static;
|
|
|
|
|
#[macro_use] extern crate log;
|
2017-06-25 13:51:44 +00:00
|
|
|
|
|
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
use std::env::var_os;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
use std::ffi::{OsStr, OsString};
|
2016-07-30 19:12:03 +00:00
|
|
|
|
use std::io::{stderr, Write, Result as IOResult};
|
2017-06-29 12:07:45 +00:00
|
|
|
|
use std::path::{Component, PathBuf};
|
2014-05-04 20:33:14 +00:00
|
|
|
|
|
2017-05-01 20:54:53 +00:00
|
|
|
|
use ansi_term::{ANSIStrings, Style};
|
|
|
|
|
|
2016-04-16 17:59:25 +00:00
|
|
|
|
use fs::{Dir, File};
|
2017-08-28 17:11:38 +00:00
|
|
|
|
use fs::feature::git::GitCache;
|
2017-08-10 16:54:28 +00:00
|
|
|
|
use options::{Options, Vars};
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub use options::Misfire;
|
2017-07-24 07:34:50 +00:00
|
|
|
|
use output::{escape, lines, grid, grid_details, details, View, Mode};
|
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;
|
2017-08-26 20:40:37 +00:00
|
|
|
|
mod style;
|
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.
|
2017-07-26 16:48:18 +00:00
|
|
|
|
pub struct Exa<'args, '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).
|
2017-07-26 16:48:18 +00:00
|
|
|
|
pub args: Vec<&'args OsStr>,
|
2017-09-01 18:13:47 +00:00
|
|
|
|
|
|
|
|
|
/// A global Git cache, if the option was passed in.
|
|
|
|
|
/// This has to last the lifetime of the program, because the user might
|
|
|
|
|
/// want to list several directories in the same repository.
|
|
|
|
|
pub git: Option<GitCache>,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-01-12 18:44:39 +00:00
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
/// The “real” environment variables type.
|
|
|
|
|
/// Instead of just calling `var_os` from within the options module,
|
|
|
|
|
/// the method of looking up environment variables has to be passed in.
|
|
|
|
|
struct LiveVars;
|
|
|
|
|
impl Vars for LiveVars {
|
|
|
|
|
fn get(&self, name: &'static str) -> Option<OsString> {
|
|
|
|
|
var_os(name)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-01 18:13:47 +00:00
|
|
|
|
/// Create a Git cache populated with the arguments that are going to be
|
|
|
|
|
/// listed before they’re actually listed, if the options demand it.
|
|
|
|
|
fn git_options(options: &Options, args: &[&OsStr]) -> Option<GitCache> {
|
|
|
|
|
if options.should_scan_for_git() {
|
|
|
|
|
Some(args.iter().map(|os| PathBuf::from(os)).collect())
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-26 16:48:18 +00:00
|
|
|
|
impl<'args, 'w, W: Write + 'w> Exa<'args, 'w, W> {
|
|
|
|
|
pub fn new<I>(args: I, writer: &'w mut W) -> Result<Exa<'args, 'w, W>, Misfire>
|
|
|
|
|
where I: Iterator<Item=&'args OsString> {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
Options::parse(args, &LiveVars).map(move |(options, mut args)| {
|
2017-08-19 21:39:34 +00:00
|
|
|
|
debug!("Dir action from arguments: {:#?}", options.dir_action);
|
|
|
|
|
debug!("Filter from arguments: {:#?}", options.filter);
|
|
|
|
|
debug!("View from arguments: {:#?}", options.view.mode);
|
2017-09-01 18:13:47 +00:00
|
|
|
|
|
|
|
|
|
// List the current directory by default, like ls.
|
|
|
|
|
// This has to be done here, otherwise git_options won’t see it.
|
|
|
|
|
if args.is_empty() {
|
|
|
|
|
args = vec![ OsStr::new(".") ];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let git = git_options(&options, &args);
|
|
|
|
|
Exa { options, writer, args, git }
|
2016-04-19 06:48:41 +00:00
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
pub fn run(&mut self) -> IOResult<i32> {
|
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();
|
2017-02-26 11:18:46 +00:00
|
|
|
|
let mut exit_status = 0;
|
2015-03-04 02:48:36 +00:00
|
|
|
|
|
2017-07-26 16:48:18 +00:00
|
|
|
|
for file_path in &self.args {
|
|
|
|
|
match File::new(PathBuf::from(file_path), None, None) {
|
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
|
|
|
|
Err(e) => {
|
2017-02-26 11:18:46 +00:00
|
|
|
|
exit_status = 2;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
writeln!(stderr(), "{:?}: {}", file_path, 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() {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
match f.to_dir() {
|
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(d) => dirs.push(d),
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Err(e) => writeln!(stderr(), "{:?}: {}", file_path, 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;
|
|
|
|
|
|
2016-10-30 14:43:33 +00:00
|
|
|
|
self.options.filter.filter_argument_files(&mut files);
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(None, files)?;
|
2016-10-30 14:43:33 +00:00
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
self.print_dirs(dirs, no_files, is_only_dir, exit_status)
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
fn print_dirs(&mut self, dir_files: Vec<Dir>, mut first: bool, is_only_dir: bool, exit_status: i32) -> IOResult<i32> {
|
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 {
|
2017-03-26 16:35:50 +00:00
|
|
|
|
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 {
|
2017-05-01 20:54:53 +00:00
|
|
|
|
let mut bits = Vec::new();
|
|
|
|
|
escape(dir.path.display().to_string(), &mut bits, Style::default(), Style::default());
|
|
|
|
|
writeln!(self.writer, "{}:", ANSIStrings(&bits))?;
|
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();
|
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
|
|
|
|
for file in dir.files(self.options.filter.dot_filter) {
|
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 {
|
|
|
|
|
Ok(file) => children.push(file),
|
2017-03-26 16:35:50 +00:00
|
|
|
|
Err((path, e)) => writeln!(stderr(), "[{}: {}]", 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
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2016-10-30 14:43:33 +00:00
|
|
|
|
self.options.filter.filter_child_files(&mut children);
|
2015-11-14 23:32:57 +00:00
|
|
|
|
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()) {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
match child_dir.to_dir() {
|
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(d) => child_dirs.push(d),
|
2017-03-26 16:35:50 +00:00
|
|
|
|
Err(e) => writeln!(stderr(), "{}: {}", child_dir.path.display(), e)?,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-02-01 02:14:31 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(Some(&dir), children)?;
|
2017-02-26 11:18:46 +00:00
|
|
|
|
match self.print_dirs(child_dirs, false, false, exit_status) {
|
|
|
|
|
Ok(_) => (),
|
|
|
|
|
Err(e) => return Err(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
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(Some(&dir), children)?;
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
Ok(exit_status)
|
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<()> {
|
2016-10-29 18:07:43 +00:00
|
|
|
|
if !files.is_empty() {
|
2017-07-08 11:11:11 +00:00
|
|
|
|
let View { ref mode, ref colours, ref style } = self.options.view;
|
2017-06-25 23:53:48 +00:00
|
|
|
|
|
2017-06-24 21:39:15 +00:00
|
|
|
|
match *mode {
|
2017-08-12 21:49:16 +00:00
|
|
|
|
Mode::Lines => {
|
|
|
|
|
lines::Render { files, colours, style }.render(self.writer)
|
|
|
|
|
}
|
|
|
|
|
Mode::Grid(ref opts) => {
|
|
|
|
|
grid::Render { files, colours, style, opts }.render(self.writer)
|
|
|
|
|
}
|
|
|
|
|
Mode::Details(ref opts) => {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
details::Render { dir, files, colours, style, opts, filter: &self.options.filter, recurse: self.options.dir_action.recurse_options() }.render(self.git.as_ref(), self.writer)
|
2017-08-12 21:49:16 +00:00
|
|
|
|
}
|
|
|
|
|
Mode::GridDetails(ref opts) => {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
grid_details::Render { dir, files, colours, style, grid: &opts.grid, details: &opts.details, filter: &self.options.filter, row_threshold: opts.row_threshold }.render(self.git.as_ref(), self.writer)
|
2017-08-12 21:49:16 +00:00
|
|
|
|
}
|
2016-10-29 18:07:43 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
Ok(())
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
}
|
2014-07-05 21:36:43 +00:00
|
|
|
|
}
|