2017-08-13 10:15:40 +00:00
|
|
|
|
use output::{View, Mode, grid, details};
|
|
|
|
|
use output::grid_details::{self, RowThreshold};
|
2017-08-09 21:25:16 +00:00
|
|
|
|
use output::table::{TimeTypes, Environment, SizeFormat, Columns, Options as TableOptions};
|
2017-07-05 23:01:45 +00:00
|
|
|
|
use output::time::TimeFormat;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
use options::{flags, Misfire, Vars};
|
2017-08-05 18:11:00 +00:00
|
|
|
|
use options::parser::MatchedFlags;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
|
2016-04-17 19:38:37 +00:00
|
|
|
|
use fs::feature::xattr;
|
|
|
|
|
|
2017-08-24 22:38:26 +00:00
|
|
|
|
|
2017-06-25 11:31:46 +00:00
|
|
|
|
impl View {
|
|
|
|
|
|
|
|
|
|
/// Determine which view to use and all of that view’s arguments.
|
2017-08-13 10:14:58 +00:00
|
|
|
|
pub fn deduce<V: Vars>(matches: &MatchedFlags, vars: &V) -> Result<View, Misfire> {
|
2017-09-13 07:44:59 +00:00
|
|
|
|
use options::style::Styles;
|
2017-09-03 18:50:40 +00:00
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
let mode = Mode::deduce(matches, vars)?;
|
2017-09-13 07:44:59 +00:00
|
|
|
|
let Styles { colours, style } = Styles::deduce(matches, vars, || *TERM_WIDTH)?;
|
2017-07-08 11:11:11 +00:00
|
|
|
|
Ok(View { mode, colours, style })
|
2017-06-25 11:31:46 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
impl Mode {
|
2016-04-17 19:38:37 +00:00
|
|
|
|
|
2017-06-25 13:59:38 +00:00
|
|
|
|
/// Determine the mode from the command-line arguments.
|
2017-08-13 10:14:58 +00:00
|
|
|
|
pub fn deduce<V: Vars>(matches: &MatchedFlags, vars: &V) -> Result<Mode, Misfire> {
|
2016-04-17 19:38:37 +00:00
|
|
|
|
use options::misfire::Misfire::*;
|
|
|
|
|
|
|
|
|
|
let long = || {
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
if matches.has(&flags::ACROSS)? && !matches.has(&flags::GRID)? {
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Err(Useless(&flags::ACROSS, true, &flags::LONG))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
else if matches.has(&flags::ONE_LINE)? {
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Err(Useless(&flags::ONE_LINE, true, &flags::LONG))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-06-26 07:38:56 +00:00
|
|
|
|
Ok(details::Options {
|
2017-07-05 20:01:01 +00:00
|
|
|
|
table: Some(TableOptions::deduce(matches)?),
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
header: matches.has(&flags::HEADER)?,
|
|
|
|
|
xattr: xattr::ENABLED && matches.has(&flags::EXTENDED)?,
|
2017-06-26 07:38:56 +00:00
|
|
|
|
})
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
let other_options_scan = || {
|
2017-08-10 16:54:28 +00:00
|
|
|
|
if let Some(width) = TerminalWidth::deduce(vars)?.width() {
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
if matches.has(&flags::ONE_LINE)? {
|
|
|
|
|
if matches.has(&flags::ACROSS)? {
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Err(Useless(&flags::ACROSS, true, &flags::ONE_LINE))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-06-25 13:59:38 +00:00
|
|
|
|
Ok(Mode::Lines)
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
else if matches.has(&flags::TREE)? {
|
2017-06-25 23:53:48 +00:00
|
|
|
|
let details = details::Options {
|
2017-07-05 20:01:01 +00:00
|
|
|
|
table: None,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
header: false,
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
xattr: xattr::ENABLED && matches.has(&flags::EXTENDED)?,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
};
|
|
|
|
|
|
2017-06-25 13:59:38 +00:00
|
|
|
|
Ok(Mode::Details(details))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-06-25 23:53:48 +00:00
|
|
|
|
let grid = grid::Options {
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
across: matches.has(&flags::ACROSS)?,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
console_width: width,
|
|
|
|
|
};
|
|
|
|
|
|
2017-06-25 13:59:38 +00:00
|
|
|
|
Ok(Mode::Grid(grid))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
// If the terminal width couldn’t be matched for some reason, such
|
|
|
|
|
// as the program’s stdout being connected to a file, then
|
|
|
|
|
// fallback to the lines view.
|
|
|
|
|
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
if matches.has(&flags::TREE)? {
|
2017-06-25 23:53:48 +00:00
|
|
|
|
let details = details::Options {
|
2017-07-05 20:01:01 +00:00
|
|
|
|
table: None,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
header: false,
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
xattr: xattr::ENABLED && matches.has(&flags::EXTENDED)?,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
};
|
|
|
|
|
|
2017-06-25 13:59:38 +00:00
|
|
|
|
Ok(Mode::Details(details))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-06-25 13:59:38 +00:00
|
|
|
|
Ok(Mode::Lines)
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
if matches.has(&flags::LONG)? {
|
2017-06-26 07:38:56 +00:00
|
|
|
|
let details = long()?;
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
if matches.has(&flags::GRID)? {
|
2017-08-12 21:51:45 +00:00
|
|
|
|
let other_options_mode = other_options_scan()?;
|
|
|
|
|
if let Mode::Grid(grid) = other_options_mode {
|
2017-08-13 10:14:58 +00:00
|
|
|
|
let row_threshold = RowThreshold::deduce(vars)?;
|
2017-08-12 21:51:45 +00:00
|
|
|
|
return Ok(Mode::GridDetails(grid_details::Options { grid, details, row_threshold }));
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
return Ok(other_options_mode);
|
|
|
|
|
}
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-06-26 07:38:56 +00:00
|
|
|
|
return Ok(Mode::Details(details));
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 20:43:56 +00:00
|
|
|
|
// If --long hasn’t been passed, then check if we need to warn the
|
|
|
|
|
// user about flags that won’t have any effect.
|
|
|
|
|
if matches.is_strict() {
|
|
|
|
|
for option in &[ &flags::BINARY, &flags::BYTES, &flags::INODE, &flags::LINKS,
|
|
|
|
|
&flags::HEADER, &flags::BLOCKS, &flags::TIME, &flags::GROUP ] {
|
|
|
|
|
if matches.has(option)? {
|
|
|
|
|
return Err(Useless(*option, false, &flags::LONG));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if cfg!(feature="git") && matches.has(&flags::GIT)? {
|
|
|
|
|
return Err(Useless(&flags::GIT, false, &flags::LONG));
|
|
|
|
|
}
|
|
|
|
|
else if matches.has(&flags::LEVEL)? && !matches.has(&flags::RECURSE)? && !matches.has(&flags::TREE)? {
|
|
|
|
|
// TODO: I'm not sure if the code even gets this far.
|
|
|
|
|
// There is an identical check in dir_action
|
|
|
|
|
return Err(Useless2(&flags::LEVEL, &flags::RECURSE, &flags::TREE));
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-04-17 19:38:37 +00:00
|
|
|
|
|
|
|
|
|
other_options_scan()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/// The width of the terminal requested by the user.
|
|
|
|
|
#[derive(PartialEq, Debug)]
|
|
|
|
|
enum TerminalWidth {
|
|
|
|
|
|
|
|
|
|
/// The user requested this specific number of columns.
|
|
|
|
|
Set(usize),
|
|
|
|
|
|
|
|
|
|
/// The terminal was found to have this number of columns.
|
|
|
|
|
Terminal(usize),
|
|
|
|
|
|
|
|
|
|
/// The user didn’t request any particular terminal width.
|
|
|
|
|
Unset,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl TerminalWidth {
|
|
|
|
|
|
|
|
|
|
/// Determine a requested terminal width from the command-line arguments.
|
|
|
|
|
///
|
|
|
|
|
/// Returns an error if a requested width doesn’t parse to an integer.
|
2017-08-13 10:14:58 +00:00
|
|
|
|
fn deduce<V: Vars>(vars: &V) -> Result<TerminalWidth, Misfire> {
|
2017-08-26 20:19:06 +00:00
|
|
|
|
use options::vars;
|
|
|
|
|
|
|
|
|
|
if let Some(columns) = vars.get(vars::COLUMNS).and_then(|s| s.into_string().ok()) {
|
2016-04-17 19:38:37 +00:00
|
|
|
|
match columns.parse() {
|
|
|
|
|
Ok(width) => Ok(TerminalWidth::Set(width)),
|
|
|
|
|
Err(e) => Err(Misfire::FailedParse(e)),
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-06-25 13:51:44 +00:00
|
|
|
|
else if let Some(width) = *TERM_WIDTH {
|
2016-04-17 19:38:37 +00:00
|
|
|
|
Ok(TerminalWidth::Terminal(width))
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
Ok(TerminalWidth::Unset)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-25 11:49:22 +00:00
|
|
|
|
fn width(&self) -> Option<usize> {
|
2016-04-17 19:38:37 +00:00
|
|
|
|
match *self {
|
2017-06-25 11:49:22 +00:00
|
|
|
|
TerminalWidth::Set(width) |
|
|
|
|
|
TerminalWidth::Terminal(width) => Some(width),
|
|
|
|
|
TerminalWidth::Unset => None,
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-08-13 10:15:40 +00:00
|
|
|
|
impl RowThreshold {
|
|
|
|
|
|
|
|
|
|
/// Determine whether to use a row threshold based on the given
|
|
|
|
|
/// environment variables.
|
|
|
|
|
fn deduce<V: Vars>(vars: &V) -> Result<RowThreshold, Misfire> {
|
2017-08-26 20:19:06 +00:00
|
|
|
|
use options::vars;
|
|
|
|
|
|
|
|
|
|
if let Some(columns) = vars.get(vars::EXA_GRID_ROWS).and_then(|s| s.into_string().ok()) {
|
2017-08-13 10:15:40 +00:00
|
|
|
|
match columns.parse() {
|
|
|
|
|
Ok(rows) => Ok(RowThreshold::MinimumRows(rows)),
|
|
|
|
|
Err(e) => Err(Misfire::FailedParse(e)),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
Ok(RowThreshold::AlwaysGrid)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-07-05 19:16:04 +00:00
|
|
|
|
impl TableOptions {
|
2017-08-05 18:11:00 +00:00
|
|
|
|
fn deduce(matches: &MatchedFlags) -> Result<Self, Misfire> {
|
2017-08-09 21:25:16 +00:00
|
|
|
|
let env = Environment::load_all();
|
|
|
|
|
let time_format = TimeFormat::deduce(matches)?;
|
|
|
|
|
let size_format = SizeFormat::deduce(matches)?;
|
|
|
|
|
let extra_columns = Columns::deduce(matches)?;
|
|
|
|
|
Ok(TableOptions { env, time_format, size_format, extra_columns })
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
impl Columns {
|
|
|
|
|
fn deduce(matches: &MatchedFlags) -> Result<Self, Misfire> {
|
|
|
|
|
let time_types = TimeTypes::deduce(matches)?;
|
|
|
|
|
let git = cfg!(feature="git") && matches.has(&flags::GIT)?;
|
|
|
|
|
|
|
|
|
|
let blocks = matches.has(&flags::BLOCKS)?;
|
|
|
|
|
let group = matches.has(&flags::GROUP)?;
|
|
|
|
|
let inode = matches.has(&flags::INODE)?;
|
|
|
|
|
let links = matches.has(&flags::LINKS)?;
|
|
|
|
|
|
|
|
|
|
Ok(Columns { time_types, git, blocks, group, inode, links })
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
impl SizeFormat {
|
|
|
|
|
|
|
|
|
|
/// Determine which file size to use in the file size column based on
|
|
|
|
|
/// the user’s options.
|
|
|
|
|
///
|
|
|
|
|
/// The default mode is to use the decimal prefixes, as they are the
|
|
|
|
|
/// most commonly-understood, and don’t involve trying to parse large
|
|
|
|
|
/// strings of digits in your head. Changing the format to anything else
|
|
|
|
|
/// involves the `--binary` or `--bytes` flags, and these conflict with
|
|
|
|
|
/// each other.
|
2017-08-05 18:11:00 +00:00
|
|
|
|
fn deduce(matches: &MatchedFlags) -> Result<SizeFormat, Misfire> {
|
2017-08-09 18:18:31 +00:00
|
|
|
|
let flag = matches.has_where(|f| f.matches(&flags::BINARY) || f.matches(&flags::BYTES))?;
|
|
|
|
|
|
|
|
|
|
Ok(match flag {
|
|
|
|
|
Some(f) if f.matches(&flags::BINARY) => SizeFormat::BinaryBytes,
|
|
|
|
|
Some(f) if f.matches(&flags::BYTES) => SizeFormat::JustBytes,
|
|
|
|
|
_ => SizeFormat::DecimalBytes,
|
|
|
|
|
})
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-07-05 22:27:48 +00:00
|
|
|
|
impl TimeFormat {
|
|
|
|
|
|
|
|
|
|
/// Determine how time should be formatted in timestamp columns.
|
2017-08-05 18:11:00 +00:00
|
|
|
|
fn deduce(matches: &MatchedFlags) -> Result<TimeFormat, Misfire> {
|
2017-07-05 23:39:54 +00:00
|
|
|
|
pub use output::time::{DefaultFormat, ISOFormat};
|
2017-07-05 23:01:45 +00:00
|
|
|
|
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
let word = match matches.get(&flags::TIME_STYLE)? {
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Some(w) => w,
|
|
|
|
|
None => return Ok(TimeFormat::DefaultFormat(DefaultFormat::new())),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if word == "default" {
|
|
|
|
|
Ok(TimeFormat::DefaultFormat(DefaultFormat::new()))
|
|
|
|
|
}
|
|
|
|
|
else if word == "iso" {
|
|
|
|
|
Ok(TimeFormat::ISOFormat(ISOFormat::new()))
|
|
|
|
|
}
|
|
|
|
|
else if word == "long-iso" {
|
|
|
|
|
Ok(TimeFormat::LongISO)
|
|
|
|
|
}
|
|
|
|
|
else if word == "full-iso" {
|
|
|
|
|
Ok(TimeFormat::FullISO)
|
2017-07-05 23:01:45 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
2017-09-14 00:22:37 +00:00
|
|
|
|
Err(Misfire::BadArgument(&flags::TIME_STYLE, word.into()))
|
2017-07-05 23:01:45 +00:00
|
|
|
|
}
|
2017-07-05 22:27:48 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2016-04-17 19:38:37 +00:00
|
|
|
|
impl TimeTypes {
|
|
|
|
|
|
|
|
|
|
/// Determine which of a file’s time fields should be displayed for it
|
|
|
|
|
/// based on the user’s options.
|
|
|
|
|
///
|
|
|
|
|
/// There are two separate ways to pick which fields to show: with a
|
|
|
|
|
/// flag (such as `--modified`) or with a parameter (such as
|
|
|
|
|
/// `--time=modified`). An error is signaled if both ways are used.
|
|
|
|
|
///
|
|
|
|
|
/// It’s valid to show more than one column by passing in more than one
|
|
|
|
|
/// option, but passing *no* options means that the user just wants to
|
|
|
|
|
/// see the default set.
|
2017-08-05 18:11:00 +00:00
|
|
|
|
fn deduce(matches: &MatchedFlags) -> Result<TimeTypes, Misfire> {
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
let possible_word = matches.get(&flags::TIME)?;
|
|
|
|
|
let modified = matches.has(&flags::MODIFIED)?;
|
|
|
|
|
let created = matches.has(&flags::CREATED)?;
|
|
|
|
|
let accessed = matches.has(&flags::ACCESSED)?;
|
2016-04-17 19:38:37 +00:00
|
|
|
|
|
|
|
|
|
if let Some(word) = possible_word {
|
|
|
|
|
if modified {
|
2017-08-05 10:55:41 +00:00
|
|
|
|
Err(Misfire::Useless(&flags::MODIFIED, true, &flags::TIME))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else if created {
|
2017-08-05 10:55:41 +00:00
|
|
|
|
Err(Misfire::Useless(&flags::CREATED, true, &flags::TIME))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else if accessed {
|
2017-08-05 10:55:41 +00:00
|
|
|
|
Err(Misfire::Useless(&flags::ACCESSED, true, &flags::TIME))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
2017-08-05 10:55:41 +00:00
|
|
|
|
else if word == "mod" || word == "modified" {
|
2017-07-26 16:48:18 +00:00
|
|
|
|
Ok(TimeTypes { accessed: false, modified: true, created: false })
|
|
|
|
|
}
|
|
|
|
|
else if word == "acc" || word == "accessed" {
|
|
|
|
|
Ok(TimeTypes { accessed: true, modified: false, created: false })
|
|
|
|
|
}
|
|
|
|
|
else if word == "cr" || word == "created" {
|
|
|
|
|
Ok(TimeTypes { accessed: false, modified: false, created: true })
|
|
|
|
|
}
|
|
|
|
|
else {
|
2017-09-14 00:22:37 +00:00
|
|
|
|
Err(Misfire::BadArgument(&flags::TIME, word.into()))
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else if modified || created || accessed {
|
2017-05-18 21:43:32 +00:00
|
|
|
|
Ok(TimeTypes { accessed, modified, created })
|
2016-04-17 19:38:37 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
Ok(TimeTypes::default())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-06-25 13:51:44 +00:00
|
|
|
|
// Gets, then caches, the width of the terminal that exa is running in.
|
|
|
|
|
// This gets used multiple times above, with no real guarantee of order,
|
|
|
|
|
// so it’s easier to just cache it the first time it runs.
|
|
|
|
|
lazy_static! {
|
|
|
|
|
static ref TERM_WIDTH: Option<usize> = {
|
2017-08-05 19:26:13 +00:00
|
|
|
|
// All of stdin, stdout, and stderr could not be connected to a
|
|
|
|
|
// terminal, but we’re only interested in stdout because it’s
|
|
|
|
|
// where the output goes.
|
|
|
|
|
use term_size::dimensions_stdout;
|
|
|
|
|
dimensions_stdout().map(|t| t.0)
|
2017-06-25 13:51:44 +00:00
|
|
|
|
};
|
|
|
|
|
}
|
2017-07-26 22:05:45 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
|
mod test {
|
|
|
|
|
use super::*;
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
use std::ffi::OsString;
|
2017-07-26 22:05:45 +00:00
|
|
|
|
use options::flags;
|
2017-08-09 16:14:16 +00:00
|
|
|
|
use options::parser::{Flag, Arg};
|
|
|
|
|
|
|
|
|
|
use options::test::parse_for_test;
|
|
|
|
|
use options::test::Strictnesses::*;
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
|
2017-08-09 16:14:16 +00:00
|
|
|
|
static TEST_ARGS: &[&Arg] = &[ &flags::BINARY, &flags::BYTES, &flags::TIME_STYLE,
|
|
|
|
|
&flags::TIME, &flags::MODIFIED, &flags::CREATED, &flags::ACCESSED,
|
2017-08-11 20:43:56 +00:00
|
|
|
|
&flags::HEADER, &flags::GROUP, &flags::INODE, &flags::GIT,
|
|
|
|
|
&flags::LINKS, &flags::BLOCKS, &flags::LONG, &flags::LEVEL,
|
2017-08-10 16:54:28 +00:00
|
|
|
|
&flags::GRID, &flags::ACROSS, &flags::ONE_LINE ];
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
2017-07-26 22:05:45 +00:00
|
|
|
|
macro_rules! test {
|
2017-08-10 12:52:49 +00:00
|
|
|
|
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
($name:ident: $type:ident <- $inputs:expr; $stricts:expr => $result:expr) => {
|
2017-08-10 12:52:49 +00:00
|
|
|
|
/// Macro that writes a test.
|
|
|
|
|
/// If testing both strictnesses, they’ll both be done in the same function.
|
2017-07-26 22:05:45 +00:00
|
|
|
|
#[test]
|
|
|
|
|
fn $name() {
|
2017-08-09 12:36:06 +00:00
|
|
|
|
for result in parse_for_test($inputs.as_ref(), TEST_ARGS, $stricts, |mf| $type::deduce(mf)) {
|
|
|
|
|
assert_eq!(result, $result);
|
|
|
|
|
}
|
2017-07-26 22:05:45 +00:00
|
|
|
|
}
|
|
|
|
|
};
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
2017-08-10 12:52:49 +00:00
|
|
|
|
($name:ident: $type:ident <- $inputs:expr; $stricts:expr => err $result:expr) => {
|
|
|
|
|
/// Special macro for testing Err results.
|
|
|
|
|
/// This is needed because sometimes the Ok type doesn’t implement PartialEq.
|
|
|
|
|
#[test]
|
|
|
|
|
fn $name() {
|
|
|
|
|
for result in parse_for_test($inputs.as_ref(), TEST_ARGS, $stricts, |mf| $type::deduce(mf)) {
|
|
|
|
|
assert_eq!(result.unwrap_err(), $result);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-09 16:14:16 +00:00
|
|
|
|
($name:ident: $type:ident <- $inputs:expr; $stricts:expr => like $pat:pat) => {
|
2017-08-10 12:52:49 +00:00
|
|
|
|
/// More general macro for testing against a pattern.
|
|
|
|
|
/// Instead of using PartialEq, this just tests if it matches a pat.
|
2017-08-09 16:14:16 +00:00
|
|
|
|
#[test]
|
|
|
|
|
fn $name() {
|
|
|
|
|
for result in parse_for_test($inputs.as_ref(), TEST_ARGS, $stricts, |mf| $type::deduce(mf)) {
|
|
|
|
|
println!("Testing {:?}", result);
|
|
|
|
|
match result {
|
|
|
|
|
$pat => assert!(true),
|
|
|
|
|
_ => assert!(false),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
2017-08-10 16:54:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
($name:ident: $type:ident <- $inputs:expr, $vars:expr; $stricts:expr => err $result:expr) => {
|
|
|
|
|
/// Like above, but with $vars.
|
|
|
|
|
#[test]
|
|
|
|
|
fn $name() {
|
2017-08-13 10:14:58 +00:00
|
|
|
|
for result in parse_for_test($inputs.as_ref(), TEST_ARGS, $stricts, |mf| $type::deduce(mf, &$vars)) {
|
2017-08-10 16:54:28 +00:00
|
|
|
|
assert_eq!(result.unwrap_err(), $result);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
($name:ident: $type:ident <- $inputs:expr, $vars:expr; $stricts:expr => like $pat:pat) => {
|
|
|
|
|
/// Like further above, but with $vars.
|
|
|
|
|
#[test]
|
|
|
|
|
fn $name() {
|
2017-08-13 10:14:58 +00:00
|
|
|
|
for result in parse_for_test($inputs.as_ref(), TEST_ARGS, $stricts, |mf| $type::deduce(mf, &$vars)) {
|
2017-08-10 16:54:28 +00:00
|
|
|
|
println!("Testing {:?}", result);
|
|
|
|
|
match result {
|
|
|
|
|
$pat => assert!(true),
|
|
|
|
|
_ => assert!(false),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
2017-07-26 22:05:45 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-07-26 22:37:58 +00:00
|
|
|
|
|
2017-07-26 22:05:45 +00:00
|
|
|
|
mod size_formats {
|
|
|
|
|
use super::*;
|
|
|
|
|
|
2017-08-09 16:14:16 +00:00
|
|
|
|
// Default behaviour
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(empty: SizeFormat <- []; Both => Ok(SizeFormat::DecimalBytes));
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
|
|
|
|
// Individual flags
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(binary: SizeFormat <- ["--binary"]; Both => Ok(SizeFormat::BinaryBytes));
|
|
|
|
|
test!(bytes: SizeFormat <- ["--bytes"]; Both => Ok(SizeFormat::JustBytes));
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
2017-08-09 18:18:31 +00:00
|
|
|
|
// Overriding
|
|
|
|
|
test!(both_1: SizeFormat <- ["--binary", "--binary"]; Last => Ok(SizeFormat::BinaryBytes));
|
|
|
|
|
test!(both_2: SizeFormat <- ["--bytes", "--binary"]; Last => Ok(SizeFormat::BinaryBytes));
|
|
|
|
|
test!(both_3: SizeFormat <- ["--binary", "--bytes"]; Last => Ok(SizeFormat::JustBytes));
|
|
|
|
|
test!(both_4: SizeFormat <- ["--bytes", "--bytes"]; Last => Ok(SizeFormat::JustBytes));
|
|
|
|
|
|
2017-08-10 12:52:49 +00:00
|
|
|
|
test!(both_5: SizeFormat <- ["--binary", "--binary"]; Complain => err Misfire::Duplicate(Flag::Long("binary"), Flag::Long("binary")));
|
|
|
|
|
test!(both_6: SizeFormat <- ["--bytes", "--binary"]; Complain => err Misfire::Duplicate(Flag::Long("bytes"), Flag::Long("binary")));
|
|
|
|
|
test!(both_7: SizeFormat <- ["--binary", "--bytes"]; Complain => err Misfire::Duplicate(Flag::Long("binary"), Flag::Long("bytes")));
|
|
|
|
|
test!(both_8: SizeFormat <- ["--bytes", "--bytes"]; Complain => err Misfire::Duplicate(Flag::Long("bytes"), Flag::Long("bytes")));
|
2017-07-26 22:05:45 +00:00
|
|
|
|
}
|
2017-07-26 22:37:58 +00:00
|
|
|
|
|
|
|
|
|
|
2017-08-09 16:14:16 +00:00
|
|
|
|
mod time_formats {
|
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
|
|
// These tests use pattern matching because TimeFormat doesn’t
|
|
|
|
|
// implement PartialEq.
|
|
|
|
|
|
|
|
|
|
// Default behaviour
|
|
|
|
|
test!(empty: TimeFormat <- []; Both => like Ok(TimeFormat::DefaultFormat(_)));
|
|
|
|
|
|
|
|
|
|
// Individual settings
|
|
|
|
|
test!(default: TimeFormat <- ["--time-style=default"]; Both => like Ok(TimeFormat::DefaultFormat(_)));
|
|
|
|
|
test!(iso: TimeFormat <- ["--time-style", "iso"]; Both => like Ok(TimeFormat::ISOFormat(_)));
|
|
|
|
|
test!(long_iso: TimeFormat <- ["--time-style=long-iso"]; Both => like Ok(TimeFormat::LongISO));
|
|
|
|
|
test!(full_iso: TimeFormat <- ["--time-style", "full-iso"]; Both => like Ok(TimeFormat::FullISO));
|
|
|
|
|
|
|
|
|
|
// Overriding
|
|
|
|
|
test!(actually: TimeFormat <- ["--time-style=default", "--time-style", "iso"]; Last => like Ok(TimeFormat::ISOFormat(_)));
|
2017-08-10 12:52:49 +00:00
|
|
|
|
test!(actual_2: TimeFormat <- ["--time-style=default", "--time-style", "iso"]; Complain => err Misfire::Duplicate(Flag::Long("time-style"), Flag::Long("time-style")));
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
|
|
|
|
test!(nevermind: TimeFormat <- ["--time-style", "long-iso", "--time-style=full-iso"]; Last => like Ok(TimeFormat::FullISO));
|
2017-08-10 12:52:49 +00:00
|
|
|
|
test!(nevermore: TimeFormat <- ["--time-style", "long-iso", "--time-style=full-iso"]; Complain => err Misfire::Duplicate(Flag::Long("time-style"), Flag::Long("time-style")));
|
2017-08-09 16:14:16 +00:00
|
|
|
|
|
|
|
|
|
// Errors
|
2017-09-14 00:22:37 +00:00
|
|
|
|
test!(daily: TimeFormat <- ["--time-style=24-hour"]; Both => err Misfire::BadArgument(&flags::TIME_STYLE, OsString::from("24-hour")));
|
2017-08-09 16:14:16 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-07-26 22:37:58 +00:00
|
|
|
|
mod time_types {
|
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
|
|
// Default behaviour
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(empty: TimeTypes <- []; Both => Ok(TimeTypes::default()));
|
2017-08-09 12:36:06 +00:00
|
|
|
|
|
|
|
|
|
// Modified
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(modified: TimeTypes <- ["--modified"]; Both => Ok(TimeTypes { accessed: false, modified: true, created: false }));
|
|
|
|
|
test!(m: TimeTypes <- ["-m"]; Both => Ok(TimeTypes { accessed: false, modified: true, created: false }));
|
|
|
|
|
test!(time_mod: TimeTypes <- ["--time=modified"]; Both => Ok(TimeTypes { accessed: false, modified: true, created: false }));
|
|
|
|
|
test!(time_m: TimeTypes <- ["-tmod"]; Both => Ok(TimeTypes { accessed: false, modified: true, created: false }));
|
|
|
|
|
|
2017-08-09 12:36:06 +00:00
|
|
|
|
// Accessed
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(acc: TimeTypes <- ["--accessed"]; Both => Ok(TimeTypes { accessed: true, modified: false, created: false }));
|
|
|
|
|
test!(a: TimeTypes <- ["-u"]; Both => Ok(TimeTypes { accessed: true, modified: false, created: false }));
|
|
|
|
|
test!(time_acc: TimeTypes <- ["--time", "accessed"]; Both => Ok(TimeTypes { accessed: true, modified: false, created: false }));
|
|
|
|
|
test!(time_a: TimeTypes <- ["-t", "acc"]; Both => Ok(TimeTypes { accessed: true, modified: false, created: false }));
|
|
|
|
|
|
2017-08-09 12:36:06 +00:00
|
|
|
|
// Created
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(cr: TimeTypes <- ["--created"]; Both => Ok(TimeTypes { accessed: false, modified: false, created: true }));
|
|
|
|
|
test!(c: TimeTypes <- ["-U"]; Both => Ok(TimeTypes { accessed: false, modified: false, created: true }));
|
|
|
|
|
test!(time_cr: TimeTypes <- ["--time=created"]; Both => Ok(TimeTypes { accessed: false, modified: false, created: true }));
|
|
|
|
|
test!(time_c: TimeTypes <- ["-tcr"]; Both => Ok(TimeTypes { accessed: false, modified: false, created: true }));
|
2017-07-26 22:37:58 +00:00
|
|
|
|
|
|
|
|
|
// Multiples
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(time_uu: TimeTypes <- ["-uU"]; Both => Ok(TimeTypes { accessed: true, modified: false, created: true }));
|
|
|
|
|
|
|
|
|
|
// Errors
|
2017-09-14 00:22:37 +00:00
|
|
|
|
test!(time_tea: TimeTypes <- ["--time=tea"]; Both => err Misfire::BadArgument(&flags::TIME, OsString::from("tea")));
|
|
|
|
|
test!(time_ea: TimeTypes <- ["-tea"]; Both => err Misfire::BadArgument(&flags::TIME, OsString::from("ea")));
|
2017-07-26 22:37:58 +00:00
|
|
|
|
|
|
|
|
|
// Overriding
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
test!(overridden: TimeTypes <- ["-tcr", "-tmod"]; Last => Ok(TimeTypes { accessed: false, modified: true, created: false }));
|
2017-08-10 12:52:49 +00:00
|
|
|
|
test!(overridden_2: TimeTypes <- ["-tcr", "-tmod"]; Complain => err Misfire::Duplicate(Flag::Short(b't'), Flag::Short(b't')));
|
Be stricter in strict mode
Now the code actually starts to use the Strictness flag that was added in the earlier commit! Well, the *code* doesn’t, but the tests do: the macros that create the test cases now have a parameter for which tests they should run. It’s usually ‘Both’ for both strict mode and default mode, but can be specified to only run in one, for when the results differ (usually when options override one another)
The downside to strict mode is that, now, *any* call to `matches.has` or `matches.get` could fail, because an option could have been specified twice, and this is the place where those are checked for. This makes the code a little less ergonomic in places, but that’s what the ? operator is for. The only place this has really had an effect is in `Classify::deduce`, which used to just return a boolean but can now fail.
In order to more thoroughly test the mode, some of the older parts of the code can now act more strict. For example, `TerminalColours::deduce` will now use the last-given option rather than searching for “colours” before “colors”.
Help and Version continue doing their own thing.
2017-08-09 08:21:29 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-08-10 12:59:39 +00:00
|
|
|
|
mod views {
|
|
|
|
|
use super::*;
|
2017-08-10 16:54:28 +00:00
|
|
|
|
use output::grid::Options as GridOptions;
|
2017-08-10 12:59:39 +00:00
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
// Default
|
|
|
|
|
test!(empty: Mode <- [], None; Both => like Ok(Mode::Grid(_)));
|
|
|
|
|
|
|
|
|
|
// Grid views
|
|
|
|
|
test!(original_g: Mode <- ["-G"], None; Both => like Ok(Mode::Grid(GridOptions { across: false, console_width: _ })));
|
|
|
|
|
test!(grid: Mode <- ["--grid"], None; Both => like Ok(Mode::Grid(GridOptions { across: false, console_width: _ })));
|
|
|
|
|
test!(across: Mode <- ["--across"], None; Both => like Ok(Mode::Grid(GridOptions { across: true, console_width: _ })));
|
|
|
|
|
test!(gracross: Mode <- ["-xG"], None; Both => like Ok(Mode::Grid(GridOptions { across: true, console_width: _ })));
|
|
|
|
|
|
|
|
|
|
// Lines views
|
|
|
|
|
test!(lines: Mode <- ["--oneline"], None; Both => like Ok(Mode::Lines));
|
|
|
|
|
test!(prima: Mode <- ["-1"], None; Both => like Ok(Mode::Lines));
|
|
|
|
|
|
|
|
|
|
// Details views
|
|
|
|
|
test!(long: Mode <- ["--long"], None; Both => like Ok(Mode::Details(_)));
|
|
|
|
|
test!(ell: Mode <- ["-l"], None; Both => like Ok(Mode::Details(_)));
|
|
|
|
|
|
|
|
|
|
// Grid-details views
|
2017-08-12 21:49:16 +00:00
|
|
|
|
test!(lid: Mode <- ["--long", "--grid"], None; Both => like Ok(Mode::GridDetails(_)));
|
|
|
|
|
test!(leg: Mode <- ["-lG"], None; Both => like Ok(Mode::GridDetails(_)));
|
2017-08-10 16:54:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Options that do nothing without --long
|
|
|
|
|
test!(just_header: Mode <- ["--header"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_group: Mode <- ["--group"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_inode: Mode <- ["--inode"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_links: Mode <- ["--links"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_blocks: Mode <- ["--blocks"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_binary: Mode <- ["--binary"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
test!(just_bytes: Mode <- ["--bytes"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
|
2017-08-11 20:43:56 +00:00
|
|
|
|
#[cfg(feature="git")]
|
|
|
|
|
test!(just_git: Mode <- ["--git"], None; Last => like Ok(Mode::Grid(_)));
|
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
test!(just_header_2: Mode <- ["--header"], None; Complain => err Misfire::Useless(&flags::HEADER, false, &flags::LONG));
|
|
|
|
|
test!(just_group_2: Mode <- ["--group"], None; Complain => err Misfire::Useless(&flags::GROUP, false, &flags::LONG));
|
|
|
|
|
test!(just_inode_2: Mode <- ["--inode"], None; Complain => err Misfire::Useless(&flags::INODE, false, &flags::LONG));
|
|
|
|
|
test!(just_links_2: Mode <- ["--links"], None; Complain => err Misfire::Useless(&flags::LINKS, false, &flags::LONG));
|
|
|
|
|
test!(just_blocks_2: Mode <- ["--blocks"], None; Complain => err Misfire::Useless(&flags::BLOCKS, false, &flags::LONG));
|
|
|
|
|
test!(just_binary_2: Mode <- ["--binary"], None; Complain => err Misfire::Useless(&flags::BINARY, false, &flags::LONG));
|
|
|
|
|
test!(just_bytes_2: Mode <- ["--bytes"], None; Complain => err Misfire::Useless(&flags::BYTES, false, &flags::LONG));
|
2017-08-11 20:43:56 +00:00
|
|
|
|
|
|
|
|
|
#[cfg(feature="git")]
|
|
|
|
|
test!(just_git_2: Mode <- ["--git"], None; Complain => err Misfire::Useless(&flags::GIT, false, &flags::LONG));
|
2017-08-10 12:59:39 +00:00
|
|
|
|
}
|
2017-07-26 22:05:45 +00:00
|
|
|
|
}
|