What's the proper way to use std.getopt?
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?
Re: What's the proper way to use std.getopt?
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
Re: What's the proper way to use std.getopt?
On Monday, 11 December 2017 at 21:24:41 UTC, Mike Wey wrote: On 11-12-17 21:58, Jordi Gutiérrez Hermoso wrote: [...] 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); } ``` D style would be to use sth. like this (instead of try/catch): ``` scope(failure) { e.msg.writeln; 1.exit; } ```
Re: What's the proper way to use std.getopt?
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?
Re: What's the proper way to use std.getopt?
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 like I 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.
Re: What's the proper way to use std.getopt?
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
Re: What's the proper way to use std.getopt?
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-sample/src/tsv-sample.d. See the main() routine and the TsvSampleOptions struct. Most of the tools have a similar pattern. --Jon
Re: What's the proper way to use std.getopt?
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: What's the proper style, then? Can someone show me a good example of how to use getopt and the docstring it automatically generates? [snip] See: https://github.com/eBay/tsv-utils-dlang/blob/master/tsv-sample/src/tsv-sample.d Oh, 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.
Re: What's the proper way to use std.getopt?
On Tuesday, 12 December 2017 at 18:34:26 UTC, Mike Wey wrote: 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? 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.
Re: What's the proper way to use std.getopt?
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: > > 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? > > 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. 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
Re: What's the proper way to use std.getopt?
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: [...] 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 Yeah that's what I thought. Just tested and it doesn't allow you to.
OT (Was: Re: What's the proper way to use std.getopt?)
On Mon, Dec 11, 2017 at 11:35:53PM +, 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.
Re: OT (Was: Re: What's the proper way to use std.getopt?)
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 +, 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. 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 Davis