Re: All I want for Christmas ...

Re: All I want for Christmas ...

[Byron Rakitzis]

Aha, more trivia.

	. /dev/tty

does not start an interactive context. you need to explicitly
say

	. -i /dev/tty

Hence your two examples

	rc<<eof
	. /dev/tty
	eof

and

	rc<<eof
	exec</dev/tty
	eof

should behave in a similar fashion.

rc only *starts up* interactively when isatty(0) is true.

Re: All I want for Christmas ...

[Alan Watson]

I could have sworn that ". /dev/tty" worked like that yesterday ...
someone must have hacked my system and patched the binaries over
night.

I guess you don't want to call isatty() every time one uses ".", but
I'm still not sure if this is "right."  What is so special about
start-up, that one doesn't need an explicit "-i" flag?  Why not check
stdin every time it gets redirected?

While I agree this last suggestion is of very limited use, and may
well be trivial, it is hardly "more" trivia -- unless you think the
error handling and the sh compatibility of your shell are trivial
issues.

Alan.

Re: All I want for Christmas ...

[Byron Rakitzis]

>So what does es do? :-)

The sky's the limit. Paul even added ~-expansion.

; prompt='es> ' es
es> exec asdf
asdf not found
es> 

Re: All I want for Christmas ...

[Alan Watson]

1. exec

The only time I use exec interactively is when I install a new version
of rc.  I think it would be a poor choice to differentiate the
behaviour of exec based on the interactiveness of the shell.

Part of the reason that I would like the change is that I often use
exec in scripts ... but I also often make mistakes in scripts.
Dumping the environment to stderr after a failed exec would be a
useful debugging aid.  It also just seems "the right thing to do."
However, Byron's reservations are valid.

2. -s

Hey, yeah, now you mention it I remember that coming round.  My
apologies for bringing it up again.

3. Let me make one more comment, which arises from a recent discussion
in comp.unix.shell:

	; rc <<EOF
	...
	. /dev/tty
	EOF

is interactive after the here document, but

	; rc <<EOF
	...
	exec </dev/tty
	EOF

is not.  Should this be so?  (And, I guess, is this even important?)

Please don't take my suggestions as criticism: I have silently thanked
Tom Duff and Byron more time than I can recall for providing me with a
shell which behaves in a simple, rational, and predictable manner in
almost every situation I have come across.  What's more, it even does
what the man page says it does ...

Alan.

Re: All I want for Christmas ...

[Scott Schwartz]

| I honestly can't see how this could be a big deal one way or another,

It depends on how sophisticated your shell scripts are.  One could
reasonably argue that if it makes a difference you should use a more
capable language.

| and given the choice, I prefer to resist any change to the program so
| late in the game.

So what does es do? :-)

Re: All I want for Christmas ...

[Byron Rakitzis]

We have 

>Well, it could recover after the exec iff the shell is interactive.

and

>I'd rather have the shell do the right thing and fix the scripts.

The lady doth protest too much, methinks.

I honestly can't see how this could be a big deal one way or another,
and given the choice, I prefer to resist any change to the program so
late in the game.

Re: All I want for Christmas ...

[Chris Siebenmann]

|	I'd rather have the shell do the right thing and fix the scripts.

 I'd rather have us do what Tom Duff's rc shell does; the version I have
prints an error message and exits.

	- cks

Re: All I want for Christmas ...

[Noel Hunt]

	From hawkwind.utcs.toronto.edu!rc-owner Thu Dec  3 15:45:16 1992
	From:	Scott Schwartz <schwartz@groucho.cs.psu.edu>
	
	I'd rather have the shell do the right thing and fix the scripts.

i agree.

Re: All I want for Christmas ...

[Scott Schwartz]

| re: exec. I would rather not change the behavior of exec. For example,
| what if some script uses exec for flow control; an exec which continued
| on failure would change the behavior of the script.

I'd rather have the shell do the right thing and fix the scripts.

Re: All I want for Christmas ...

[Byron Rakitzis]

re: -s. I think I agreed on the list that I will incorporate this into
1.5.

re: exec. I would rather not change the behavior of exec. For example,
what if some script uses exec for flow control; an exec which continued
on failure would change the behavior of the script.

Re: All I want for Christmas ...

[John Mackin]

    If I do:

    	; exec foo
    	foo not found

    then rc dies (as do all other shells, I believe).

Not _all_ other shells, just most of 'em.  The Pike (V8+) version of
sh continues after a failed exec.  I don't think this is too big an
issue, but I lean to the side of continuing, on the basis that if
the user typed the exec interactively and made a typo or was confused,
they probably didn't want their shell to go away.

    2. -s flag

This has been talked about on the list before.  Boyd did this 'cos he
felt he had to.  I sent Boyd's code to Rich Salz.

Personally, as I have said before, I see nothing at all wrong with
adopting command line usage that brings rc more into line with the
defacto standard set by sh, and therefore I am behind -s, if not
heavily.  On the other hand, I find it disappointing that -s
proponents cannot muster anything better than the tired old `I
seem to need this on Ultrix, for reasons I can't explain' argument.
Hell, people!  I have many Ultrix boxes here.  They are good boxes!
The _first_ thing you do on an Ultrix box is build X11R5.  The _second_
thing you do is rm -rf DEATHwindows, and set up xdm and R5.  Come on
up to Freely Distributable X Windows, Your International Passport
To Bitmapped Graphics Pleasure!  You'll Be So Glad You Did!

(Well hell, X is terrible, but it's a gazillion times better than
DEATHwindows.  Of course you might have special graphics hardware,
watch that one.  Luckily, we don't.)

OK,
John.

All I want for Christmas ...

[Alan Watson]

Well, rc v1.5 was mentioned, so I figure it's time to get out my wish
list and see what Santa brings for Christmas.

1. Error handling after exec

If I do:

	; exec foo
	foo not found

then rc dies (as do all other shells, I believe).  Would it be
difficult to continue after such an error, so that the user could
decide on the appropriate action to take?  This would more closely
parallel the behaviour of the system call, but is it the behaviour we
want from a shell?

2. -s flag

Other shells have a -s flag, meaning "read commands from stdin unless
told otherwise."  It seems pretty useless to me, but my X server
executes my .X11Startup by the equivalent of "$SHELL -s <.X11Startup".
I'm not sure if this is standard (what's wrong with execlp?), but it
would not surprise me if this feature was specific to Ultrix servers.
Ultrix rather frowns of the MIT way of configuring X.  (Oh, the drama
and joy of Ultrix.)  I get around this by using a five line C program
as my "shell"; it eliminates any "-s" at argv[1] and then execs rc.
Is there any support for adding an (essentially dummy) -s flag to rc
for the sake of compatibility with other shells?