Future shell work - comments reqyuested

[Robert Elz <kre%munnari.OZ.AU@localhost>]

I have more or less finished work on shell arithmetic, completing the
currently missing (not posix required, but allowed) operators, that is
the unary ++, -- (prefix & postfix) and the ',' operator.  There's
nothing much to say (or ask) about that, but...

While playing around in there, I was reminded (again) of the undocumented
"let" and "exp" built-in commands (or should I say command, they are two
names for the same thing.)

To save people reading the source, the man page for them (either or both)
if such a thing existed, would document them something like:

NAME
	exp - evaluate arithmetic expression
SYNOPSIS
	exp exp res sion
DESCRIPTION
	The exp utility joins its arguments with spaces (like eval),
	then evaluates the result as an arithmetic expression.  The
	result is printed to stdout.
EXIT STATUS
	1 if the result was zero, and 0 otherwise.

(ok, it would probably be a bit more wordy, and mention the need to
quote things like '*', unlike $(( )), but that's about it.)

I have no idea of the origins of "exp", but I believe that "let" was
added to be more ksh compatible.

Except that it isn't, in ksh each arg given is an expression to be
evaluated (they are not formed into a single expression) and no results
are printed.   The exit status is as above, but applies to the last
expression evaluated.

I understand why we have the output, until relatively recently arithmetic
expressions had no side effects, the only way to get a value (other than
he 0/1 exit status) from a let or exp command, was for the command to
print the value, and then use it in a command substitution, as in
	x=$( let 3 + 4 )
These days there is essentially no reason to ever do that, as we would
use
	x=$(( 3 + 4 ))
instead, or just $(( x = 3 + 4 ))   (in a situation where the value is
wanted as part of the command line).

The first question is what we should do about all of this ?

FreeBSD deleted the "exp" command some time ago, but retain the let command
just the same as we have it.

dash seems to have neither (any more.)

ksh (all variants I think) have the ksh form of "let", as do bash and zsh
(though it is possible there might be some minor differences, esp with zsh.)
They don't have exp.

yash (like dash) has neither.

I don't see a lot of point in keeping exp, as it only exists (any more) in
our shell, and as it hasn't been documented in many many years (decades) if
it ever was, I doubt that anyone in the NetBSD world een knows it exists
(but I am open to correction on that.)

So the real issue is likely to be what we do with let - we can keep it as
is (and retain FreeBSD compatibility) or we can convert it to ksh style,
and be more compatible with the ksh's, bash, and zsh.

Which is preferred?   And if we do keep it, should we document it, or
just have it available in case it is used (one case was observed in a
pkgsrc package configure script recently ... but was used only because it
managed to deduce that the (current) NetBSD sh was ksh).

One option would be to keep exp like it is (and use it as a "let" replacement
if some script expects FreeBSD behaviour) and make "let" be the ksh type
command.

So, opinions?

Second, the -i (iinteractive) flag to sh is handled quite strangely on
the command line.    After the shell has started it can be turned on or
off at will (doing so is not often an intelligent thing to do, but it
does have some uses.)   But on the command line, unlike all other options,
it cannot simply be set - the shell deduces it is interactive when input
is from stdin, and stdin and stdout are ttys, and -i can be set, but only
in conjunction with -s.

That is in
	sh -ic 'commands...'
or
	sh -i script args

The '-i' is simply ignored.

(To be a little stranger, it can be turned off in any circumstances,
as with "sh +i").

I am not sure why that special case exists, and I doubt it makes sense.

I am proposing that we (I) remove the restruction, and allow -i to be
set on the command like, regardless of what other flags or args are present
(and to be disabled, as it can be now.)

When -i is not mentioned at all (the usual case) everything will remain
as it is now of course, with the shell deducing whether it is interactive,
and setting -i if it is.

Opinions on this one?

kre

ps: I currently have a (self-imposed) moratorium on non-bug-fix sh changes,
so the arithmetic additions mentioned above (and any changes to let/exp,
and -i) will not actually appear for a while.