rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: gjv%atlas%cesar@crbca1.SINet.SLB.COM
To: rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar.
Subject: Re: Thoughts on a builtin read
Date: Tue, 21 Sep 1993 12:52:34 -0400	[thread overview]
Message-ID: <9309211656.AA00816@SINet.SLB.COM> (raw)
In-Reply-To: Your message of "Tue, 21 Sep 1993 17:57:14 +0200."

[Malte wrote:]
 |[ rsalz@osf.org wrote ]:
 |    set $status to?  Leave it unchanged?  What about
 |            x=*
 |    if the directory is empty?  And if it isn't? What about

This sets x to '*', no error whatsoever.

 |            x=/foo/*
 |    when /foo doesn't exist?

This sets x to '/foo/*', again no error.

 |Yes, an assignment leaves the status unchanged. Your file name expansion
 |examples are just a shorthand for
 |	x = `{ glob /foo/* }	# glob == echo

I agree on this, It would be nice if the status reflects the result of
the evaluation of the right-hand side, not that of the assignment itself.

If you 'redefine' $status this way, it is also possible to save and
restore its value, something you currently can't (see my earlier mail
on the problems with $status and the prompt function).

The only problem here may be the following:

	; a=(b c)
	; $a="foo"
	multi-word variable name
	; echo $status

However, an rc-script aborts if you try this, so you can't check $status

 |There's been a discussion on shift shifting arbitrary lists with the
 |proposed syntax being "shift x 2" probably because "x = `{ shift x 2 }"
 |isn't too elegant. If this makes its way into rc, I don't mind if read
 |expects a variable as a command line parameter.

As Chris said, a `BUILTIN currently always forks, which is a disadvantage
of an implementation like "x=`{shift x 2}" or "x=`{read a; echo $a}" in order
to get a set of words in 'x'.

And since the $$<var-name> construction already allows a function like
'append x (a b c)' in order to modify the variable 'x', a 'read x'
or 'shift x 2' is not introducing something new.

Personally, I think that

	s = shift 2 $s
	s = shift 2 (what ever list)
	l = read
	l2 = read [1=3]		# would this read from descriptor 3 ?

would also be quite elegant, avoiding the builtins taking variable
names. But as mentioned above, this causes problems with the current
implementation of $status.


J.G. Vons   E-Mail: vons@cesar.crbca1.sinet.slb.com

             reply	other threads:[~1993-09-21 16:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-09-21 16:52 gjv%atlas%cesar [this message]
  -- strict thread matches above, loose matches on Subject: below --
1993-09-22 17:18 Steve_Kilbane
1993-09-21 17:26 Arnold Robbins
1993-09-21 17:11 rsalz
1993-09-21 16:58 Arnold Robbins
1993-09-21 16:36 Byron Rakitzis
1993-09-21 16:50 ` Chris Siebenmann
1993-09-21 15:56 malte
1993-09-21 17:02 ` Chris Siebenmann
1993-09-21 15:54 Tom Culliton x2278
1993-09-21 15:15 Alan Watson
1993-09-21 15:09 rsalz
1993-09-21 14:33 malte
1993-09-21 14:20 rsalz
1993-09-21  6:51 malte
1993-09-21 14:19 ` Chris Siebenmann
1993-09-20 22:11 Tom Culliton x2278

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:

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

  git send-email \
    --in-reply-to=9309211656.AA00816@SINet.SLB.COM \
    --to=gjv%atlas%cesar@crbca1.sinet.slb.com \
    --cc=rc%hawkwind.utcs.toronto.edu%m_internet%m_mailnow%hermes.DECnet@cesar.sedalia.sinet.slb.com \
    --cc=vons@cesar.crbca1.sinet.slb.com \


* 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).