www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the proper way to use std.getopt?

reply Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
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
next sibling parent reply Mike Wey <mike-wey example.com> writes:
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
next sibling parent reply Seb <seb wilzba.ch> writes:
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; } ```
Dec 11 2017
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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: [...]

 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
Dec 11 2017
prev sibling parent reply Mike Wey <mike-wey example.com> writes:
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
parent reply bauss <jj_1337 live.dk> writes:
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.
Dec 12 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Dec 12 2017
parent bauss <jj_1337 live.dk> writes:
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.
Dec 13 2017
prev sibling parent Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
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
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Dec 11 2017
prev sibling parent reply Jon Degenhardt <jond noreply.com> writes:
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
parent Jordi =?UTF-8?B?R3V0acOpcnJleg==?= Hermoso <jordigh octave.org> writes:
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.
Dec 12 2017