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