From: Decklin Foster <fosterd@hartwick.edu>
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: rc futures
Date: Thu, 6 Jan 2000 22:45:41 -0500 [thread overview]
Message-ID: <20000106224609.B19379@dillinja> (raw)
In-Reply-To: <Fx4AAIAwUTjePAYA@ltsun0.star.le.ac.uk>; from tjg@star.le.ac.uk on Fri, Dec 10, 1999 at 11:55:06AM -0500
[boy, I'm late replying to this. *don't* ask where i've been...]
Tim Goodwin writes:
> 5. Builtin `echo'. Well, it's not going away :-). There's always the
> compile-time option to omit it...
We could always make echo an optionally-compile-inable builtin /a la/
the stuff in addon.c, and make the people who want it figure out how
to have it be linked in... ;-) Not that *hard*, just annoying.
> 6. Avoid exporting a variable: see below.
Why do we need this? My apologies if this has already been gone over.
I always thought it was some bizzare sh-ism that I was destined never
to understand...
> 10. `$PATH' versus `$path'. I think rc should prefer `$path' if both
> are set. Likewise for `$cdpath' and `$home'.
Ooops. I thought, from reading the manpage, that rc updated $PATH if
something set $path and vice versa? I guess this must not be the case.
> 11. `.' should search `$path'. This will be fixed.
Well, we've had some debate here (and i'm definetly on the `against'
side.) My request is this: bash allows 'source' as a synonym for '.'.
I can make a 'source' function for interactive use, but interactively
I'd just type '.' anyway (it's shorter after all). I just prefer
'source' in shell scripts because it's vastly more readable IMHO.
especially when sourcing a dotfile. And scripts can't pull this
hypothetical function out of my $home/.rcrc, unless i'm mistaken.
> 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.
Great. However, I went to go try to add this and discovered print.c. I
must admit that i'm entirely lost in it. It *seems* to be a copy of
fprintf. Are we actually trying to be portable to systems without a
printf? :-) But seriously, there are some entry points which deal with
this Format structure that i'm not sure of the significance of...
So can anyone lend a hand? I'd really like to grok this code. If you
only reply to one issue in this mail, make it this one.
> 18. Support BSD editline, and clean up the readline, editline, vrl, etc.
> interface if possible. (Suggestion due to Raymond Venneker.)
also a more (intellegent, bloated, take your pick... ;-)) readline
interface. with bash readline can look inside variables and complete
against $PATH if it's the first word, and so on... If I can figure out
how to help with #17 and it gets fixed then I'll take a look at this.
Don't worry, i'll ask if I have to add anything *really* fattening.
> 19. Discard autoconf and automake. I wrote a long message to the
> <9fans> list about some of my objections to autoconf. I have a
> replacement system in the wings.
That'd be nice. One thing I would like is for all code which implements
fixes for low-level stuff that's broken/nonexistent on certain systems
be placed in a separate directory (say lib/). Then write everything
else (i.e. the important rc code) to a sane interface, and bring in
the code that wraps the unsane interfaces inside sane interfaces in as
needed.
> 20. ~ expansion.
I am, of course, biased for this, if only because I haven't actually
used ~ for matching in a script yet... Here's my question. Is there
really anything about '~' (the builtin) that can't be done with an
external program? Why does it get a special glyph indtead of a name
like 'match'? I never use '[' for 'test' when i'm using rc...
Obviously, you can argue that there's nothing at all essential about
using ~ to denote $home, but you have to make a tradeoff somwhere.
> 27. Smaller, faster, cheaper. I don't think rc has any major
> inefficiencies, but I will certainly throw some profiling tools at
> it, to see if there are improvements to be made. In this context,
> "cheaper" means smaller to download, or faster to build.
Don't forget easier to read (as in source code) -- for those of us
struggling to learn.
--
Written with 100% free software. Please support the following websites:
www.noamazon.com www.eviltoy.com www.debian.org www.gnu.org lpf.ai.mit.edu
next prev parent reply other threads:[~2000-01-12 21:13 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
2000-01-07 3:45 ` Decklin Foster [this message]
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=20000106224609.B19379@dillinja \
--to=fosterd@hartwick.edu \
--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).