Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.postscript > #3662 > unrolled thread

getopt.ps

Started bynews@zzo38computer.org.invalid
First post2021-08-01 14:05 -0700
Last post2021-08-21 08:31 +0100
Articles 5 — 3 participants

Back to article view | Back to comp.lang.postscript


Contents

  getopt.ps news@zzo38computer.org.invalid - 2021-08-01 14:05 -0700
    Re: getopt.ps luser droog <luser.droog@gmail.com> - 2021-08-04 23:17 -0700
      Re: getopt.ps luser droog <luser.droog@gmail.com> - 2021-08-06 22:15 -0700
      Re: getopt.ps news@zzo38computer.org.invalid - 2021-08-20 13:14 -0700
        Re: getopt.ps ken <ken@spamcop.net> - 2021-08-21 08:31 +0100

#3662 — getopt.ps

Fromnews@zzo38computer.org.invalid
Date2021-08-01 14:05 -0700
Subjectgetopt.ps
Message-ID<1627849972.bystand@zzo38computer.org>
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.

[toc] | [next] | [standalone]


#3664

Fromluser droog <luser.droog@gmail.com>
Date2021-08-04 23:17 -0700
Message-ID<0ac2aeb1-c2b3-4253-a90c-04c299ecb13fn@googlegroups.com>
In reply to#3662
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.

[toc] | [prev] | [next] | [standalone]


#3665

Fromluser droog <luser.droog@gmail.com>
Date2021-08-06 22:15 -0700
Message-ID<961a28df-ed55-4d49-a876-9d297bc2d1fcn@googlegroups.com>
In reply to#3664
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.

[toc] | [prev] | [next] | [standalone]


#3666

Fromnews@zzo38computer.org.invalid
Date2021-08-20 13:14 -0700
Message-ID<1628187236.bystand@zzo38computer.org>
In reply to#3664
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.

[toc] | [prev] | [next] | [standalone]


#3669

Fromken <ken@spamcop.net>
Date2021-08-21 08:31 +0100
Message-ID<MPG.3b8abc325e5daf6b9898ca@usenet.plus.net>
In reply to#3666
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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.postscript


csiph-web