Re: Two bugs in es 0.9 alpha-2

[Harald Hanche-Olsen <hanche@math.ntnu.no>]

(The message I am responding to is almost two months old.  This is not
too untypical of the level of activity on this list.)

- "J. F. Wittenberger" <jerry@pfirsich.compot.com>:

| a) This is a little arguable, but I consider it a bug, because the
| former version and all shells I know handle it different:
| 
| I tried to get the name a script was called by hence I did:
| 
| NAME=`{basename $0}
| 
| giving me a value of `%backquote' for `$NAME'.  puh.

Um, yes, this happens because %backquote changed from being just plain
$&backquote to being a function, in which $0 is the name of that
function.  Since this is documented, sort of, I personally would
hesitate to call it a bug.  More precisely, the man page states

       If,  as the most common case, a function variable is bound
       to a lambda, when the function is invoked, the variable $0
       is bound (dynamically, see below) to the name of the func-
       tion.

Note that the dynamical nature of this binding is what causes the
problem.  To see what your snippet of code is really doing, say

; echo {NAME=`{basename $0}}
{NAME=<={%backquote <={%flatten '' $ifs} {basename $0}}}

and initial.es says

fn %backquote {
	let ((status output) = <={ $&backquote $* }) {
		bqstatus = $status
		result $output
	}
}

so by the time $&backquote gets to evaluate {basename $0}, $0 has
already been dynamically bound to %backquote.

| Workaround:
| 
| NAME=$0; NAME=`{basename $NAME} # ugly hack

No need to fork to get this.  You can do it with es builtins:

@{NAME=$*($#*)} <={%fsplit / $0}

or the somewhat more conventional

let(x=<={%fsplit / $0}) NAME=$x($#x)

| b) After running quite a ugly script (I use es or prototyping an
| application) I do smth like
| 
| fn quit  { echo quit; exit 0; }
| 
|    ..... {
|    ...
|    quit
|    }
|   ...
|   ....
| 
| when the quit gets executed I get a segmentation violation.

Uh.  I too have es dying on me occasionally.  But every time the
problem goes away when I try to isolate it in order to provide a
meaningful error report.  I would conjecture that this problem falls
into that same category.  To fix it, I suspect nothing will less than
a complete, careful review of the source code (preferably by someone
other than its author) will work.  Or maybe someone can run it under
purify and see what happens?  (Our purify license just ran out.  If it
gets renewed, and if I find the time, maybe I'll give it a try
myself.)

- Harald