new list subscriber

new list subscriber

[Byron Rakitzis]

From hawkwind.utcs.toronto.edu!cks Thu Aug 22 19:57:54 1991
To: byron@archone.tamu.edu
Subject: early reaction(s) to rc
Date: Thu, 22 Aug 1991 19:57:11 -0500
From: Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>

- the elegance is nice. I'll have to see how much I can simplify my
  environment with it as my login shell (probably a fair bit).
- with 1.1gamma at least, commands are placed into history too soon;
  commands should be put there after execution, not before. Putting
  them there before makes it impossible to get -p to print the last
  command executed, among other things.
- it might be nice to define another pseudo-signal, call it SIGSTARTUP,
  along the lines of SIGEXIT. If SIGSTARTUP is always executed, there
  should be some way of telling whether or not a shell is interactive.
  This would let people make their root prompts something arbitrary,
  for example (after a few slips, I insist on having the machine name
  in mine).

 Feel free to forward these to the mailing list and to put me on it.

	- cks

Re: early reaction(s) to rc

[John Mackin]

Hi, Chris, welcome to the rc list.  I am puzzled by some of your comments,
and would like to ask you to expand on them.

    - it might be nice to define another pseudo-signal, call it SIGSTARTUP,
      along the lines of SIGEXIT.

Now, the clear advantage of a fake "the shell has just started" signal is
that it gives you a way (assuming that you can manage to import the
function in the environment, as you always can if the process is just
being spawned, and as you probably can if it is being started remotely
by some type of daemon like say rshd) to execute something at shell
initialisation time _regardless of whether the shell is a login shell
or not_, and without the disgusting (both aesthetically and practically)
overhead of an initialisation file per (every) shell, like .cshrc.
I like the idea in the abstract, although I would want to think of
some worthwhile concrete applications for it before I would lobby for
its inclusion in rc -- I do not mean to suggest that there do not
exist such; rather, at the moment I just don't have time to consider
the matter at any length.  (On a point of pure gustation, I do have to
say I don't like the name much -- but on the other hand I can't think of
a better one right now either: the obvious sigbegin doesn't appeal,
and sigenter (as the antonym of sigexit) doesn't sound right either.
Suggestions, any rcer's?)

      If SIGSTARTUP is always executed, there should be some way of
      telling whether or not a shell is interactive.  This would let
      people make their root prompts something arbitrary, for example
      (after a few slips, I insist on having the machine name in
      mine).

sigstartup, clearly, should always be executed.  In the other direction
lies zsh :).

As a quite separate issue I'd like to address the question of telling
whether or not the shell is interactive.  sh has $-, and $- has many
puzzling bugs, and inconsistencies between different versions of sh;
these render a very pleasing concept very hard to use in practice.
(For those of you who might not have come from an sh background,
$- is supposed to contain exactly those `Boolean' command-line
flags that are currently in effect; so e.g. if -e and -v were true,
$- would be "ev".)  I like this idea, and think it should be
extended; I think there should be no `variables' that are accessible
_from outside the shell source_, that is to someone using rc,
that can't be examined and, if appropriate, set, by rc.  So,
for example, if -i is true (either explicitly from argv, or
by implication), that should be testable from within rc, somehow.
I have no syntax in mind at the moment.

I also said "if appropriate, set"; I am not happy about the fact
that rc has no "set" builtin (or equivalent mechanism).  Byron, in
the eventual revamp of rc -x, you might like to consider that it
is not at all unreasonable to want to turn -x off and on at different
points during execution.  Clearly it's meaningless to suggest
setting -l, but a case (perhaps a weak one) can be made for setting -i
and -d, and -v and -e are fine candidates for toggling during the
life of the shell.  As well (and this is one of my beefs with sh's $-)
I'd like the same mechanism, whatever it is, to say -c was true if the
shell was currently executing a command from a -c argument: I needed
that once, with sh.

Now after that digression, let's return to Chris's comments:

      If SIGSTARTUP is always executed, there should be some way of
      telling whether or not a shell is interactive.  This would let
      people make their root prompts something arbitrary, for example
      (after a few slips, I insist on having the machine name in
      mine).

This is what I fail to follow; I don't understand why one needs to tell
whether or not the shell is interactive in order to accomplish the goal
of making a root prompt be something arbitrary.  The best shot I have had
so far at understanding this is that perhaps, Chris, you are an ex-csh
user (in which case may I offer you my heartiest congratulations), and
are inappropriately extrapolating csh experiences into the rc arena.
Indeed, because csh is such a terrible program, it _is_ necessary to know
whether or not the shell is interactive before one sets the prompt (since
the damn-fool thing doesn't import the prompt from the environment,
_and uses whether or not it has a non-null value as the criterion for
deciding whether to print it_ -- so that willy-nilly setting the prompt
in .cshrc results in prompts from non-interactive shells -- gaaack!!).

I have some further comments about the idea of root prompt, su, and
the sigstartup proposal, but I will defer them; this is long enough now
and I would like to know what Chris really meant before going on.

Happy rc'ing all!

OK,
John.

Re: early reaction(s) to rc

[Chris Siebenmann]

[This is part 1 of N parts of stuff; more to come as I digest and
comment on my pile of email.]

John writes:
| This is what I fail to follow; I don't understand why one needs to tell
| whether or not the shell is interactive in order to accomplish the goal
| of making a root prompt be something arbitrary.

 Figuring out what the root prompt should be may take a significant
number of (potentially expensive) operations; I'd like to do it only
when necessary, to avoid the performance hit.

 In hindsight, setting the root prompt was a bad example of per-shell
startup actions. A much better one for people with windowing systems
is arranging a per-window history, something that is highly useful
(especially for me, as just specifying a global history file seems to
result in all sorts of interesting jumbling up of stuff). For X, one
can almost get there cheaply with a prompt function, but it's not
quite close enough (and going the final step is expensive; you need to
check what your current tty is, which is not something I want to do
for every prompt).

	- cks

Re: early reaction(s) to rc

[Arnold D. Robbins]

> (On a point of pure gustation, I do have to
> say I don't like the name much -- but on the other hand I can't think of
> a better one right now either: the obvious sigbegin doesn't appeal,
> and sigenter (as the antonym of sigexit) doesn't sound right either.
> Suggestions, any rcer's?)

Shorten it to SIGSTART.

> As a quite separate issue I'd like to address the question of telling
> whether or not the shell is interactive.  sh has $-, and $- has many
> puzzling bugs, and inconsistencies between different versions of sh;
> these render a very pleasing concept very hard to use in practice.

My $.02:

	$options is a list of (sorted?) command line options
	that are in effect:

	; echo options are: $options
	options are: -i -n -x

This makes it easy to see what's turned on, although turning things
on and off one at a time is harder, in both rc programs and inside rc itself.

This is the start of an idea, anyway; I acknowledge it's not full blown.

> I have some further comments about the idea of root prompt, su, and
> the sigstartup proposal,

Byron has told me in private mail he doesn't think the shell should
automatically change prompts for root.  I disagree, but not terribly
strongly.  My own suggestion for a root prompt would be ';; '.

Arnold Robbins -- The Basement Computer		| Laundry increases
Internet: arnold@skeeve.ATL.GA.US		| exponentially in the
UUCP:	{ gatech, emory }!skeeve!arnold		| number of children.
Bitnet:	Forget it. Get on a real network.	|    -- Miriam Robbins

Re: early reaction(s) to rc

[Chris Siebenmann]

Arnold writes:
| Byron has told me in private mail he doesn't think the shell should
| automatically change prompts for root.  I disagree, but not terribly
| strongly.  My own suggestion for a root prompt would be ';; '.

 If rc is going to automatically change my prompt when I'm root, I
should darn well be able to tell it what to. How about prompt(3) and
prompt(4), if present?

 It isn't truly necessary, as one can always play around with a prompt
function that checks for various indications of root-ness (the cheap
one I've used before is a HOME of /).

	- cks

Re: early reaction(s) to rc

[DaviD W. Sanderson]

> the matter at any length.  (On a point of pure gustation, I do have to
> say I don't like the name much -- but on the other hand I can't think of
> a better one right now either: the obvious sigbegin doesn't appeal,
> and sigenter (as the antonym of sigexit) doesn't sound right either.
> Suggestions, any rcer's?)

How about "sigmain", analogous to the entry function for C programs
(and nicely parallel to "sigexit".) Unfortunately not all the special
functions in rc have names beginning with "sig", though they would if
"prompt" were changed to "sigprompt".  This would allow a useful
convention: ``all special functions in rc have names beginning with
"sig"''.

> As a quite separate issue I'd like to address the question of telling
> whether or not the shell is interactive.  sh has $-, and $- has many

I have suggested to Byron making the rc flags available in a special
variable.  I think the Plan 9 rc does this, but I don't have my docs
handy to check.

> that rc has no "set" builtin (or equivalent mechanism).  Byron, in
> the eventual revamp of rc -x, you might like to consider that it
> is not at all unreasonable to want to turn -x off and on at different
> points during execution.

Yes, I think it would be useful to be able to toggle certain
command-line switches.  Often I am interested in debugging only part of
a script, and being able to selectively turn on -x has helped in sh.
I dunno what a reasonable syntax might be.

> This is what I fail to follow; I don't understand why one needs to tell
> whether or not the shell is interactive in order to accomplish the goal
> of making a root prompt be something arbitrary.

There is another possible application:  I might want to remove
something from the environment if the shell is NOT interactive.
This could be a way (albeit a bit clumsy) to get around the fact
that all variables are exported into the environment.

DaviD W. Sanderson (dws@cs.wisc.edu)

Re: early reaction(s) to rc

[Boyd Roberts]

    I have suggested to Byron making the rc flags available in a special
    variable.  I think the Plan 9 rc does this, but I don't have my docs
    handy to check.

I've been thinking about `rcmain' for a while here Byron.  It gets executed
on every rc invocation.  It cleans up a lot of bad gore to do with
interactiveness, because the command line option processing is done in
this global rc script.  I spoke to Duff about it, I know you think it's
hideous, but it's a lot cleaner than special:

  - signals
  - variables
  - braindamage

You don't want `set' in rc.  You have arrays already, and with the trivial
number of options available, there's no point in going `set -x' or whatever.

For gods sake lets keep the shell stable, and concentrate on getting
the bugs out and _not_ the options in!

Duff told me:

    rcmain does the flags that affect initialization, to wit:
          -p      `protected' -- don't read functions, set path=(. /bin)
          -c      execute a command given on the command line
          -i      `interactive' -- print prompts for commands
          -l      `login shell' -- read $home/lib/profile before user's commands

I think it's a really neat idea.  We should do it.  It also solves a headache
I have here with DEC X invoking rc with this braindamaged `-s' option when i
log in -- gag.

Re: early reaction(s) to rc

[Arnold D. Robbins]

> Duff told me:
> 
>     rcmain does the flags that affect initialization, to wit:
>           -p      `protected' -- don't read functions, set path=(. /bin)
>           -c      execute a command given on the command line
>           -i      `interactive' -- print prompts for commands
>           -l      `login shell' -- read $home/lib/profile before user's commands

I would love to know how this works.  -c is trivial:

	eval $*(2) ; exit

and so is -l, but -p and -i are harder --- is there some secret equivalent
of `set' in his rc?  In other words, how does the rc program tell the
shell itself what to do with the environment and whether or not to prompt?

Thanks,

Arnold

Re: early reaction(s) to rc

[John Mackin]

Arnold writes, in relation to rcmain:

    I would love to know how this works.  -c is trivial:

    	eval $*(2) ; exit

    and so is -l, but -p and -i are harder --- is there some secret equivalent
    of `set' in his rc?  In other words, how does the rc program tell the
    shell itself what to do with the environment and whether or not to prompt?

I second the first comment; for quite a while I've wanted to have a look
at a real Tenth Edition (as opposed to Plan 9, if there is a difference)
rcmain.  Boyd, do you reckon if you ask td to mail you one, he will?  I
have some general comments to make about rcmain which I will send later
today, right now I have to get off to work -- but I just thought I should
point out that -p doesn't require any support beyond what our rc already
has:

eval `{ whatis | rev | sed -n -e '/ nf$/s/^.*{\(.*\)$/\1/p' | rev }

You can't really do without the two rev's, since there's no way to be
sure your r.e. is matching the function name correctly if you try that
(consider that function names, if quoted, may contain both space and
left-curly-bracket).  But that certainly does the job of removing
functions from the environment.  (Of course, in a real rcmain, all
the commands above -- eval, whatis, rev, sed, and rev -- would be
prefixed by `builtin' to avoid being subverted by functions before
they could accomplish the task of deleting them.  I have omitted this
here for clarity.)

OK,
John.

Re: early reaction(s) to rc

[John Mackin]

I wrote:

    eval `{ whatis | rev | sed -n -e '/ nf$/s/^.*{\(.*\)$/\1/p' | rev }

    You can't really do without the two rev's, [...]

Apologies to all on the list, I must've been drunk :).  Sheesh, do I
feel like a silly person; the above, of course, _still_ doesn't work
in the presence of function names containing {.  Anyway it can be done,
but I don't have time now to fully test an implementation, and rather
than mail another implementation that isn't fully tested, I'll just
describe how to write the sed:

- any line beginning with "fn " either does or doesn't begin with "fn '"
- if it doesn't, then the function name terminates at the second
  space character on the line
- if it does, then the function name terminates at the first "'" character
  following the "'" character in "fn '" which is not preceded by a "'"
  (wow, thank Duff for rc's simple, consistent quoting rules!)

And you don't need any rev's, just the sed.

Hangs head in shame....

OK,
John.

Re: early reaction(s) to rc

[Paul Haahr]

i used to set up a different history file for each window, and
just had xterm run an rc script which then invoked rc.  no muss,
no fuss, and didn't require any changes to rc.  Byron mentioned
last week that he uses one history file for all his windows; i
tried this last week, and now say i think it is the way to go.

as for per window startup commands themselves, if they are necessary
(the only thing my script did was set $history; everything else was
inherited) then just run a script that later invokes an interactive
rc.  one extra fork/exec is not that bad.  (or you can always do a
	. -i /dev/tty
if you really want to save that fork/exec)

on the other hand, it might (just MIGHT, i'm not advocating this)
be nice to be able to specify a different file that could be execute
prior to running rc, just like $home/.rcrc; maybe
	rc -L foo
would start an rc processes that did a . foo to start.

Re: early reaction(s) to rc

[Chris Siebenmann]

|Byron mentioned last week that he uses one history file for all his 
|windows; i tried this last week, and now say i think it is the way to go.

 I tried this in the beginning, but it seemed to jumble up and loose
entries from the history file randomly. It could get into situations
where I'd type a command into one window, and then right after it type
a -p, and it wouldn't find the command. Does anyone else use a single
global history under Ultrix and have it work? (Boyd?)

	- cks

Re: early reaction(s) to rc

[Boyd Roberts]

I should add that in this multi-window, multi-machine scenario I have here
I use one history file, with a tail -f in a 10 line xterm & my original
version of history.c.  My history file is:

    -rw--w--w-  1 boyd        87763 Aug 27 12:22 .h

And things aren't so slow:

    prl313 ; grep -n the-first-line .h
    1:the-first-line
    9494:grep -n the-first-line .h
    prl313 ; time : the-first-line
    the-first-line
    the-first-line: No such file or directory
            0.4 real         0.2 user         0.1 sys

I use : as my history char, as they do in Plan 9, and my :.c doesn't care
about how big anything is.  I'll get `panic: out of swap' before it'll
miss a long ago typed command of some ridiculous length.  But don't
talk to me about tab deletions in the edit phase -- gag! :-(