Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 01 2020 13:10
    pksunkara commented #1711
  • Mar 01 2020 13:09
    pickfire commented #1711
  • Mar 01 2020 13:07
    pickfire commented #1710
  • Mar 01 2020 12:14
    bors[bot] commented #1710
  • Mar 01 2020 12:14
    CreepySkeleton commented #1710
  • Mar 01 2020 12:09
    CreepySkeleton commented #1710
  • Mar 01 2020 12:09
    CreepySkeleton commented #1710
  • Mar 01 2020 12:08
    pksunkara review_requested #1710
  • Mar 01 2020 11:49
    pickfire commented #1710
  • Mar 01 2020 11:47
    pksunkara commented #1711
  • Mar 01 2020 11:44
    pickfire opened #1711
  • Mar 01 2020 11:44
    pickfire labeled #1711
  • Mar 01 2020 11:36
    pickfire synchronize #1710
  • Mar 01 2020 09:10
    pickfire commented #1710
  • Mar 01 2020 09:09
    pickfire opened #1710
  • Mar 01 2020 08:30
    pksunkara commented #1655
  • Mar 01 2020 08:29
    pickfire commented #1655
  • Feb 29 2020 16:49
    bors[bot] closed #1709
  • Feb 29 2020 16:49
    bors[bot] commented #1709
  • Feb 29 2020 16:07
    pksunkara commented #1709
Mehdi Sadeghi
@mehdisadeghi
Howerver I have another question. How can I add default value and env option to an arguement with the clap_app! macro? e.g. (@arg BUS: "socketcan interface")
Mehdi Sadeghi
@mehdisadeghi
Found that one too! (@arg BUS: default_value[vcan0] "socketcan interface")
This channel is pure magic. You just ask the questsions. The answers appear in your mind. Have a good day!
Git User
@gitb2_gitlab
is there a way to capture all args in clap without "--" param. So I'd like to have ./myprog -a something anotherparam -e -a --anything ==>
param1: -a (something)
param2: anotherparam
param3: -e -a --anything
I've tried in yaml with "allow_hyphen_values: true and "multiple: true" but it does not work
complains that -e is not valid parameter
Denis Lisov
@tanriol
Have you tried AppSettings::TrailingVarArg?
Git User
@gitb2_gitlab
@tanriol thanks, seems to work
programmatically, gotta find a way to impl it in yaml
let m = App::from(yml).setting(clap::AppSettings::TrailingVarArg).get_matches();
and yml: "cmd" with "multiple: true" seemed to do the trick
prographo
@prographo

I really hate rust, hope someone can help me, so I can get back to programming in a language I like...

            Arg::with_name("tflag")
                .short("tf")
                .long("tflag")
                .help("Turbo on if this flag is specified"),

When I run...

error: The argument 'tflag' wasn't found

How do I make a an argument optional?

even when I specify it doesn't take a value .. same result.
                .takes_value(false)
               .required(false)
Still demands the argument.
h.e.l.p
Denis Lisov
@tanriol

@prographo

I really hate rust

I'm pretty sure that this is not the most efficient way of asking for help :-)

Anyway, your error looks like it is optional, but your code is not ready for it being absent (using macros that assume it's always present?).

stedingan
@stedingan
Hello what am i doing wrong if i want to have an argument -e and also an argument -ext or is this not possible?
Denis Lisov
@tanriol
@stedingan By default, -ext as an argument is considered the same as -e -x -t
Long arguments are normally introduced with -- like --my-ext-argument
stedingan
@stedingan
@tanriol so if i do https://paste.xinu.at/W3A/ i generate three shorts?
Arash
@areux

is there a way to have multi-word options in clap_app!?
for example in this code

(@arg dbus_start_jack: --start-jack "Start jack via dbus interface")

clap converts --start-jack to --start.

Denis Lisov
@tanriol
@areux Definitely possible if constructed in code; not sure about macros.
See docs, your question is mentioned there. TL;DR: --("start-jack")
CreepySkeleton
@CreepySkeleton
Hey people! From now on, I'm going to be monitoring this channel and answering your pleads for help / complaints. The goal is to build a sort of sub-community that is able answering simple questions, thus taking some load off the maintainers. Only feature requests / bug reports / really complicated questions should be directed to the issue tracker.
Denis Lisov
@tanriol
@CreepySkeleton Hello and nice to see someone else ready to help people :-)
CreepySkeleton
@CreepySkeleton
Any idea how to increase the amount of someoneelses?
Denis Lisov
@tanriol
Not much. On the other hand, at the moment the amount of questions here is also rather low - maybe one in a week or even a few.
CreepySkeleton
@CreepySkeleton
Let me tell you a secret - the amount of question directed to the issue tracker is... not huge, but close to uncomfortable for some maintainers.
Diana
@DianaNites
Is there any way to do what I want TeXitoi/structopt#365? Some sort of default_occurrences_if, or a way to get default_value_if working for it?
amesgen
@amesgen
Are there plans for clap::App: Send? I think it would suffice to replace Rc by Arc here. I would be open to implementing this (behind a feature flag).
Denis Lisov
@tanriol
@amesgen What's your use case for it? Sounds to me like argument parsing usually happens well before starting additional threads, no?
amesgen
@amesgen
@tanriol Usually it does, but I use clap/structopt for parsing input commands of a chat bot. This usage seems to be intended if I interpret the comments on this correctly.
CreepySkeleton
@CreepySkeleton
@DianaNites Not that I would know about. Not with structopt at least
CreepySkeleton
@CreepySkeleton
@amesgen But do you really want to send the App instance across the boundary?
amesgen
@amesgen
@CreepySkeleton Yes, chat message processing is concurrent. Right now, I recreate the app on every message received, which is probably fine if the clap::App is small and the message frequency is low.
CreepySkeleton
@CreepySkeleton
@amesgen You should raise the issue on the tracker: https://github.com/clap-rs/clap/issues
I'm not against replacing Rc with Arc, I'm just wary it would penalize the performance for common cases in favor of corner cases. I don't see your case as very common, no offense.
Maybe we'll manage to invent an alternative solution.
CreepySkeleton
@CreepySkeleton
Also, a feature flag won't do. They are supposed to be purely additive.
Hans
@hansl
Hey guys. How y'all doing? We are using Clap for command parsing and wanted to move to v3. 2 questions; (1) can we move command to command from v2 to v3 #[derive()] (or do we have to do all at once)? and (2) can we use a function call as the default value (we have some resolution logic in some places)?
MGlolenstine
@MGlolenstine
Hey guys, I was wondering how I could set it so when my program was called without any arguments, the program would print the same as command --help. Is there a way to do it?
Also, is there a way to give command arguments default values? I'm currently checking if the variable doesn't exist and then setting it to a "default" value.
amesgen
@amesgen
@CreepySkeleton Ok, I will create an issue. Indeed, an alternative solution would be optimal. Of course, my usecase is not common (I probably should have explained my use ase upfront to prevent XY-problem-like communication). I suggested putting the Arc solution behind a feature flag exactly due to performance concerns, and I am surprised that feature flags are supposed to be only additive in clap (other libraries like tokio use feature flags for similar things (std vs parking_lot sync stuff)). Would you mind expanding on that?
Denis Lisov
@tanriol
@MGlolenstine AppSettings::ArgRequiredElseHelp, Arg::default_value - note however that these two are not compatible because the default value is considered to be present.
@amesgen In all crates feature flags are supposed to be purely additive (as in "if it compiles and I enable some other feature flag, it has to compile as well").
MGlolenstine
@MGlolenstine
@tanriol Thanks! I'm unsure how I managed to miss this.
CreepySkeleton
@CreepySkeleton
@amesgen Features are supposed to be additive in all crates because they get populated across all the dependency tree.
Imagine we've introduced a "foo" feature in clap. Your crates "banana" and "orange" depend on clap; "banana" enables "foo". Do you think "orange" depends on clap with "foo" disabled? Nope, if a feature was enabled somewhere, it ends up being enabled everywhere across the dependency graph.
This is why features are supposed to be additive.
CreepySkeleton
@CreepySkeleton
Btw, all the features in tokio are additive as I see. @amesgen What were you taliking about?