rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: haahr@adobe.com (Paul Haahr)
To: rc@archone.tamu.edu
Subject: Re: username expansion, gnu readline, and code bloat
Date: Tue, 2 Jul 1991 12:25:08 -0500	[thread overview]
Message-ID: <9107021725.AA00431@roycroft.adobe.com> (raw)

David Hogan writes (excerpted ruthlessly)

> Well, I'll put my vote in.  I think username expansion _should_ be in rc.
> Maybe it should be #ifdef'd, but it should be available.  As for the
> issue of changing the language, well, username expansion need not change
> the language, merely add to it.

adding to it does change it.  #ifdef'ing means there would be different
dialects of the language, which is problematic.  if username expansion
does go into rc (which, as i've said, i strongly argue against) it should
go into all versions.  

> > 	- another special character is a bad idea.  [...]

> You'd get used to it.  After all, ~ is already special in rc.  I mean,
> should we remove ^ from rc because it's a special character?

no, but we shouldn't gratuitously add new lexical tokens.  and what should
be done about the old meaning for ~?  yet another context dependent meaning?
i hope not?

> > 	- what makes this functionality special enough that it
> > 	  should be in the shell itself?  why is username expansion
> > 	  more important than, say, naming specific paths in my
> > 	  home directory, or important system directories?

> What makes shell functions special enough that they should be in the
> shell?  The answer is that they are convenient, and make it possible to
> do things that you couldn't otherwise do.

we agree.  on the other hand, it bothers me that i have to have a shell
script the corresponds to most of my shell functions for when the are
invoked by system().

>					     Just like username expansion.
> Username expansion saves me a lot of time every day, from having to type
> in long pathnames when I want to get to some program that is in someone
> else's bin.  Typing ~user is a way of life!  After 3 years of using shells
> which support it, I would not even consider using one which didn't.

job control is a way of life.  emacs is a way of life.  why is that the
ultimate defense?

>									As
> for the important system directories, well, look at the following lines
> from our passwd file: 

> s:*:7:7:System Source:/usr/src:
> man:*:8:1:0000-Admin(0000):/usr/local/man:
> i:*:11:11:Include Files:/usr/include:

why not
	s=/usr/src
	man=/usr/local/man
	i=/usr/include
and be done with it?  why is a ``user'' the appropriate concept for
this group of files.

> > 	- in general, i don't like ~ expansion because it is not
> > 	  recognized by the kernel; [...]

> Do you then hate backquote expansion because it's not in the kernel?
> What about globbing??  Come on, everybody, lets add globbing to
> the kernel! ;-)  No, symbolic expansion belongs to the shell, whether
> it be metacharacters in filenames or username expansion.

valid point.  but $ expansion and globbing are more general that just
a shorthand for a few specific path names.

> > [i suggest several alternatives:]

> > `{u user}
> Much too awkward to type.  Might as well be typing full pathnames.

agreed.

> > $u/user	# where $u is not a system wide directory
> This would waste more disk space than adding username expansion to
> rc, and waste more time searching the directory than would be used up
> loading the extra bytes in when you run rc.

actually, i doubt it would add much more disk space on any modern unix system
than the 130k cited earlier for yellow pages support.  (i know that you find
yp useless baggage, but sites running large numbers of diskless or dataless
workstations have very few reasonable alternatives.)  besides, the reason to
fear code bloat has little to do with disk space.

> > $user	# where $user is defined in the environment
> On our system, if you did that, you wouldn't have any environment space left.

(is that rc's fault? :-)  it's probably not a good idea to add that much
to your environment, regardless if your machine support it.

> > (1) cartesian products

> Come, come, you can't be serious!  How often are you going to need such
> a feature?  Once in 5 years perhaps?

needed it:  so far, twice since i switched to rc as my full-time shell.  (six
months or so.)  wanted it: a dozen or so times more.  often i do an `{ls|egrep}
or somesuch where ^^ would have been far more convenient.

>					Lets restrict ourselves to putting
> _useful_ features into the shell (such as username expansion -- I use
> this every day) and not some feature that noone will ever need.

> > (2) ranges in variable subscripts
> > (3) backslash escapes

> Both (2) and (3) here are gratuitous changes to the syntax of rc.

you say gratuitous, i say necessary.  you say useful, i say code bloat.
you say no one, i say everyone.  the truth lies somewhere in between.

paul


             reply	other threads:[~1991-07-02 18:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-07-02 17:25 Paul Haahr [this message]
1991-07-04  8:48 ` David Hogan
  -- strict thread matches above, loose matches on Subject: below --
1991-06-30  3:23 Paul Haahr
1991-07-01  9:37 ` Boyd Roberts
1991-07-02  7:03 ` David Hogan

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=9107021725.AA00431@roycroft.adobe.com \
    --to=haahr@adobe.com \
    --cc=rc@archone.tamu.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).