Subject: Re: make release abends with "*** Error code 1" SOLVED ERRATUM
To: Simon Truss <simon@bigblue.demon.co.uk>
From: Woodchuck <djv@bedford.net>
List: netbsd-help
Date: 01/22/2007 14:54:54
On Mon, 22 Jan 2007, Simon Truss wrote:

>>> The first thing to do is bracket the interior of .kshrc with
>>>
>>> 	if [ -o interactive ]; then
>>> 		. /etc/ksh.kshrc
>>> 		<other stuffs>
>>> 	fi
>> 
>> Alas, I thought I were done.  This recommendation does not work
>> on NetBSD, because 	if [ -o <some shell state> ]
>> is bogus.  It is bogus because sh does not implement test/[ as
>
> how about:
>
> case $- in *i*)
>      # commands for interactive use only
> esac
>
> its documented in the sh man page and works for me.
>
> Simon

Yes.  But the problem is that an interactive shell need not have
the -i switch to be one.  A sh -i is only one sort.

From man 1 sh:

      If no args are present and if the standard input of the shell is con-
      nected to a terminal (or if the -i flag is set), and the -c option is not
      present, the shell is considered an interactive shell.

Frankly, I find that sentence to be ambiguous in English.
It seems to be
 	no-args AND (stdin-tty OR -i) AND not-c   ==> INTERACTIVE

i.e., that there are three conditions that must be true to be interactive.
I am interpreting the comma in the man page as a strict grouping.
I seriously doubt if it was so intended.
 	(no-args AND stdin-tty) OR -i AND not-c   ==> INTERACTIVE

There are still other groupings consistent with English rules of
precendence ("or" and "and" have equal precedence).  English
parentheses do not *group* like "logic" parens, English parens
are sort-of left associative, of all things.  I suppose I should
go through the source and see what the reality is.

From man 1 ksh:

     A  shell  is  interactive  if the -i option is used or if both standard
     input and standard error are attached to a tty.

This one is easier to parse.

 	-i  OR (stdin-tty AND stderr-tty) ==> INTERACTIVE

Ksh seems to relax the no-args and the not-c conditions.

The problem I'm finding is due to $ENV being sourced on any
sh or ksh invocation.  If ENV is undefined, ksh (but not sh) will
invoke a default ($HOME/.kshrc) for every shell.  (Not true in all
BSD's.)  So for ksh, if one wants no script at all, ENV should be
set to some null script.

Perhaps I'm all wet on that -- perhaps sh and/or ksh sets the
flags expressed in $- on the fly for "i".  It does set them
on the fly for the V and E flags.  Set -o vi  and set -o emacs
change V and E flags in the current shell.

You're probably right, $- and the case statement are probably
the portable way to go.  Thanks for your interest!

Dave