I wrote a PostScript program for parsing command-line switches similar to
how the getopt function of UNIX is doing. I might use it myself in some of
my own programs, but it might be useful for other programmers to use, too.
You can also tell me if you have a suggestion for improvement, too.

Long option parameters without = are not implemented, and it will always
use the POSIXLY_CORRECT kind of parsing.

***BEGIN***

% PostScript code for parsing command-line arguments
% (public domain)

<< /V [0 0] /L ARGUMENTS length >> begin
/D exch def
/G {//D 1 index known {//D exch get} {clear //D /Error get exec stop} ifelse} def
/T <<
/N {
% No value
exch pop //null exch exec
} bind
/O {
% Optional value
//V 1 get 3 -1 roll 1 add 1 index length 1 index sub getinterval
dup () eq {pop //null} if
exch exec exit
} bind
/R {
% Required value
//V 1 get 3 -1 roll 1 add 1 index length 1 index sub getinterval
dup () eq {
pop //V 0 get 1 add //V 0 2 index put
//ARGUMENTS length 1 index eq {//G 5 get exec} if
//ARGUMENTS exch get
} if
exch exec exit
} bind
>> def
{ {
//V 0 get //L ge {exit} if
//ARGUMENTS //V 0 get get
dup length 2 lt {pop exit} if
dup (--) eq {pop //V 0 //V 0 get 1 add put exit} if
dup 0 get 45 ne {pop exit} if
dup 1 get 45 eq {
% Long option
(=) search {
exch pop //G exec exec
} {
//G exec //null exch exec
} ifelse
} {
% Short option
//V 1 2 index put
1 exch 1 exch length 1 sub {
//V 1 get 1 index 1 getinterval //G exec
dup 1 get dup type /nametype eq //G if
exch 0 get //T exch get exec
} for
} ifelse
//V 0 //V 0 get 1 add put
} loop
//userdict /ARGUMENTS //ARGUMENTS //V 0 get //L 1 index sub getinterval put
} end bind exec

***END***

--
Don't laugh at the moon when it is day time in France.

On Sunday, August 1, 2021 at 4:03:18 PM UTC-5, ne...@zzo38computer.org.invalid wrote:
> I wrote a PostScript program for parsing command-line switches similar to
> how the getopt function of UNIX is doing. I might use it myself in some of
> my own programs, but it might be useful for other programmers to use, too.
> You can also tell me if you have a suggestion for improvement, too.
>
> Long option parameters without = are not implemented, and it will always
> use the POSIXLY_CORRECT kind of parsing.
>
> ***BEGIN***
>
> % PostScript code for parsing command-line arguments
> % (public domain)

I think this is interesting code (and it's great to see people writing PS!).
But I'm not sure if it's actually very useful. If you're using ghostscript,
you can combine the ARGUMENTS form with -D definitions, so you
don't really need to parse any option style syntax from the ARGUMENTS
list. Just define those with -D and use ARGUMENTS for strings
or filenames or whatever.

I started a thread recently listing every way I could think of to pass
arguments into a PS program. Lots of them can be combined.
You can even define parameters with regular PS code and concatenate
the files before processing.

On Thursday, August 5, 2021 at 1:17:44 AM UTC-5, luser droog wrote:
> On Sunday, August 1, 2021 at 4:03:18 PM UTC-5, ne...@zzo38computer.org.invalid wrote:
> > I wrote a PostScript program for parsing command-line switches similar to
> > how the getopt function of UNIX is doing. I might use it myself in some of
> > my own programs, but it might be useful for other programmers to use, too.
> > You can also tell me if you have a suggestion for improvement, too.
> >
> > Long option parameters without = are not implemented, and it will always
> > use the POSIXLY_CORRECT kind of parsing.
> >
> > ***BEGIN***
> >
> > % PostScript code for parsing command-line arguments
> > % (public domain)
> I think this is interesting code (and it's great to see people writing PS!).
> But I'm not sure if it's actually very useful. If you're using ghostscript,
> you can combine the ARGUMENTS form with -D definitions, so you
> don't really need to parse any option style syntax from the ARGUMENTS
> list. Just define those with -D and use ARGUMENTS for strings
> or filenames or whatever.
>
> I started a thread recently listing every way I could think of to pass
> arguments into a PS program. Lots of them can be combined.
> You can even define parameters with regular PS code and concatenate
> the files before processing.

Another way which could be cool is use -c "(some)(options)" and just
leave stuff on the stack. The program can then use

count 0 ne {
...
} if

to check for and process optional parameters.

luser droog <luser.droog@gmail.com> wrote:
> I think this is interesting code (and it's great to see people writing PS!).
> But I'm not sure if it's actually very useful. If you're using ghostscript,
> you can combine the ARGUMENTS form with -D definitions, so you
> don't really need to parse any option style syntax from the ARGUMENTS
> list. Just define those with -D and use ARGUMENTS for strings
> or filenames or whatever.

While that is true, I don't really like -d and -s for your own program's
options; the -d and -s are for setting the options of Ghostscript itself
(such as specifying what file or printer to use for graphical output, and
some other options).

--
Don't laugh at the moon when it is day time in France.

In article <1628187236.bystand@zzo38computer.org>,
news@zzo38computer.org.invalid says...
> While that is true, I don't really like -d and -s for your own program's
> options; the -d and -s are for setting the options of Ghostscript itself
> (such as specifying what file or printer to use for graphical output, and
> some other options).

Although that is what they do, it's not the case that they are intended
to be specific to Ghostscript internals.

Most command line options, including the ones processed by Ghostscript,
are stored in systemdict and are available for use by PostScript
programs.

A number of the example/utility PostScript programs supplied with
Ghostscript make use of parameters passed to the program on the command
line.

Ken