[9fans] rc eflag bug?

[9fans] rc eflag bug?

[Sam]

Specifically:

baron% @{
 	flag e +
 	flag e; echo eflag: $status
 	echo one
 	cp /this/should /bail
 	echo time
 	}
eflag:
one
cp: can't stat /this/should: '/this/should' directory entry not found
time
baron% rc; echo back
baron% c=c
baron% if(~ $c c){
 	flag e +
 	echo two
 	cp /this/should /bail
 	echo times
 	}
two
cp: can't stat /this/should: '/this/should' directory entry not found
times
baron% #and yet when run again ...
baron% if(~ $c c){
 	echo three
 	cp /this/will /bail
 	echo times
 	}
three
cp: can't stat /this/will: '/this/will' directory entry not found
back
baron%

Sam

Re: [9fans] rc eflag bug?

[Richard Miller]

Here's an explanation for this surprising rc behaviour:

> baron% c=c
> baron% if(~ $c c){
>  	flag e +
>  	echo two
>  	cp /this/should /bail
>  	echo times
>  	}
> two
> cp: can't stat /this/should: '/this/should' directory entry not found
> times
> baron% #and yet when run again ...
> baron% if(~ $c c){
>  	echo three
>  	cp /this/will /bail
>  	echo times
>  	}
> three
> cp: can't stat /this/will: '/this/will' directory entry not found
> back
> baron%

Each top-level (simple or compound) rc command is compiled into threaded code
and then executed.  If the 'e' flag is set at compile time, rc emits code after
each simple command to check the status and exit if non-null.  So if the flag
becomes set during the execution of a compound command, it doesn't take effect
until that compound command finishes and the next command is compiled.  If the
compound command was in a subshell (using @{...}), the 'e' flag setting won't
affect the parent shell so it has no effect.  (I'm ignoring the special case
of the 'eval' command ...)

So, is it a bug, or a documentation change to explain that changes to the 'e'
flag take effect from the next top-level command?

-- Richard