From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pantransit.reptiles.org ([209.157.133.146]) by hawkwind.utcs.utoronto.ca with SMTP id <24961>; Sun, 19 Dec 1999 02:25:08 -0500
Received: (qmail 10638 invoked by uid 204); 16 Dec 1999 12:43:13 -0000
Date:	Thu, 16 Dec 1999 07:43:13 -0500
Message-ID: <19991216124313.10637.qmail@pantransit.reptiles.org>
From:	"Smarasderagd" <smarry@vex.net>
To:	rc@hawkwind.utcs.toronto.edu, tjg@star.le.ac.uk
Subject: Re: rc futures

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!