2016-04-17 19:38:37 +00:00
use std ::env ::var_os ;
use output ::Colours ;
2017-07-24 07:34:50 +00:00
use output ::{ View , Mode , grid , details } ;
2017-07-05 20:01:01 +00:00
use output ::table ::{ TimeTypes , Environment , SizeFormat , Options as TableOptions } ;
2017-07-08 11:11:11 +00:00
use output ::file_name ::{ Classify , FileStyle } ;
2017-07-05 23:01:45 +00:00
use output ::time ::TimeFormat ;
2017-07-26 16:48:18 +00:00
use options ::{ flags , Misfire } ;
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-07-26 16:48:18 +00:00
use info ::filetype ::FileExtensions ;
2016-04-17 19:38:37 +00:00
2017-06-24 21:39:15 +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-05 18:11:00 +00:00
pub fn deduce ( matches : & MatchedFlags ) -> Result < View , Misfire > {
2017-07-08 11:11:11 +00:00
let mode = Mode ::deduce ( matches ) ? ;
let colours = Colours ::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
let style = FileStyle ::deduce ( matches ) ? ;
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-05 18:11:00 +00:00
pub fn deduce ( matches : & MatchedFlags ) -> 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 long_options_scan = | | {
2017-07-26 16:48:18 +00:00
for option in & [ & flags ::BINARY , & flags ::BYTES , & flags ::INODE , & flags ::LINKS ,
& flags ::HEADER , & flags ::BLOCKS , & flags ::TIME , & flags ::GROUP ] {
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 ( option ) ? {
2017-07-26 16:48:18 +00:00
return Err ( Useless ( * option , false , & 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
if cfg! ( feature = " git " ) & & matches . has ( & flags ::GIT ) ? {
2017-07-26 16:48:18 +00:00
Err ( Useless ( & flags ::GIT , false , & 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 ::LEVEL ) ? & & ! matches . has ( & flags ::RECURSE ) ? & & ! matches . has ( & flags ::TREE ) ? {
2017-07-26 16:48:18 +00:00
Err ( Useless2 ( & flags ::LEVEL , & flags ::RECURSE , & flags ::TREE ) )
2016-04-17 19:38:37 +00:00
}
else {
Ok ( ( ) )
}
} ;
let other_options_scan = | | {
2017-06-25 13:51:44 +00:00
if let Some ( width ) = TerminalWidth ::deduce ( ) ? . 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-06-26 07:38:56 +00:00
match other_options_scan ( ) ? {
Mode ::Grid ( grid ) = > return Ok ( Mode ::GridDetails ( grid , details ) ) ,
others = > return Ok ( others ) ,
} ;
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-03-26 16:35:50 +00:00
long_options_scan ( ) ? ;
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.
2016-04-17 20:01:30 +00:00
fn deduce ( ) -> Result < TerminalWidth , Misfire > {
2016-04-17 19:38:37 +00:00
if let Some ( columns ) = var_os ( " COLUMNS " ) . and_then ( | s | s . into_string ( ) . ok ( ) ) {
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-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-07-05 19:16:04 +00:00
Ok ( TableOptions {
2017-07-05 20:01:01 +00:00
env : Environment ::load_all ( ) ,
2017-07-05 22:27:48 +00:00
time_format : TimeFormat ::deduce ( matches ) ? ,
2017-03-26 16:35:50 +00:00
size_format : SizeFormat ::deduce ( matches ) ? ,
time_types : TimeTypes ::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
inode : matches . has ( & flags ::INODE ) ? ,
links : matches . has ( & flags ::LINKS ) ? ,
blocks : matches . has ( & flags ::BLOCKS ) ? ,
group : matches . has ( & flags ::GROUP ) ? ,
git : cfg ! ( feature = " git " ) & & matches . has ( & flags ::GIT ) ? ,
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 > {
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 binary = matches . has ( & flags ::BINARY ) ? ;
let bytes = matches . has ( & flags ::BYTES ) ? ;
2016-04-17 19:38:37 +00:00
match ( binary , bytes ) {
2017-07-26 16:48:18 +00:00
( true , true ) = > Err ( Misfire ::Conflict ( & flags ::BINARY , & flags ::BYTES ) ) ,
2016-04-17 19:38:37 +00:00
( true , false ) = > Ok ( SizeFormat ::BinaryBytes ) ,
( false , true ) = > Ok ( SizeFormat ::JustBytes ) ,
( false , false ) = > Ok ( SizeFormat ::DecimalBytes ) ,
}
}
}
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 } ;
const STYLES : & [ & str ] = & [ " default " , " long-iso " , " full-iso " , " iso " ] ;
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-07-26 16:48:18 +00:00
Err ( Misfire ::bad_argument ( & flags ::TIME_STYLE , word , STYLES ) )
2017-07-05 23:01:45 +00:00
}
2017-07-05 22:27:48 +00:00
}
}
2017-07-26 22:37:58 +00:00
static TIMES : & [ & str ] = & [ " modified " , " accessed " , " created " ] ;
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 {
Err ( Misfire ::bad_argument ( & flags ::TIME , word , TIMES ) )
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 ( ) )
}
}
}
/// Under what circumstances we should display coloured, rather than plain,
/// output to the terminal.
///
/// By default, we want to display the colours when stdout can display them.
/// Turning them on when output is going to, say, a pipe, would make programs
/// such as `grep` or `more` not work properly. So the `Automatic` mode does
/// this check and only displays colours when they can be truly appreciated.
#[ derive(PartialEq, Debug) ]
enum TerminalColours {
/// Display them even when output isn’ t going to a terminal.
Always ,
/// Display them when output is going to a terminal, but not otherwise.
Automatic ,
/// Never display them, even when output is going to a terminal.
Never ,
}
impl Default for TerminalColours {
fn default ( ) -> TerminalColours {
TerminalColours ::Automatic
}
}
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
const COLOURS : & [ & str ] = & [ " always " , " auto " , " never " ] ;
2016-04-17 19:38:37 +00:00
impl TerminalColours {
/// Determine which terminal colour conditions to use.
2017-08-05 18:11:00 +00:00
fn deduce ( matches : & MatchedFlags ) -> Result < TerminalColours , Misfire > {
2017-06-23 21:58:07 +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_where ( | f | f . matches ( & flags ::COLOR ) | | f . matches ( & flags ::COLOUR ) ) ? {
2017-07-26 16:48:18 +00:00
Some ( w ) = > w ,
None = > return Ok ( TerminalColours ::default ( ) ) ,
} ;
if word = = " always " {
Ok ( TerminalColours ::Always )
}
else if word = = " auto " | | word = = " automatic " {
Ok ( TerminalColours ::Automatic )
}
else if word = = " never " {
Ok ( TerminalColours ::Never )
2016-04-17 19:38:37 +00:00
}
else {
2017-07-26 16:48:18 +00:00
Err ( Misfire ::bad_argument ( & flags ::COLOR , word , COLOURS ) )
2016-04-17 19:38:37 +00:00
}
}
}
2017-05-07 14:31:00 +00:00
2017-06-25 13:51:44 +00:00
impl Colours {
2017-08-05 18:11:00 +00:00
fn deduce ( matches : & MatchedFlags ) -> Result < Colours , Misfire > {
2017-06-25 13:51:44 +00:00
use self ::TerminalColours ::* ;
let tc = TerminalColours ::deduce ( matches ) ? ;
if tc = = Always | | ( tc = = Automatic & & TERM_WIDTH . is_some ( ) ) {
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 scale = matches . has ( & flags ::COLOR_SCALE ) ? | | matches . has ( & flags ::COLOUR_SCALE ) ? ;
2017-06-25 13:51:44 +00:00
Ok ( Colours ::colourful ( scale ) )
}
else {
Ok ( Colours ::plain ( ) )
}
}
}
2017-05-07 14:31:00 +00:00
2017-07-08 11:11:11 +00:00
impl FileStyle {
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
fn deduce ( matches : & MatchedFlags ) -> Result < FileStyle , Misfire > {
let classify = Classify ::deduce ( matches ) ? ;
2017-07-10 13:01:38 +00:00
let exts = FileExtensions ;
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
Ok ( FileStyle { classify , exts } )
2017-07-08 11:11:11 +00:00
}
}
2017-05-07 14:31:00 +00:00
impl Classify {
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
fn deduce ( matches : & MatchedFlags ) -> Result < Classify , Misfire > {
let flagged = matches . has ( & flags ::CLASSIFY ) ? ;
Ok ( if flagged { Classify ::AddFileIndicators }
else { Classify ::JustFilenames } )
2017-05-07 14:31:00 +00:00
}
}
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 ;
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 options ::parser ::Flag ;
pub fn os ( input : & 'static str ) -> OsString {
let mut os = OsString ::new ( ) ;
os . push ( input ) ;
os
}
2017-07-26 22:05:45 +00:00
macro_rules ! test {
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-07-26 22:05:45 +00:00
#[ test ]
fn $name ( ) {
2017-08-08 08:18:17 +00:00
use options ::parser ::Arg ;
use options ::test ::assert_parses ;
use options ::test ::Strictnesses ::* ;
2017-07-26 22:05:45 +00:00
2017-07-26 22:37:58 +00:00
static TEST_ARGS : & [ & Arg ] = & [ & flags ::BINARY , & flags ::BYTES ,
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
& flags ::TIME , & flags ::MODIFIED , & flags ::CREATED , & flags ::ACCESSED ,
& flags ::COLOR , & flags ::COLOUR ] ;
2017-07-26 22:05: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
assert_parses ( $inputs . as_ref ( ) , TEST_ARGS , $stricts , | mf | $type ::deduce ( mf ) , $result )
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 ::* ;
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 ) ) ;
test! ( binary : SizeFormat < - [ " --binary " ] ; Both = > Ok ( SizeFormat ::BinaryBytes ) ) ;
test! ( bytes : SizeFormat < - [ " --bytes " ] ; Both = > Ok ( SizeFormat ::JustBytes ) ) ;
test! ( both : SizeFormat < - [ " --binary " , " --bytes " ] ; Both = > Err ( Misfire ::Conflict ( & flags ::BINARY , & flags ::BYTES ) ) ) ;
2017-07-26 22:05:45 +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 ( ) ) ) ;
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 } ) ) ;
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 } ) ) ;
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
test! ( time_tea : TimeTypes < - [ " --time=tea " ] ; Both = > Err ( Misfire ::bad_argument ( & flags ::TIME , & os ( " tea " ) , super ::TIMES ) ) ) ;
test! ( time_ea : TimeTypes < - [ " -tea " ] ; Both = > Err ( Misfire ::bad_argument ( & flags ::TIME , & os ( " ea " ) , super ::TIMES ) ) ) ;
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 } ) ) ;
test! ( overridden_2 : TimeTypes < - [ " -tcr " , " -tmod " ] ; Complain = > Err ( Misfire ::Duplicate ( Flag ::Short ( b 't' ) , Flag ::Short ( b 't' ) ) ) ) ;
}
mod colourses {
use super ::* ;
// Default
test! ( empty : TerminalColours < - [ ] ; Both = > Ok ( TerminalColours ::default ( ) ) ) ;
// --colour
test! ( u_always : TerminalColours < - [ " --colour=always " ] ; Both = > Ok ( TerminalColours ::Always ) ) ;
test! ( u_auto : TerminalColours < - [ " --colour " , " auto " ] ; Both = > Ok ( TerminalColours ::Automatic ) ) ;
test! ( u_never : TerminalColours < - [ " --colour=never " ] ; Both = > Ok ( TerminalColours ::Never ) ) ;
// --color
test! ( no_u_always : TerminalColours < - [ " --color " , " always " ] ; Both = > Ok ( TerminalColours ::Always ) ) ;
test! ( no_u_auto : TerminalColours < - [ " --color=auto " ] ; Both = > Ok ( TerminalColours ::Automatic ) ) ;
test! ( no_u_never : TerminalColours < - [ " --color " , " never " ] ; Both = > Ok ( TerminalColours ::Never ) ) ;
2017-07-26 22:37:58 +00:00
// Errors
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! ( no_u_error : TerminalColours < - [ " --color=upstream " ] ; Both = > Err ( Misfire ::bad_argument ( & flags ::COLOR , & os ( " upstream " ) , super ::COLOURS ) ) ) ; // the error is for --color
test! ( u_error : TerminalColours < - [ " --colour=lovers " ] ; Both = > Err ( Misfire ::bad_argument ( & flags ::COLOR , & os ( " lovers " ) , super ::COLOURS ) ) ) ; // and so is this one!
// Overriding
test! ( overridden_1 : TerminalColours < - [ " --colour=auto " , " --colour=never " ] ; Last = > Ok ( TerminalColours ::Never ) ) ;
test! ( overridden_2 : TerminalColours < - [ " --color=auto " , " --colour=never " ] ; Last = > Ok ( TerminalColours ::Never ) ) ;
test! ( overridden_3 : TerminalColours < - [ " --colour=auto " , " --color=never " ] ; Last = > Ok ( TerminalColours ::Never ) ) ;
test! ( overridden_4 : TerminalColours < - [ " --color=auto " , " --color=never " ] ; Last = > Ok ( TerminalColours ::Never ) ) ;
test! ( overridden_5 : TerminalColours < - [ " --colour=auto " , " --colour=never " ] ; Complain = > Err ( Misfire ::Duplicate ( Flag ::Long ( " colour " ) , Flag ::Long ( " colour " ) ) ) ) ;
test! ( overridden_6 : TerminalColours < - [ " --color=auto " , " --colour=never " ] ; Complain = > Err ( Misfire ::Duplicate ( Flag ::Long ( " color " ) , Flag ::Long ( " colour " ) ) ) ) ;
test! ( overridden_7 : TerminalColours < - [ " --colour=auto " , " --color=never " ] ; Complain = > Err ( Misfire ::Duplicate ( Flag ::Long ( " colour " ) , Flag ::Long ( " color " ) ) ) ) ;
test! ( overridden_8 : TerminalColours < - [ " --color=auto " , " --color=never " ] ; Complain = > Err ( Misfire ::Duplicate ( Flag ::Long ( " color " ) , Flag ::Long ( " color " ) ) ) ) ;
2017-07-26 22:37:58 +00:00
}
2017-07-26 22:05:45 +00:00
}