This works, assuming mainflag is defined for both the main mode and command's mode:
program command --mainflag --commandflag
I'd like this to work too:
program --mainflag command --commandflag
but it doesn't recognise --commandflag, I think because it has not selected the command's mode.
Aug 19, 2011 Delete comment Project Member #1 ndmitchell
In the first case, whether --mainflag is defined for the main mode is totally irrelevant. The current rule is:
program [modes] [flags/args]
This picks exactly one mode, then accumulates flags/args into it. In the first case you do not end up with:
main-mode{--mainflag} and command-mode{--commandflag}
You just end up with:
command-mode{--mainflag,--commandflag}
The restriction to only have modes before flags is just a choice of the command line processor, and could be lifted - is that what you are asking for? However, the restriction to only producing one "mode" value is much more fundamental.
Labels: Proj-Catch
Aug 19, 2011 Delete comment Project Member #2 ndmitchell
(No comment was entered for this change.)
Labels: -Proj-Catch Proj-CmdArgs
Aug 19, 2011 Delete comment Project Member #3 ndmitchell
Issue 458 has been merged into this issue.
Aug 19, 2011 Delete comment #4 simon@joyful.com
Ok, it sounds like I don't have the right mental model for cmdargs yet, but yes I think that's what I'm asking for. I'd like flags to work either before or after the mode (command); I think I'm used to that from other (good) programs.
Sep 3, 2011 Delete comment Project Member #5 ndmitchell
Currently CmdArgs allows you to enter: modes(flags|args)
You are asking for: (modes|flags|args)*
Separately, Lennart has asked for: modes_flags_args*
Certainly the mode Lennart asks for is essential to support something like runhaskell, where "runhaskell -O Module --args" should be treated as --args being an argument that is passed on directly, and then interpreted by the Module.
It seems like this should be a preference set per application, something available in Explicit, and then exposed through Implicit.
Summary: Modes/Flags/Args ordering should be customizable
Status: Accepted
Sep 6, 2011 Delete comment #6 simon@joyful.com
Hi Neil, following up on this and your email: I'm not asking that flags be handled or passed through based on their position in the command line, at least not in this issue. I'm just asking for a more forgiving parser that allows flags to appear either before or after the mode argument, so users don't have to think much about ordering. I think this is what the most usable programs out there, do, and of course I'd like cmdargs to support that. I actually didn't realise it wasn't supported until you pointed it out.
Sep 6, 2011 Delete comment #7 simon@joyful.com
PS but since you bring it up, that pass-through-based on position rule feels a bit to clever/unfamiliar to me. I like the explicit "after --" convention. But I'd like an alternate mode where unrecognised flags are passed through without complaint. That would make hledger's commands more usable, users wouldn't have to use -- and ordering would be more flexible.
Sep 11, 2011 Delete comment Project Member #8 ndmitchell
I added this bug to track the addition of an unknown flag: https://code.google.com/p/ndmitchell/issues/list?id=470
Sep 11, 2011 Delete comment Project Member #9 ndmitchell
I raised a separate bug for the unknown flags bit: https://code.google.com/p/ndmitchell/issues/detail?id=470
Oct 16, 2012 Delete comment Project Member #10 ndmitchell
Asked on StackOverflow: http://stackoverflow.com/questions/12881204/can-cmdargs-have-flags-outside-of-sub-modes/
Labels: Downstream
Jan 27, 2014 Delete comment #11 rpglover64
I assume no progress has been made on this. Could some of the parsing difficulties be ameliorated by requiring explicit specification of common flags that can be present before the mode?
From http://code.google.com/p/ndmitchell/issues/detail?id=457 by @simonmichael:
This works, assuming mainflag is defined for both the main mode and command's mode:
program command --mainflag --commandflag
I'd like this to work too:
program --mainflag command --commandflag
but it doesn't recognise --commandflag, I think because it has not selected the command's mode. Aug 19, 2011 Delete comment Project Member #1 ndmitchell In the first case, whether --mainflag is defined for the main mode is totally irrelevant. The current rule is:
program [modes] [flags/args]
This picks exactly one mode, then accumulates flags/args into it. In the first case you do not end up with:
main-mode{--mainflag}
andcommand-mode{--commandflag}You just end up with:
command-mode{--mainflag,--commandflag}
The restriction to only have modes before flags is just a choice of the command line processor, and could be lifted - is that what you are asking for? However, the restriction to only producing one "mode" value is much more fundamental. Labels: Proj-Catch Aug 19, 2011 Delete comment Project Member #2 ndmitchell (No comment was entered for this change.) Labels: -Proj-Catch Proj-CmdArgs Aug 19, 2011 Delete comment Project Member #3 ndmitchell Issue 458 has been merged into this issue. Aug 19, 2011 Delete comment #4 simon@joyful.com Ok, it sounds like I don't have the right mental model for cmdargs yet, but yes I think that's what I'm asking for. I'd like flags to work either before or after the mode (command); I think I'm used to that from other (good) programs. Sep 3, 2011 Delete comment Project Member #5 ndmitchell Currently CmdArgs allows you to enter: modes(flags|args)
You are asking for: (modes|flags|args)*
Separately, Lennart has asked for: modes_flags_args*
Certainly the mode Lennart asks for is essential to support something like runhaskell, where "runhaskell -O Module --args" should be treated as --args being an argument that is passed on directly, and then interpreted by the Module.
It seems like this should be a preference set per application, something available in Explicit, and then exposed through Implicit. Summary: Modes/Flags/Args ordering should be customizable Status: Accepted Sep 6, 2011 Delete comment #6 simon@joyful.com Hi Neil, following up on this and your email: I'm not asking that flags be handled or passed through based on their position in the command line, at least not in this issue. I'm just asking for a more forgiving parser that allows flags to appear either before or after the mode argument, so users don't have to think much about ordering. I think this is what the most usable programs out there, do, and of course I'd like cmdargs to support that. I actually didn't realise it wasn't supported until you pointed it out. Sep 6, 2011 Delete comment #7 simon@joyful.com PS but since you bring it up, that pass-through-based on position rule feels a bit to clever/unfamiliar to me. I like the explicit "after --" convention. But I'd like an alternate mode where unrecognised flags are passed through without complaint. That would make hledger's commands more usable, users wouldn't have to use -- and ordering would be more flexible. Sep 11, 2011 Delete comment Project Member #8 ndmitchell I added this bug to track the addition of an unknown flag: https://code.google.com/p/ndmitchell/issues/list?id=470 Sep 11, 2011 Delete comment Project Member #9 ndmitchell I raised a separate bug for the unknown flags bit: https://code.google.com/p/ndmitchell/issues/detail?id=470 Oct 16, 2012 Delete comment Project Member #10 ndmitchell Asked on StackOverflow: http://stackoverflow.com/questions/12881204/can-cmdargs-have-flags-outside-of-sub-modes/ Labels: Downstream Jan 27, 2014 Delete comment #11 rpglover64 I assume no progress has been made on this. Could some of the parsing difficulties be ameliorated by requiring explicit specification of common flags that can be present before the mode?