From: malte@TechFak.Uni-Bielefeld.DE
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: Thoughts on a builtin read
Date: Tue, 21 Sep 1993 11:56:15 -0400 [thread overview]
Message-ID: <9309211556.AA20736@dahlie.techfak.uni-bielefeld.de> (raw)
[ rsalz@osf.org wrote ]:
Anyhow, let's take a look at your idea. That is,
x=`foobar
hould set $status to the exit value of foobar. What should
x=foobar
set $status to? Leave it unchanged? What about
x=*
if the directory is empty? And if it isn't? What about
x=/foo/*
when /foo doesn't exist?
Yes, an assignment leaves the status unchanged. Your file name expansion
examples are just a shorthand for
x = `{ glob /foo/* } # glob == echo
Currently, neither "x=*" nor "x=`{ glob *}" sets $status to some reasonable
value, it is just 0 -- always!
You are making a simple shell very complicated, don't you think?
Complicated is your word for it, I'd rather call it more usable. I have
frequently had the problem to distinguish between a failed backquote
command and a command producing no output. There may be better solutions then
this
x = `{ foo || echo '!@#$%^&*()' }
if( ~ $x '!@#$%^&*()' )
...
but it seems to me to be a FAQ. The person who started this thread had
just this problem. I don't mean to offend anybody, but I have the impression
that because Tom Duff invented this shell there can't be anything wrong. But
if one takes a closer look, one sees quite a few sh'isms still in it, e.g
shift. I think rc in its original form and in its current form is an excellent
point to start a shell project. This is why I post all this to this list
and have it discussed instead of just implementing it for myself. Be assured
though, that I very much appreciate different opinions.
Back to the read problem: Currently there is no builtin which assigns
a value to a variable ( except for the special variables of course ).
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. But since I don't care
if some functionality is built into the shell, I'd prefer the
backquote substitution solution.
Malte
next reply other threads:[~1993-09-21 15:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1993-09-21 15:56 malte [this message]
1993-09-21 17:02 ` Chris Siebenmann
-- 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:52 gjv%atlas%cesar
1993-09-21 16:36 Byron Rakitzis
1993-09-21 16:50 ` 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:
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=9309211556.AA20736@dahlie.techfak.uni-bielefeld.de \
--to=malte@techfak.uni-bielefeld.de \
--cc=rc@hawkwind.utcs.toronto.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).