2016-04-17 19:38:37 +00:00
use output ::Colours ;
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-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
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-07-26 16:48:18 +00:00
use info ::filetype ::FileExtensions ;
2016-04-17 19:38:37 +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-08-10 16:54:28 +00:00
let mode = Mode ::deduce ( matches , vars ) ? ;
2017-07-08 11:11:11 +00:00
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-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-10 16:54:28 +00:00
if let Some ( columns ) = vars . get ( " 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 > {
if let Some ( columns ) = vars . get ( " EXA_GRID_ROWS " ) . and_then ( | s | s . into_string ( ) . ok ( ) ) {
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-08-09 12:36:06 +00:00
const TIME_STYLES : & [ & str ] = & [ " default " , " long-iso " , " full-iso " , " iso " ] ;
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-08-09 12:36:06 +00:00
Err ( Misfire ::bad_argument ( & flags ::TIME_STYLE , word , TIME_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 ( ) ) {
2017-08-23 10:45:29 +00:00
let scale = matches . has_where ( | f | f . matches ( & flags ::COLOR_SCALE ) | | f . matches ( & flags ::COLOUR_SCALE ) ) ? ;
Ok ( Colours ::colourful ( scale . is_some ( ) ) )
2017-06-25 13:51:44 +00:00
}
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 ;
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
pub fn os ( input : & 'static str ) -> OsString {
let mut os = OsString ::new ( ) ;
os . push ( input ) ;
os
}
2017-07-26 22:05:45 +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-23 10:45:29 +00:00
& flags ::COLOR , & flags ::COLOUR , & flags ::COLOR_SCALE , & flags ::COLOUR_SCALE ,
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 ::* ;
2017-08-10 12:52:49 +00:00
use std ::ffi ::OsStr ;
2017-08-09 16:14:16 +00:00
// 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-08-10 12:52:49 +00:00
test! ( daily : TimeFormat < - [ " --time-style=24-hour " ] ; Both = > err Misfire ::bad_argument ( & flags ::TIME_STYLE , OsStr ::new ( " 24-hour " ) , TIME_STYLES ) ) ;
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-08-10 12:52:49 +00:00
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 } ) ) ;
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
}
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
2017-08-10 12:52:49 +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!
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
// 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 ) ) ;
2017-08-10 12:52:49 +00:00
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-08-23 10:45:29 +00:00
test! ( scale_1 : Colours < - [ " --color=always " , " --color-scale " , " --colour-scale " ] ; Last = > like Ok ( Colours { scale : true , .. } ) ) ;
test! ( scale_2 : Colours < - [ " --color=always " , " --color-scale " , ] ; Last = > like Ok ( Colours { scale : true , .. } ) ) ;
test! ( scale_3 : Colours < - [ " --color=always " , " --colour-scale " ] ; Last = > like Ok ( Colours { scale : true , .. } ) ) ;
test! ( scale_4 : Colours < - [ " --color=always " , ] ; Last = > like Ok ( Colours { scale : false , .. } ) ) ;
test! ( scale_5 : Colours < - [ " --color=always " , " --color-scale " , " --colour-scale " ] ; Complain = > err Misfire ::Duplicate ( Flag ::Long ( " color-scale " ) , Flag ::Long ( " colour-scale " ) ) ) ;
test! ( scale_6 : Colours < - [ " --color=always " , " --color-scale " , ] ; Complain = > like Ok ( Colours { scale : true , .. } ) ) ;
test! ( scale_7 : Colours < - [ " --color=always " , " --colour-scale " ] ; Complain = > like Ok ( Colours { scale : true , .. } ) ) ;
test! ( scale_8 : Colours < - [ " --color=always " , ] ; Complain = > like Ok ( Colours { scale : false , .. } ) ) ;
2017-07-26 22:37:58 +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
}