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};
|
2020-10-10 01:34:54 +00:00
|
|
|
|
use std::io::{stdout, 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};
|
|
|
|
|
use crate::fs::feature::git::GitCache;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
use crate::fs::filter::GitIgnore;
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
use crate::options::{Options, Vars, vars, OptionsResult};
|
2018-12-07 23:43:31 +00:00
|
|
|
|
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
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
let args: Vec<_> = env::args_os().skip(1).collect();
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
match Options::parse(&args, &LiveVars) {
|
|
|
|
|
OptionsResult::Ok(options, mut input_paths) => {
|
|
|
|
|
|
|
|
|
|
// List the current directory by default.
|
|
|
|
|
// (This has to be done here, otherwise git_options won’t see it.)
|
|
|
|
|
if input_paths.is_empty() {
|
|
|
|
|
input_paths = vec![ OsStr::new(".") ];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let git = git_options(&options, &input_paths);
|
|
|
|
|
let writer = stdout();
|
|
|
|
|
let exa = Exa { options, writer, input_paths, git };
|
|
|
|
|
|
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
|
|
|
|
match exa.run() {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Ok(exit_status) => {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
exit(exit_status);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Err(e) if e.kind() == ErrorKind::BrokenPipe => {
|
|
|
|
|
warn!("Broken pipe error: {}", e);
|
|
|
|
|
exit(exits::SUCCESS);
|
2020-10-10 18:49:46 +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
|
|
|
|
Err(e) => {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
eprintln!("{}", e);
|
|
|
|
|
exit(exits::RUNTIME_ERROR);
|
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
|
|
|
|
}
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OptionsResult::Help(help_text) => {
|
|
|
|
|
println!("{}", help_text);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OptionsResult::Version(version_str) => {
|
|
|
|
|
println!("{}", version_str);
|
2020-10-10 18:49:46 +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
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
OptionsResult::InvalidOptions(error) => {
|
|
|
|
|
eprintln!("{}", error);
|
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
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
if let Some(s) = error.suggestion() {
|
|
|
|
|
eprintln!("{}", s);
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
exit(exits::OPTIONS_ERROR);
|
2020-10-10 18:49:46 +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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
/// The main program wrapper.
|
2020-10-10 01:34:54 +00:00
|
|
|
|
pub struct Exa<'args> {
|
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
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
/// The output handle that we write to.
|
|
|
|
|
pub writer: Stdout,
|
2016-04-19 06:48:41 +00:00
|
|
|
|
|
|
|
|
|
/// List of the free command-line arguments that should correspond to file
|
|
|
|
|
/// names (anything that isn’t an option).
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
pub input_paths: 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
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
impl<'args> Exa<'args> {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
pub fn run(mut self) -> IOResult<i32> {
|
|
|
|
|
debug!("Running with options: {:#?}", self.options);
|
2016-04-19 06:48:41 +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 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
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
for file_path in &self.input_paths {
|
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)?;
|
2020-10-10 18:49:46 +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
|
|
|
|
Ok(f) => {
|
2020-10-10 18:49:46 +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() {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Ok(d) => dirs.push(d),
|
|
|
|
|
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
|
|
|
|
}
|
2020-10-10 18:49:46 +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 {
|
2020-10-10 01:34:54 +00:00
|
|
|
|
writeln!(&mut self.writer)?;
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-10-10 18:49:46 +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());
|
2020-10-10 01:34:54 +00:00
|
|
|
|
writeln!(&mut 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;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
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();
|
2020-10-10 18:49:46 +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<()> {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
if files.is_empty() {
|
|
|
|
|
return Ok(());
|
|
|
|
|
}
|
2017-06-25 23:53:48 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
let View { ref mode, ref colours, ref style } = self.options.view;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
match mode {
|
|
|
|
|
Mode::Lines(ref opts) => {
|
|
|
|
|
let r = lines::Render { files, colours, style, opts };
|
|
|
|
|
r.render(&mut self.writer)
|
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Mode::Grid(ref opts) => {
|
|
|
|
|
let r = grid::Render { files, colours, style, opts };
|
|
|
|
|
r.render(&mut self.writer)
|
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Mode::Details(ref opts) => {
|
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let recurse = self.options.dir_action.recurse_options();
|
|
|
|
|
|
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
let r = details::Render { dir, files, colours, style, opts, filter, recurse, git_ignoring };
|
|
|
|
|
r.render(self.git.as_ref(), &mut self.writer)
|
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Mode::GridDetails(ref opts) => {
|
|
|
|
|
let grid = &opts.grid;
|
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let details = &opts.details;
|
|
|
|
|
let row_threshold = opts.row_threshold;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-10 18:49:46 +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 };
|
|
|
|
|
r.render(self.git.as_ref(), &mut self.writer)
|
2016-10-29 18:07:43 +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;
|
|
|
|
|
}
|