Escaping delimiters for value_parser when using value_delimiter

[quietvoid]

Hi.
I've searched the existing issues/discussions and couldn't find anything on support for arg values containing the characters used for value_delimiter

For example, my app supports custom list arg values that consist of an enum value and optional path string.

#[arg(
    id = "data",
    help = "List of key-value export parameters formatted as `key=output`, where `output` is an output file path.\nSupports multiple occurences prefixed by --data or delimited by ','",
    long,
    short = 'd',
    conflicts_with = "output",
    value_parser = ExportOptionParser,
    value_delimiter = ','
)]
pub data: Vec<(ExportData, Option<PathBuf>)>,

So it can support lists like --data a,b,c=path.txt.
However some paths may contain the character used in value_delimiter, and it breaks the parsing as the values are split before being passed to the parser.

Though the shell may remove escapes, when explicit such as --data a,b=\'a,test.txt\', the delimiter doesn't seem possible to escape.
And the parser receives truncated strings becaues of the delimiter:

"a"
"b=\'a"
"test.txt\'"

So my question is basically if there's a way to support either of:

• escaping the value_delimiter char
• allowing the user to specify a custom delimiter as an arg?

For reference: quietvoid/dovi_tool#284

[epage]

There can be a lot of caveats to escaping that I worry that fully supporting it would over-complicate clap's API, bloat the API, and negatively affect binary size and build times for little gain. I lean towards this being handled by callers in TypedValueParser implementations (note that functions of the right signature implement that trait).

Some things to know

• You're custom value parser would be returning a Vec which would make your field a Vec<Vec<_>>. It looks like that doesn't have special meaning in clap (some have requested it in the past) so you are likely fine with that
• If you want to support OsStr, you'll need to work with OsStr::as_encoded_bytes and OsStr::from_encoded_bytes_unchecked

[quietvoid]

Thanks, I guess it is possible only with a custom parser but I'd rather not have to handle it all myself.
Either way, the solution is simple: users can simply avoid using the delimiter in the values.