From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Thu, 21 Mar 2013 14:29:38 +0100
Message-ID: <2197990.tSQfKsnBKJ@coil>
User-Agent: KMail/4.10.1 (Linux/3.9.0-rc3-l50; KDE/4.10.1; x86_64; ; )
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nextPart5591379.Q9ifZmforb"
Content-Transfer-Encoding: 7Bit
Subject: [9fans] p9p rc flag e +
Topicbox-Message-UUID: 2fd767c4-ead8-11e9-9d60-3106f5b1d025

This is a multi-part message in MIME format.

--nextPart5591379.Q9ifZmforb
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

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

for example, the attached mkfile returns error for target `breaks', but=
 works=20
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-e=
mpty=20
$status from the conditional expression to its outern scope. perhaps th=
is is=20
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?


--=20
dexen deVries

[[[=E2=86=93][=E2=86=92]]]

--nextPart5591379.Q9ifZmforb
Content-Disposition: attachment; filename="mkfile"
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"; name="mkfile"

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

--nextPart5591379.Q9ifZmforb--