www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - getopt & single-letter options with parameters

reply Adrian Matoga <epi atari8.info> writes:
Hi,

Is it by design that single-letter option needs to be glued to its 
argument, like "-ofilename", or is it a bug in implementation?

Source:

import std.stdio;
import std.getopt;

void main(string[] args)
{
	string outputFile;
	getopt(args,
		config.passThrough,
		"o|output-filename", &outputFile);
	writeln(args);
	writeln("'" ~ outputFile ~ "'");
}



Results:

test.exe -o somename


test.exe somename
''


test.exe -osomename


test.exe
'somename'

Regards,
Adrian Matoga
Aug 07 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/07/2010 05:55 PM, Adrian Matoga wrote:

 Hi,

 Is it by design that single-letter option needs to be glued to its
 argument, like "-ofilename", or is it a bug in implementation?

 Source:

 import std.stdio;
 import std.getopt;

 void main(string[] args)
 {
 string outputFile;
 getopt(args,
 config.passThrough,
 "o|output-filename", &outputFile);
 writeln(args);
 writeln("'" ~ outputFile ~ "'");
 }



 Results:
  >test.exe -o somename
 test.exe somename
 ''

  >test.exe -osomename
 test.exe
 'somename'

 Regards,
 Adrian Matoga


It's by design in order to avoid confusion with parameterless options. 
Your example works with either of these invocations:

./prog -ofilename
./prog -o=filename
./prog --o=filename

but not others.


Andrei
Aug 07 2010
next sibling parent reply Adrian Matoga <epi atari8.info> writes:
On 2010-08-08 01:22, Andrei Alexandrescu wrote:

 On 08/07/2010 05:55 PM, Adrian Matoga wrote:

 Hi,

 Is it by design that single-letter option needs to be glued to its
 argument, like "-ofilename", or is it a bug in implementation?

 Source:

 import std.stdio;
 import std.getopt;

 void main(string[] args)
 {
 string outputFile;
 getopt(args,
 config.passThrough,
 "o|output-filename", &outputFile);
 writeln(args);
 writeln("'" ~ outputFile ~ "'");
 }



 Results:
  >test.exe -o somename
 test.exe somename
 ''

  >test.exe -osomename
 test.exe
 'somename'

 Regards,
 Adrian Matoga


 
 It's by design in order to avoid confusion with parameterless options. 
 Your example works with either of these invocations:
 
 ./prog -ofilename
 ./prog -o=filename
 ./prog --o=filename
 
 but not others.
 
 
 Andrei


Thanks very much.
I suggest adding this info to official docs (it's not obvious, and a bit 
confusing, since long options work with whitespace(s)).

Adrian
Aug 07 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/07/2010 06:57 PM, Adrian Matoga wrote:

 On 2010-08-08 01:22, Andrei Alexandrescu wrote:

 On 08/07/2010 05:55 PM, Adrian Matoga wrote:

 Hi,

 Is it by design that single-letter option needs to be glued to its
 argument, like "-ofilename", or is it a bug in implementation?

 Source:

 import std.stdio;
 import std.getopt;

 void main(string[] args)
 {
 string outputFile;
 getopt(args,
 config.passThrough,
 "o|output-filename", &outputFile);
 writeln(args);
 writeln("'" ~ outputFile ~ "'");
 }



 Results:

test.exe -o somename


 test.exe somename
 ''


test.exe -osomename


 test.exe
 'somename'

 Regards,
 Adrian Matoga


 It's by design in order to avoid confusion with parameterless options.
 Your example works with either of these invocations:

 ./prog -ofilename
 ./prog -o=filename
 ./prog --o=filename

 but not others.


 Andrei


 Thanks very much.
 I suggest adding this info to official docs (it's not obvious, and a bit
 confusing, since long options work with whitespace(s)).

 Adrian


http://www.dsource.org/projects/phobos/changeset/1822

Andrei
Aug 08 2010
parent Adrian Matoga <epi atari8.info> writes:
 http://www.dsource.org/projects/phobos/changeset/1822
 
 Andrei


Thank you, now the description is clear.

By the way, shouldn't "--FOo" and "--bAr" in the following fragment be 
rejected because of "caseSensitive" set just before them?



 By default options are case-insensitive. You can change that behavior
 by passing $(D getopt) the $(D caseSensitive) directive like this:

 ---------
 bool foo, bar;
 getopt(args,
     std.getopt.config.caseSensitive,
     "foo", &foo,
     "bar", &bar);
 ---------

 In the example above, "--foo", "--bar", "--FOo", "--bAr" etc. are 


recognized.


Adrian
Aug 08 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
On Aug 7, 2010, at 4:22 PM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org 

 wrote:




 It's by design in order to avoid confusion with parameterless  
 options. Your example works with either of these invocations:

 ./prog -ofilename
 ./prog -o=filename
 ./prog --o=filename

 but not others.


 Andrei





 Aug 07 2010



prev sibling next sibling parent reply SK <sk metrokings.com>  writes:


	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit



On Aug 7, 2010, at 4:22 PM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org 

 wrote:



 On 08/07/2010 05:55 PM, Adrian Matoga wrote:

 Hi,

 Is it by design that single-letter option needs to be glued to its
 argument, like "-ofilename", or is it a bug in implementation?

 Source:

 import std.stdio;
 import std.getopt;

 void main(string[] args)
 {
 string outputFile;
 getopt(args,
 config.passThrough,
 "o|output-filename", &outputFile);
 writeln(args);
 writeln("'" ~ outputFile ~ "'");
 }



 Results:

test.exe -o somename


 test.exe somename
 ''


test.exe -osomename


 test.exe
 'somename'

 Regards,
 Adrian Matoga


 It's by design in order to avoid confusion with parameterless  
 options. Your example works with either of these invocations:

 ./prog -ofilename
 ./prog -o=filename
 ./prog --o=filename

 but not others.


 Andrei


The prevailing convention is to allow whitespace in this case.  Would  
you reconsider?

Sorry for the accidental null post earlier.

-steve



 Aug 07 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 08/07/2010 10:08 PM, SK wrote:

 It's by design in order to avoid confusion with parameterless options.
 Your example works with either of these invocations:

 ./prog -ofilename
 ./prog -o=filename
 ./prog --o=filename

 but not others.


 Andrei


 The prevailing convention is to allow whitespace in this case. Would you
 reconsider?


Sure. A patch would actually help a lot.

Andrei



 Aug 07 2010



prev sibling next sibling parent  Jonathan M Davis <jmdavisprog gmail.com>  writes:


On Saturday 07 August 2010 20:08:26 SK wrote:

 Sorry for the accidental null post earlier.


Well, just so long as no one dereferenced it... ;)

- Jonathan M Davis



 Aug 07 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i3kpsi$rod$1 digitalmars.com...

 ./prog -ofilename


That being allowed at all kind of bugs me. I realize this probably isn't a 
particularly common problem in practice, but suppose you have:

-o<filename>
-of

And the user uses "-o" with a file named "f":

theapp -of  // Do what now?

Or,

-o<filename>
-of<filename>

theapp -ofabc  // "-o fabc" or "-of abc"?

The whole possibility kinda makes me nervous.



 Aug 08 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 08/08/2010 12:17 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i3kpsi$rod$1 digitalmars.com...

 ./prog -ofilename


 That being allowed at all kind of bugs me. I realize this probably isn't a
 particularly common problem in practice, but suppose you have:

 -o<filename>
 -of

 And the user uses "-o" with a file named "f":

 theapp -of  // Do what now?

 Or,

 -o<filename>
 -of<filename>

 theapp -ofabc  // "-o fabc" or "-of abc"?

 The whole possibility kinda makes me nervous.


Short options with parameters don't accept bundling, so the problem 
never shows itself.

Andrei



 Aug 08 2010



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 08/08/2010 02:37 PM, Andrei Alexandrescu wrote:

 On 08/08/2010 12:17 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:i3kpsi$rod$1 digitalmars.com...

 ./prog -ofilename


 That being allowed at all kind of bugs me. I realize this probably
 isn't a
 particularly common problem in practice, but suppose you have:

 -o<filename>
 -of

 And the user uses "-o" with a file named "f":

 theapp -of // Do what now?

 Or,

 -o<filename>
 -of<filename>

 theapp -ofabc // "-o fabc" or "-of abc"?

 The whole possibility kinda makes me nervous.


 Short options with parameters don't accept bundling, so the problem
 never shows itself.

 Andrei


Actually I stand corrected. The tar program does use bundled parameters...

Andrei



 Aug 08 2010



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i3n12a$2vfq$1 digitalmars.com...

 On 08/08/2010 12:17 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i3kpsi$rod$1 digitalmars.com...

 ./prog -ofilename


 That being allowed at all kind of bugs me. I realize this probably isn't 
 a
 particularly common problem in practice, but suppose you have:

 -o<filename>
 -of

 And the user uses "-o" with a file named "f":

 theapp -of  // Do what now?

 Or,

 -o<filename>
 -of<filename>

 theapp -ofabc  // "-o fabc" or "-of abc"?

 The whole possibility kinda makes me nervous.


 Short options with parameters don't accept bundling, so the problem never 
 shows itself.


This then:

--xy<filename>
--xyz<filename>

theapp --xyzabc  // "--xy zabc" or "-xyz abc"?



 Aug 08 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 08/08/2010 04:02 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i3n12a$2vfq$1 digitalmars.com...

 On 08/08/2010 12:17 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>   wrote in message
 news:i3kpsi$rod$1 digitalmars.com...

 ./prog -ofilename


 That being allowed at all kind of bugs me. I realize this probably isn't
 a
 particularly common problem in practice, but suppose you have:

 -o<filename>
 -of

 And the user uses "-o" with a file named "f":

 theapp -of  // Do what now?

 Or,

 -o<filename>
 -of<filename>

 theapp -ofabc  // "-o fabc" or "-of abc"?

 The whole possibility kinda makes me nervous.


 Short options with parameters don't accept bundling, so the problem never
 shows itself.


 This then:

 --xy<filename>
 --xyz<filename>

 theapp --xyzabc  // "--xy zabc" or "-xyz abc"?


The long form with parameters accepts "--name=value" and "--name value" 
but not "--namevalue".

Andrei



 Aug 08 2010