how to use PathBuf has default value (config file)

[nbari]

I am trying to use as the default value a file located within home:

let home_dir =  dirs::home_dir()?
let config_file = home_dir.join(".config").join("s3m").join("config.yml");

I want to use it as the default value for the config, for example:

  .arg(
            Arg::new("config")
            .default_value(config_file)
            .long("config")
            .num_args(1)
            .short('c')
            .value_parser(validator_is_file())
            .value_name("config.yml")
        )

But when trying to build I get:

121  |            .default_value(config_file)
     |             ------------- ^^^^^^^^^^^ the trait `From<PathBuf>` is not implemented for `clap::builder::OsStr`
     |             |
     |             required by a bound introduced by this call
     |
     = help: the following other types implement trait `From<T>`:
               <clap::builder::OsStr as From<clap::builder::Str>>
               <clap::builder::OsStr as From<&clap::builder::OsStr>>
               <clap::builder::OsStr as From<&clap::builder::Str>>
               <clap::builder::OsStr as From<&&'static std::ffi::OsStr>>
               <clap::builder::OsStr as From<&&'static str>>
               <clap::builder::OsStr as From<&'static std::ffi::OsStr>>
               <clap::builder::OsStr as From<&'static str>>
     = note: required for `PathBuf` to implement `Into<clap::builder::OsStr>`
     = note: required for `PathBuf` to implement `IntoResettable<clap::builder::OsStr>`

I also tried display:

 .default_value(config_file.display())
     |             ------------- ^^^^^^^^^^^^^^^^^^^^^ the trait `From<std::path::Display<'_>>` is not implemented for `clap::builder::OsStr`

Any ideas about how to set the default value to an existing path/Pathbuf?

[epage]

• Without cargo add clap -F string, it'll need to be &'static Path
• You would need to call as_os_str

[nbari]

Hi @epage many thanks, can you please provide an example of how to use clap -F string (to not using &' static Path)

[nbari]

I think just found it, wondering if only doing something like:

.default_value(path.display().to_string())

but then when using get_one::<Pathbuf>("config") or what get_one::<String>("config") I get

Mismatch between definition and access of config. Could not downcast to std::path::PathBuf, need to downcast to ()

let config_file: PathBuf = match matches.get_one::<String>("config") {
        Some(c) => c.to_owned().into(),
        None => {
            eprintln!("no config file found");
            exit(1)
        }
    };

but same error

[nbari]

The problem that I had is that my validator was not returning Pathbuf, this fixed:

pub fn validator_is_file() -> ValueParser {
    ValueParser::from(move |s: &str| -> std::result::Result<PathBuf, String> {
        if fs::metadata(s).map_err(|e| e.to_string())?.is_file() {
            Ok(PathBuf::from(s))
        } else {
            Err(format!("Cannot read the file: {}", s))
        }
    })
}

And using the Arg like this:

  .arg(
            Arg::new("config")
            .default_value(config_file_path.into_os_string())
            .long("config")
            .num_args(1)
            .short('c')
            .value_parser(validator_is_file())
            .value_name("config.yml")
        ) 

Then to get the config I am using:

  let config_file: PathBuf = matches
        .get_one::<PathBuf>("config")
        .map(|c| c.into())
        .unwrap_or_else(|| {
            eprintln!("no config file found");
            exit(1);
        });

Is there any room to make it cleaner or best practices to follow?

[epage]

You don't need display but PathBuf should have a into_os_string or similar.

As for the error, id need a full reproduction case.

[epage]

Wow, github mobile made this hard to follow and respond to the correct thing.

Is there any room to make it cleaner or best practices to follow?

Overall, I've taken the approach that the builder API is the lower level, more complex API. Without a custom value parser (using just built-ins), you automatically get alignment between the value_parser and the get_one calls. With a custom value parser, there can be mistakes like this. Using something like clio's OsStrParser can help.

So with that background, there are likely things we can improve.

• clio is linked to from the main docs as a related product but could likely be called out more.
• We do need to make a builder version of the typed value example