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 13:10
    pksunkara commented #1711
  • Mar 01 13:09
    pickfire commented #1711
  • Mar 01 13:07
    pickfire commented #1710
  • Mar 01 12:14
    bors[bot] commented #1710
  • Mar 01 12:14
    CreepySkeleton commented #1710
  • Mar 01 12:09
    CreepySkeleton commented #1710
  • Mar 01 12:09
    CreepySkeleton commented #1710
  • Mar 01 12:08
    pksunkara review_requested #1710
  • Mar 01 11:49
    pickfire commented #1710
  • Mar 01 11:47
    pksunkara commented #1711
  • Mar 01 11:44
    pickfire opened #1711
  • Mar 01 11:44
    pickfire labeled #1711
  • Mar 01 11:36
    pickfire synchronize #1710
  • Mar 01 09:10
    pickfire commented #1710
  • Mar 01 09:09
    pickfire opened #1710
  • Mar 01 08:30
    pksunkara commented #1655
  • Mar 01 08:29
    pickfire commented #1655
  • Feb 29 16:49
    bors[bot] closed #1709
  • Feb 29 16:49
    bors[bot] commented #1709
  • Feb 29 16:07
    pksunkara commented #1709
Git User
@gitb2_gitlab
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?
amesgen
@amesgen

@CreepySkeleton Thanks for the explanation/link! This situation is indeed suboptimal, at least clap is typically used only by the final binary and not by many different intermediate libraries with different flags. The "binary only" features mentioned by withoutboats would be a perfect fit for this IMHO. I personally think that enabling App: Send behind a feature is better than preventing the (probably rather uncommon) compilation failure if two crates with and without app-send depend on clap and one crate uses a not-Send + Sync validator{_os}, but that is not for me to decide.

I was talking about the parking_lot feature of tokio, but I initially forgot that in clap, one also has to adapt the bound on F to also require Send + Sync. If this was not the case, the situation would be analogous to tokio, as the change would be purely internal. This could be fixed by also requiring Send + Sync for F even when app-send is disabled, as the public API does not depend on app-send then (I updated #1771 to mention this).

amesgen
@amesgen
One clarification: I did not consider tokio's parking_lot feature to be "additive", as it modifies internal code, rather introducing new dependencies/functions, but that is probably bikeshedding.
Pavan Kumar Sunkara
@pksunkara
Hey guys, so our support for gitter community is always supposed to be temporary. Please use https://github.com/clap-rs/clap/discussions to ask a question from now onwards. I would encourage users to also answer some questions there. And I would encourage people to point others at that if they come asking a question here. We want our community to not be fragmented anymore.
Denis Lisov
@tanriol
@pksunkara Good luck to you :-) sorry, I don't feel like watching one more space, so I'll either continue answering here or just switch to other things.
Pavan Kumar Sunkara
@pksunkara
It is one of the reasons we got discussions enabled. Because we don't want to watch more workspaces than just github.