digitalmars.D.learn - What's the proper way to use std.getopt?
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (17/17) Dec 11 2017 I don't quite understand what to do if getopt throws. I would
- Mike Wey (25/31) Dec 11 2017 I would use something like this, print the help information for --help,
- Seb (8/32) Dec 11 2017 D style would be to use sth. like this (instead of try/catch):
- H. S. Teoh (9/17) Dec 11 2017 Frankly, much as I love UFCS syntax, I think this is taking it a little
- Jonathan M Davis (23/38) Dec 11 2017 Clearly, there's quite a range of what folks like or find acceptable.
- Mike Wey (4/12) Dec 12 2017 I might have missed something, but where is `e` defined in this case?
- bauss (10/21) Dec 12 2017 I was thinking the same and can't find anything in the
- Jonathan M Davis (6/30) Dec 12 2017 If it works, it's a bug related to code lowering (since scope statements...
- bauss (4/12) Dec 13 2017 Yeah that's what I thought.
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (5/23) Dec 11 2017 But I would like to show the help docstring when processing the
- Adam D. Ruppe (28/30) Dec 11 2017 I might have already said this to you on IRC but the way I'd do
- Jon Degenhardt (8/11) Dec 12 2017 The command line tools I published use the approach described in
- Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso (7/15) Dec 12 2017 [snip]
I don't quite understand what to do if getopt throws. I would
have hoped for something like
int arg1;
string arg2;
auto parser = getopt("opt1", "docstring 1", &arg1, "opt2",
"docstring 2", &arg2);
try {
auto opts = parser.parse(args)
}
except(BadArguments) {
parser.showHelpString();
}
but instead, the docstring from getopt is only generated if all
arguments are valid, i.e. when it's the least needed because the
user already knew what to input.
What's the proper style, then? Can someone show me a good example
of how to use getopt and the docstring it automatically generates?
Dec 11 2017
On 11-12-17 21:58, Jordi Gutiérrez Hermoso wrote:but instead, the docstring from getopt is only generated if all arguments are valid, i.e. when it's the least needed because the user already knew what to input. What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates?I would use something like this, print the help information for --help, print an error for invalid arguments: ``` try { auto helpInformation = getopt( args, "input|i", "The input", &input, "output|o", "The output", &output ); if (helpInformation.helpWanted) { defaultGetoptPrinter("Description", helpInformation.options); exit(0); } } catch (GetOptException e) { writeln(e.msg); exit(1); } ``` -- Mike Wey
Dec 11 2017
On Monday, 11 December 2017 at 21:24:41 UTC, Mike Wey wrote:On 11-12-17 21:58, Jordi Gutiérrez Hermoso wrote:D style would be to use sth. like this (instead of try/catch): ``` scope(failure) { e.msg.writeln; 1.exit; } ```[...]I would use something like this, print the help information for --help, print an error for invalid arguments: ``` try { auto helpInformation = getopt( args, "input|i", "The input", &input, "output|o", "The output", &output ); if (helpInformation.helpWanted) { defaultGetoptPrinter("Description", helpInformation.options); exit(0); } } catch (GetOptException e) { writeln(e.msg); exit(1); } ```
Dec 11 2017
"H. S. Teoh" <hsteoh quickfur.ath.cx>
On Mon, Dec 11, 2017 at 11:35:53PM +0000, Seb via Digitalmars-d-learn wrote:
[...]
D style would be to use sth. like this (instead of try/catch):
```
scope(failure) {
e.msg.writeln;
1.exit;
}
```
Frankly, much as I love UFCS syntax, I think this is taking it a little
too far. Maybe I'm just old-fashioned, but I still find `exit(1)` much
more readable than `1.exit`. Ditto for the writeln.
scope(failure), OTOH, rawkz. :-P
T
--
Don't drink and derive. Alcohol and algebra don't mix.
Dec 11 2017
On Monday, December 11, 2017 15:38:44 H. S. Teoh via Digitalmars-d-learn wrote:On Mon, Dec 11, 2017 at 11:35:53PM +0000, Seb via Digitalmars-d-learn wrote: [...]Clearly, there's quite a range of what folks like or find acceptable. Personally, I never drop the parens unless it makes sense to treat the function like a property, so even if I were doing something like Seb here, it would be e.msg.writeln(); 1.exit(); but like you, I wouldn't use UFCS here. I don't know exactly what the line is for me though; some functions just don't feel right with UFCS, and others are perfectly fine. I think that part of it is probably whether the function returns. I'm unlikely to use UFCS if the function is void like these are. For whatever reason, using UFCS with something like writeln or exit just seems really wrong to me. But then again, I also think that it feels really wrong to do something like 42.msecs or 42.msecs(), and that _does_ return a value. Maybe it's because it feels like a constructor to me, and you don't use UFCS with constructors. I don't know. I don't know how logical or consistent my reasoning is with when to use UFCS, since I've never sat down and studied it. Sometimes, it feels perfectly reasonable, and other times, it just feels really wrong. Either way, clearly, different folks have a different level of tolerance or liking for UFCS in various circumstances. - Jonathan M DavisD style would be to use sth. like this (instead of try/catch): ``` scope(failure) { e.msg.writeln; 1.exit; } ```Frankly, much as I love UFCS syntax, I think this is taking it a little too far. Maybe I'm just old-fashioned, but I still find `exit(1)` much more readable than `1.exit`. Ditto for the writeln.
Dec 11 2017
On 12-12-17 00:35, Seb wrote:
D style would be to use sth. like this (instead of try/catch):
```
scope(failure) {
e.msg.writeln;
1.exit;
}
```
I might have missed something, but where is `e` defined in this case?
--
Mike Wey
Dec 12 2017
On Tuesday, 12 December 2017 at 18:34:26 UTC, Mike Wey wrote:On 12-12-17 00:35, Seb wrote:I was thinking the same and can't find anything in the documentation that states you can retrieve the exception that caused the failure by an "e" variable. All I could find is that in case you need to use the exception you'd have to do a try/catch. So ultimately that code wouldn't work, according to the language specs. I haven't tested it, so I don't know if it's some hidden feature, but if it is, then I'm against it.D style would be to use sth. like this (instead of try/catch): ``` scope(failure) { e.msg.writeln; 1.exit; } ```I might have missed something, but where is `e` defined in this case?
Dec 12 2017
On Wednesday, December 13, 2017 06:55:46 bauss via Digitalmars-d-learn wrote:On Tuesday, 12 December 2017 at 18:34:26 UTC, Mike Wey wrote:If it works, it's a bug related to code lowering (since scope statements are always lowered to try-catch-finally blocks). You're not supposed to have access to the exception in a scope statement. - Jonathan M DavisOn 12-12-17 00:35, Seb wrote:I was thinking the same and can't find anything in the documentation that states you can retrieve the exception that caused the failure by an "e" variable. All I could find is that in case you need to use the exception you'd have to do a try/catch. So ultimately that code wouldn't work, according to the language specs. I haven't tested it, so I don't know if it's some hidden feature, but if it is, then I'm against it.D style would be to use sth. like this (instead of try/catch): ``` scope(failure) { e.msg.writeln; 1.exit; } ```I might have missed something, but where is `e` defined in this case?
Dec 12 2017
On Wednesday, 13 December 2017 at 07:37:17 UTC, Jonathan M Davis wrote:On Wednesday, December 13, 2017 06:55:46 bauss via Digitalmars-d-learn wrote:Yeah that's what I thought. Just tested and it doesn't allow you to.[...]If it works, it's a bug related to code lowering (since scope statements are always lowered to try-catch-finally blocks). You're not supposed to have access to the exception in a scope statement. - Jonathan M Davis
Dec 13 2017
On Monday, 11 December 2017 at 21:24:41 UTC, Mike Wey wrote:
try
{
auto helpInformation = getopt(
args,
"input|i", "The input", &input,
"output|o", "The output", &output
);
if (helpInformation.helpWanted)
{
defaultGetoptPrinter("Description", helpInformation.options);
exit(0);
}
}
catch (GetOptException e)
{
writeln(e.msg);
exit(1);
}
But I would like to show the help docstring when processing the
exception. It's pretty standard behaviour. If you give a program
bad arguments, it just spits out a docstring of all options and
what each does. Can this be achieved?
Dec 11 2017
On Monday, 11 December 2017 at 20:58:25 UTC, Jordi Gutiérrez Hermoso wrote:I don't quite understand what to do if getopt throws. I would have hoped for something likeI might have already said this to you on IRC but the way I'd do it (if you must do this) is: void main(string[] args) { int arg1; string arg2; bool getoptions(string[] args) { auto result = getopt(args, "opt1", "docstring 1", &arg1, "opt2", "docstring 2", &arg2); if(result.helpWanted) defaultGetoptPrinter("Some information about the program.", result.options); return result.helpWanted; } try { if(getoptions(args)) return; // it just printed help } catch(GetOptException e) { writeln(e.msg); getoptions(["--help"]); return; } /* rest of your program */ } Even though, I think printing the whole help output on any exception is likely to be fairly annoying since it obscures the actual error message.
Dec 11 2017
On Monday, 11 December 2017 at 20:58:25 UTC, Jordi Gutiérrez Hermoso wrote:What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates?The command line tools I published use the approach described in a number of the replies, but with a tad more structure. It's hardly perfect, but may be useful if you want more examples. See: https://github.com/eBay/tsv-utils-dlang/blob/master/tsv-samp e/src/tsv-sample.d. See the main() routine and the TsvSampleOptions struct. Most of the tools have a similar pattern. --Jon
Dec 12 2017
On Tuesday, 12 December 2017 at 20:57:28 UTC, Jon Degenhardt wrote:On Monday, 11 December 2017 at 20:58:25 UTC, Jordi Gutiérrez Hermoso wrote:[snip]What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates?See: https://github.com/eBay/tsv-utils-dlang/blob/master/tsv-sample/src/tsv-sample.dOh, thanks! This is more or less what I wanted. I suppose showing all of the docstring when the arguments are bad is possibly stupid and I shouldn't be doing that to begin with. I'll adopt this style to only show which argument was bad.
Dec 12 2017