[9fans] p9p rc flag e +

[9fans] p9p rc flag e +

[dexen deVries]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

in p9p rc, an `if (/bin/false)' statement without `if not' statement causes 
non-empty $status, and thus will terminate mk.

for example, the attached mkfile returns error for target `breaks', but works 
for target `works', with the difference being that of trailing `if not'.

from my point of view, the `if (/bin/false)' statement spills the non-empty 
$status from the conditional expression to its outern scope. perhaps this is 
to simplify implementation of `if not', but it irks me.

is that really the expected behavior, or is it a quirk of p9p rc?

is there a point to, or an use case for this behavior?


-- 
dexen deVries

[[[↓][→]]]

[-- Attachment #2: mkfile --]
[-- Type: text/plain, Size: 324 bytes --]

MKSHELL=$PLAN9/bin/rc

test:VQ: positive negative
	echo success.

positive:VQ:
	if (test -e mkfile)
		echo the file exists

negative:VQ:
		# any file or dir that is sure not to exist
		# if we have a file `mkfile', then for sure we don't have a dir `mkfile/'
	if (test -e mkfile/)
		echo SHOULD NOT BE REACHED

Re: [9fans] p9p rc flag e +

[erik quanstrom]

> in p9p rc, an `if (/bin/false)' statement without `if not' statement causes
> non-empty $status, and thus will terminate mk.
>
[...]
>
> is that really the expected behavior, or is it a quirk of p9p rc?
>
> is there a point to, or an use case for this behavior?

the more idiomatic way to write this is if(~ 0 1); plan 9 has no
/bin/false.  plan 9 rc behaves in the same way, and the usual
solution is to use ~ 0 0 to clear the status, or exit ''.

i have seen scripts reuse the status, especially of a pipe
inside the if.  (obviously the status is the same in either
branch.)

i don't think this is a bug, nor due i think it could be
changed in a manner compatable with existing scripts.

- erik

Re: [9fans] p9p rc flag e +

[dexen deVries]

On Thursday 21 of March 2013 10:22:54 erik quanstrom wrote:
> the more idiomatic way to write this is if(~ 0 1); plan 9 has no
> /bin/false.  plan 9 rc behaves in the same way, and the usual
> solution is to use ~ 0 0 to clear the status, or exit ''.
> 
> i have seen scripts reuse the status, especially of a pipe
> inside the if.  (obviously the status is the same in either
> branch.)


thanks Erik, it makes sense to me now :-)


i'd rather have if's $status visible only to the first statement following it, 
for example:

if (foo | bar | baz) {  # sets $status
  if (! ~ $status ....) {  # uses $status
    handle_particular_kind_of_pipeline_failure
  }
  do_other_stuff   # should not be affected
}
do_yet_other_stuff   # should not be affected either


...but guess rc's semantics are almost set in stone by now :-)


cheers,
-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] p9p rc flag e +

[erik quanstrom]

> i'd rather have if's $status visible only to the first statement following it,
> for example:
>
> if (foo | bar | baz) {  # sets $status
>   if (! ~ $status ....) {  # uses $status
>     handle_particular_kind_of_pipeline_failure
>   }
>   do_other_stuff   # should not be affected
> }
> do_yet_other_stuff   # should not be affected either
>
>
> ...but guess rc's semantics are almost set in stone by now :-)

the status is only visible to the first *executed* statement.
remember, rc at heart is a virtual machine.

since the argument of if is always executed before the branch,
the status of cmd1 in "if(cond)cmd1" is by definition ''.

to take this to its logical conclusion, consider this code

	if(~ 0 1){
	}
	if not{
	}
	echo $status

it prints "no match".

- erik