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!
next 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).