[9fans] p9p rc flag e +

[dexen deVries]

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?

[erik quanstrom]

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

[...]

Post by dexen deVries
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

[dexen deVries]

Post by erik quanstrom
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,

[erik quanstrom]

Post by dexen deVries
i'd rather have if's $status visible only to the first statement following it,
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