rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: John Mackin <mackin@vast.eecs.unsw.oz.au>
To: The rc Mailing List <rc@archone.tamu.edu>
Subject: Re: how to 'getopts' in rc
Date: Fri, 6 Sep 1991 08:01:10 -0500	[thread overview]
Message-ID: <9109062301.4705.rc.babad@vast.eecs.unsw.oz> (raw)
In-Reply-To: <9109051902.AA00517@dahlie.techfak.uni-bielefeld.de>

Could anyone on the list who wants to send me mail privately please
note my new address.  The address I was at previously is no longer
valid (and I mean that -- it will not forward).

Malte asks:

    How would you do it in rc or should getopts be a rc builtin?

Well, I think no one on the list would seriously campaign to have a
getopts builtin (at least, I _sincerely hope_ no one would).  It would
be easy, if a little tedious, to code up a getopts rough-equivalent;
one could either take an approach of doing most of the work in rc,
or of making it a function that wrapped around getopt(1) (which is
easily available in the public domain) and got that to do most of
the work.

But hey!  This is rc!  Why hamstring ourselves with old-style interfaces,
when we can do much cuter things -- things that were only _theoretically_
possible in sh, since in any attempt to implement them in practice,
the quoting would have gotten totally out of control.

I have in mind a function along the following rough lines:

	* = ` { getopts opt1 'code1' opt2 'code2' ... - $* }

where each fragment of rc code gets executed if the corresponding
option is present.  The assignment to * is necessary, since a function
can't affect the $* of the enclosing level.  So, for example, if
you have options x and q, and option f that takes an option argument,
you might write:

	* = ` { getopts x 'dashx = true' q 'dashq = true' \
			f: 'dashf = $optarg' - $* }

I think that's a much nicer interface than the getopt(1) style
supported by the getopts builtin, mainly because the option letter and the
code for the option are right next to each other.  I haven't coded this
up in rc (I'm unemployed right now, and I don't have much computer
access), but I don't see any reason why it should be at all difficult.

The only thing that's not perfectly nice, in my view, about this
is the fact you have to explicitly pass $*, and explicitly assign to
it; that, however, is the price that must be paid for getopts not
being a builtin, and I am sure we are all quite willing to pay it.

OK,
John.


  reply	other threads:[~1991-09-06 13:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-09-05 19:02 malte
1991-09-06 13:01 ` John Mackin [this message]
1991-09-09 18:45 malte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9109062301.4705.rc.babad@vast.eecs.unsw.oz \
    --to=mackin@vast.eecs.unsw.oz.au \
    --cc=rc@archone.tamu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).