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
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
use std::env;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
use std::ffi::{OsStr, OsString};
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
use std::io::{stdout, stderr, Write, Result as IOResult, ErrorKind};
|
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};
|
|
|
|
|
|
2020-10-10 01:01:12 +00:00
|
|
|
|
use log::*;
|
2018-12-07 23:43:31 +00:00
|
|
|
|
|
|
|
|
|
use crate::fs::{Dir, File};
|
2020-10-09 23:09:44 +00:00
|
|
|
|
use crate::fs::filter::GitIgnore;
|
2018-12-07 23:43:31 +00:00
|
|
|
|
use crate::fs::feature::git::GitCache;
|
|
|
|
|
use crate::options::{Options, Vars};
|
|
|
|
|
pub use crate::options::vars;
|
|
|
|
|
pub use crate::options::Misfire;
|
|
|
|
|
use crate::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;
|
2020-10-10 01:01:12 +00:00
|
|
|
|
mod logger;
|
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
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
fn main() {
|
|
|
|
|
use std::process::exit;
|
|
|
|
|
|
2020-10-10 01:01:12 +00:00
|
|
|
|
logger::configure(env::var_os(vars::EXA_DEBUG));
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
|
|
|
|
let args: Vec<OsString> = env::args_os().skip(1).collect();
|
|
|
|
|
match Exa::from_args(args.iter(), &mut stdout()) {
|
|
|
|
|
Ok(mut exa) => {
|
|
|
|
|
match exa.run() {
|
|
|
|
|
Ok(exit_status) => exit(exit_status),
|
|
|
|
|
Err(e) => {
|
|
|
|
|
match e.kind() {
|
|
|
|
|
ErrorKind::BrokenPipe => exit(exits::SUCCESS),
|
|
|
|
|
_ => {
|
|
|
|
|
eprintln!("{}", e);
|
|
|
|
|
exit(exits::RUNTIME_ERROR);
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
Err(ref e) if e.is_error() => {
|
|
|
|
|
let mut stderr = stderr();
|
|
|
|
|
writeln!(stderr, "{}", e).unwrap();
|
|
|
|
|
|
|
|
|
|
if let Some(s) = e.suggestion() {
|
|
|
|
|
let _ = writeln!(stderr, "{}", s);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
exit(exits::OPTIONS_ERROR);
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
Err(ref e) => {
|
|
|
|
|
println!("{}", e);
|
|
|
|
|
exit(exits::SUCCESS);
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
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> {
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
env::var_os(name)
|
2017-08-10 16:54:28 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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() {
|
2018-06-19 12:58:03 +00:00
|
|
|
|
Some(args.iter().map(PathBuf::from).collect())
|
2017-09-01 18:13:47 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-26 16:48:18 +00:00
|
|
|
|
impl<'args, 'w, W: Write + 'w> Exa<'args, 'w, W> {
|
2018-12-16 07:18:43 +00:00
|
|
|
|
pub fn from_args<I>(args: I, writer: &'w mut W) -> Result<Exa<'args, 'w, W>, Misfire>
|
2017-07-26 16:48:18 +00:00
|
|
|
|
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);
|
2020-04-19 03:52:35 +00:00
|
|
|
|
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 {
|
2018-12-16 07:18:43 +00:00
|
|
|
|
match File::from_args(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) => {
|
2018-03-31 08:54:14 +00:00
|
|
|
|
if f.points_to_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 {
|
2018-06-19 12:58:03 +00:00
|
|
|
|
writeln!(self.writer)?;
|
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();
|
2020-10-09 23:09:44 +00:00
|
|
|
|
let git_ignore = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
for file in dir.files(self.options.filter.dot_filter, self.git.as_ref(), git_ignore) {
|
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();
|
2019-07-13 20:14:42 +00:00
|
|
|
|
for child_dir in children.iter().filter(|f| f.is_directory() && !f.is_all_all) {
|
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 {
|
2018-04-01 23:00:27 +00:00
|
|
|
|
Mode::Lines(ref opts) => {
|
|
|
|
|
let r = lines::Render { files, colours, style, opts };
|
2017-10-02 07:45:55 +00:00
|
|
|
|
r.render(self.writer)
|
2017-08-12 21:49:16 +00:00
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2017-08-12 21:49:16 +00:00
|
|
|
|
Mode::Grid(ref opts) => {
|
2017-10-02 07:45:55 +00:00
|
|
|
|
let r = grid::Render { files, colours, style, opts };
|
|
|
|
|
r.render(self.writer)
|
2017-08-12 21:49:16 +00:00
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2017-08-12 21:49:16 +00:00
|
|
|
|
Mode::Details(ref opts) => {
|
2017-10-02 07:43:49 +00:00
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let recurse = self.options.dir_action.recurse_options();
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-09 23:09:44 +00:00
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
let r = details::Render { dir, files, colours, style, opts, filter, recurse, git_ignoring };
|
2020-04-19 03:52:35 +00:00
|
|
|
|
r.render(self.git.as_ref(), self.writer)
|
2017-08-12 21:49:16 +00:00
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2017-08-12 21:49:16 +00:00
|
|
|
|
Mode::GridDetails(ref opts) => {
|
2017-10-02 07:43:49 +00:00
|
|
|
|
let grid = &opts.grid;
|
|
|
|
|
let filter = &self.options.filter;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
let details = &opts.details;
|
2017-10-02 07:43:49 +00:00
|
|
|
|
let row_threshold = opts.row_threshold;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-09 23:09:44 +00:00
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
let r = grid_details::Render { dir, files, colours, style, grid, details, filter, row_threshold, git_ignoring };
|
2017-10-02 07:45:55 +00:00
|
|
|
|
r.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
|
|
|
|
}
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mod exits {
|
|
|
|
|
|
|
|
|
|
/// Exit code for when exa runs OK.
|
|
|
|
|
pub const SUCCESS: i32 = 0;
|
|
|
|
|
|
|
|
|
|
/// Exit code for when there was at least one I/O error during execution.
|
|
|
|
|
pub const RUNTIME_ERROR: i32 = 1;
|
|
|
|
|
|
|
|
|
|
/// Exit code for when the command-line options are invalid.
|
|
|
|
|
pub const OPTIONS_ERROR: i32 = 3;
|
|
|
|
|
}
|