Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.postscript > #3662 > unrolled thread
| Started by | news@zzo38computer.org.invalid |
|---|---|
| First post | 2021-08-01 14:05 -0700 |
| Last post | 2021-08-21 08:31 +0100 |
| Articles | 5 — 3 participants |
Back to article view | Back to comp.lang.postscript
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
| From | news@zzo38computer.org.invalid |
|---|---|
| Date | 2021-08-01 14:05 -0700 |
| Subject | getopt.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]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2021-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]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2021-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]
| From | news@zzo38computer.org.invalid |
|---|---|
| Date | 2021-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]
| From | ken <ken@spamcop.net> |
|---|---|
| Date | 2021-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