rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Chris Siebenmann <cks>
To: rc
Subject: Re: rc futures
Date: Tue, 14 Dec 1999 19:17:11 -0500	[thread overview]
Message-ID: <99Dec15.032252est.25059@hawkwind.utcs.utoronto.ca> (raw)
In-Reply-To: tjg's message of Fri, 10 Dec 1999 11:55:06 -0500. <Fx4AAIAwUTjePAYA@ltsun0.star.le.ac.uk>

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

 I disagree for the already stated reasons. $PATH is standard on Unix;
when rc starts, if $PATH and $path disagree, something has fiddled with
$PATH and expects the fiddling to be respected. Similarly for $HOME
and $home.

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

 If Plan 9 rc doesn't, I don't think we should either.

| 16. Make `*' match files beginning with `.' (except `.' and `..', of
| course).  This is something of a religious question, but my feeling is
| that special treatment of "dot files" is a mistake.  (Suggestion ditto.)

 This might be a good idea in a new shell, or for rc on a new system
(without the cultural history of dotfiles).

 I think it is a really bad idea for an existing shell on an existing
system, for all the obvious reasons. I would never run a version of
rc that behaved this way here.

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

 My personal opinion is that rc should report errors in a shell script
marked both with rc's name and with the script's name (so that it is
obvious that it is a syntax error in the script, and not an error
message being emitted by the script).

 I think rc should retain its current way of reporting the exit status
of commands run directly from an interactive session.

 Whether rc should print 'rc: ' in front of syntax errors during
interactive sessions seems like a religious issue. In the name of
minimalism, I'd vote no.

	- cks


  parent reply	other threads:[~1999-12-15  8:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2000-01-07  3:45 ` Decklin Foster
2000-01-01  4:20   ` Paul Haahr
2000-01-15  8:58     ` Steve Kilbane
1999-12-13 12:55 Elliott Hughes
1999-12-14  9:44 Byron Rakitzis
1999-12-15 16:32 Russ Cox
1999-12-16 12:43 Smarasderagd
1999-12-19 11:06 ` Steve Kilbane
1999-12-22  0:00   ` Christopher Vance
1999-12-16 16:40 Chet Ramey
2000-01-03 15:46 Bengt Kleberg
2000-01-12 14:22 Bengt Kleberg
2000-01-12 21:34 Chet Ramey
2000-01-01  2:55 ` Paul Haahr
2000-01-14 12:16 Bengt Kleberg
2000-01-14 12:20 Bengt Kleberg

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=99Dec15.032252est.25059@hawkwind.utcs.utoronto.ca \
    --to=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).