rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: "Smarasderagd" <smarry@vex.net>
To: rc@hawkwind.utcs.toronto.edu, tjg@star.le.ac.uk
Subject: Re: rc futures
Date: Thu, 16 Dec 1999 07:43:13 -0500	[thread overview]
Message-ID: <19991216124313.10637.qmail@pantransit.reptiles.org> (raw)

Tim Goodwin <tjg@star.le.ac.uk> writes:
>4. `shift' only works on `$*'. This could be fixed, but it's not hard to
>write a function that can shift any variable (except one).  Suggested
>fix is to the documentation: include the `anyshift' function, and remove
>this "bug".

>7. `$^var' to join with an arbitrary separating character.  Again, this
>is easy to fake with a function when needed.

I prefer the latter option for both of these, given the simplicity of the
workarounds and the lapse of time since the last argument about it.

>10. `$PATH' versus `$path'.  I think rc should prefer `$path' if both
>are set.  Likewise for `$cdpath' and `$home'.

Ditto previous objections.  Any sh/perl/etc. script that thinks it only
needs to update PATH/HOME and happens to run an rc script would break.

>11. `.' should search `$path'.  This will be fixed.

I'd be reluctant to possibly break scripts that assume that they can
source a file from the current directory even if "." isn't in $path.

>12. Extra parentheses around `~' and `!' are syntax errors (you'll
>have to get rc-1.6b2 to see what this is about).  I suspect that these
>"surprising" special cases can be fixed with minor tweaks to the
>grammar.  (Suggestion due to Bengt Kleberg.)

I agree with Byron; the current behaviour is the correct consequence of
the syntax, not a bug.

>13. Add the `flag' builtin as described in this document.  (I've
>considered a few "improved" versions of this, but I think the original
>specification is pretty much spot on.)
>
>     http://www.star.le.ac.uk/~tjg/rc/misc/td.html

Since, with the possible exception of -x, there aren't any flags you'd
want to turn on and off during the execution of a script, I don't know
if there's any point to this.

>14. Add a command line flag that means "don't export any variables".
>(Any suggestions for a mnemonic letter?)  This is fairly useless on
>the command line, but in conjunction with `flag' solves bug 6 neatly.
>(Actually, the flag will probably mean "don't export any variables,
>except those set in temporary assignments", which is rather more
>useful.)

I once ran into a problem with a slide-show script which blew up
because the shell variable holding the list of images to display took
the environment past Linux's size limit for execve() and friends.
I fixed the problem pretty simply, and haven't run into it again,
but I can imagine situations where it isn't so easily avoided and the
limitation is more frustrating.

It's not entirely clear what it means to 'not export' a variable, though.
Do we make it available only to the current invocation of the shell, and
not to explicit subshells invoked via '@{ ... }', but still provide it
to other subshells, such as in pipelines?  I think it'd be worse to create
a peculiar class of variables with a list of exceptions which make sense
only if you know about the implementation.

>15. Fake bidirectional pipes on systems where `pipe()' produces a
>unidirectional pipe, but `socketpair()' exists.  (Suggestion due to
>Charles Forsyth, via John Murdie.)

I'm not sure how useful this is, given that many utilities and the C/C++
library generally make sweeping assumptions that break badly when you
try to make them interact through anything other than a (pseudo-)tty.
The only application I can think of offhand is testing network software.

I'd favour providing some helper program(s) for setting up bidirectionally
connected programs and/or pipelines.

>17. Improved error reporting, as discussed on the list recently.  Also,
>I intend that rc should prefix its errors with `rc: '; the long standing
>Unix tradition that shells are special in this regard is not very
>useful, I think.

I tend to think prefixing errors with 'rc:' in interactive sessions is
ugly, though it might have saved me some confusion in the past (I was
trying to run "host" on a system where it wasn't installed, and began
to think that DNS was down because I got "host not found" on every query...)

>18. Support BSD editline, and clean up the readline, editline, vrl, etc.
>interface if possible.  (Suggestion due to Raymond Venneker.)

As a 9term user, I mostly want to thrash out the old 'history' utility
so that it compiles reliabily with optimization and doesn't sometimes
skip lines with a lot of hyphens in them.

>22. Add a `sigeof' function, which is invoked when rc sees EOF on
>standard input when it's a terminal device.  If sigeof returns 1, rc
>attempts to continue reading from standard input.
>
>    fn sigeof { echo 'Type `exit'' to leave the shell' >[1=2]; return 1 }
>
>(Suggestion due to Mark K Gardner.)

I desired this briefly when I wanted to prevent accidentally logging
out my console window, but I found that

while () {. -i /dev/tty; echo NO NO NO NO}

did the job for me.  You can insert the continue-or-exit logic of your
choice in place of the "NO" bit.

>28. That's all for now, folks!


             reply	other threads:[~1999-12-19  7:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-16 12:43 Smarasderagd [this message]
1999-12-19 11:06 ` Steve Kilbane
1999-12-22  0:00   ` Christopher Vance
  -- strict thread matches above, loose matches on Subject: below --
2000-01-14 12:20 Bengt Kleberg
2000-01-14 12:16 Bengt Kleberg
2000-01-12 21:34 Chet Ramey
2000-01-01  2:55 ` Paul Haahr
2000-01-12 14:22 Bengt Kleberg
2000-01-03 15:46 Bengt Kleberg
1999-12-16 16:40 Chet Ramey
1999-12-15 16:32 Russ Cox
1999-12-14  9:44 Byron Rakitzis
1999-12-13 12:55 Elliott Hughes
1999-12-10 16:55 Tim Goodwin
1999-12-13 18:54 ` Paul Haahr
2000-01-04 16:43   ` Tim Goodwin
1999-12-31 23:26     ` Paul Haahr
1999-12-15  0:17 ` Chris Siebenmann
2000-01-07  3:45 ` Decklin Foster
2000-01-01  4:20   ` Paul Haahr
2000-01-15  8:58     ` Steve Kilbane

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=19991216124313.10637.qmail@pantransit.reptiles.org \
    --to=smarry@vex.net \
    --cc=rc@hawkwind.utcs.toronto.edu \
    --cc=tjg@star.le.ac.uk \
    /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).