Command line options

i love the way the GNU options work, and I don’t want to have to reinvent

We found getopt() to be pretty useless for us internally because of
difficulty dealing with advanced argument systems (+set cddir
/mnt/cdrom, for instance).

Argv does lots of neat stuff.

m.On Tue, May 09, 2000 at 02:06:31PM -0400, Blue Lang wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

hey folks,

i’m looking at porting the GNU getopt() function set to SDL. (from the
GNU fileutils 4.0 package)

i love the way the GNU options work, and I don’t want to have to reinvent
the wheel for option parsing code. getopt is some pretty heavy-duty stuff,
not as in difficult code, but as in, it does a lot of different things and
takes some setting-up in your application.

the beauty of it to me, tho, is how easy it is to read within the
application source itself - in other words, the actual call to
getopt_long() or whatever is very nice to look at and easy to modify.

is anyone working on anything like this, has it been looked at before, is
there already something like it for SDL, etc.

also, does anyone know off the top of your head if that same code will
work under windows? i think it will, it looks pretty straighforward, but i
don’t think i’ve ever compiled anything under windows… :stuck_out_tongue:

thanks,–
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015

Out of curiosity, do people think that this is the kind of thing that
should go into SDL? It seems to me that getopt() should stay in
unistd.h, and people who want to use it may do so as they wish. Parsing
of command line options doesn’t seem like the job of SDL… One of the
things that is so attractive to me about SDL is it’s simplicity and it’s
clarity. If a bunch of utility functions that don’t relate to the goals
of SDL start getting tossed in that will very quickly disappear.

Just my $0.02,
–Ryan

Blue Lang wrote:>

hey folks,

i’m looking at porting the GNU getopt() function set to SDL. (from the
GNU fileutils 4.0 package)

i love the way the GNU options work, and I don’t want to have to reinvent
the wheel for option parsing code. getopt is some pretty heavy-duty stuff,
not as in difficult code, but as in, it does a lot of different things and
takes some setting-up in your application.

the beauty of it to me, tho, is how easy it is to read within the
application source itself - in other words, the actual call to
getopt_long() or whatever is very nice to look at and easy to modify.

is anyone working on anything like this, has it been looked at before, is
there already something like it for SDL, etc.

also, does anyone know off the top of your head if that same code will
work under windows? i think it will, it looks pretty straighforward, but i
don’t think i’ve ever compiled anything under windows… :stuck_out_tongue:

thanks,


Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015

Out of curiosity, do people think that this is the kind of thing that
should go into SDL? It seems to me that getopt() should stay in
unistd.h, and people who want to use it may do so as they wish. Parsing

is there a unistd.h for (the non-gcc) windows compilers? if there is, then
my problem is solved… i guess i just need to dig into some windows code
see how they do it. i just didn’t want to end up with large #ifdef blocks
for something as dumb as command line options.

of command line options doesn’t seem like the job of SDL… One of the
things that is so attractive to me about SDL is it’s simplicity and it’s
clarity. If a bunch of utility functions that don’t relate to the goals
of SDL start getting tossed in that will very quickly disappear.

shrug, it could easily be part of one of the little helper libraries.
(i think that) SDL is as much (in practice) about coding to one API for
multiple OSes as it is about the gfx apis. IMHO, and all that.On Tue, 9 May 2000, Ryan J. Evans wrote:


Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015

i love the way the GNU options work, and I don’t want to have to reinvent

We found getopt() to be pretty useless for us internally because of
difficulty dealing with advanced argument systems (+set cddir
/mnt/cdrom, for instance).

are you referring to the “unix” getopt() or the GNU getopt()?

actually, i see what you’re saying, even the gnu one (without
extending it) only has space allocated in the ‘opt’ struct for one
argument per option - but it would be really easy to extend.

Argv does lots of neat stuff.

this looks like ‘write your own damn parser and like it.’ :slight_smile: so i guess
the general consensus thus far is that SDL is a bad place for this?On Tue, 9 May 2000, Michael Vance wrote:

On Tue, May 09, 2000 at 02:06:31PM -0400, Blue Lang wrote:


Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015

are you referring to the “unix” getopt() or the GNU getopt()?

GNU.

actually, i see what you’re saying, even the gnu one (without
extending it) only has space allocated in the ‘opt’ struct for one
argument per option - but it would be really easy to extend.

That’s the first line of a very long slide into writing your own
library :slight_smile:

this looks like ‘write your own damn parser and like it.’ :slight_smile: so i guess
the general consensus thus far is that SDL is a bad place for this?

Well, Argv is an actual library out there for doing argument parsing,
from Gray Davis the guy who did dmalloc. It’s very flexible.

m.On Tue, May 09, 2000 at 03:26:08PM -0400, Blue Lang wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire