Re: [9fans] bug or a feature?

Re: [9fans] bug or a feature?

[Byron Rakitzis]

>i'm happiest with
>
>        if foo
>                bar
>        if not
>                baz

Maybe someone can settle this for me.

I found "if not" an atrocity because it's not something lexically
scoped. This is apparently legal rc according to the grammar:

	if not foo
	if not bar
	if not baz

It's up to the interpreter to flag it as an error.

Granted there are many "runtime" as opposed to "parse" errors which
rc will flag for you, but it strikes me as singularly awful that the
control structure of the language should be one of those things.

Also, without thinking really hard about it, I'm not sure how
if not would work for nested ifs. Does this work the way you
would expect?

	if (foo) {
		stuff
		if (bar) {
			more stuff
		}
	}
	if not {
		!foo stuff
	}

A peek at the plan9 rc source suggests there is a global variable
called "ifnot" which makes me very, very nervous. But I don't run
plan9 at home so I can't test this code sample. What if foo is true
and bar is false?

TD was justifiably proud of rc's yacc grammar -- I suppose I felt I
was doing it one better by bringing "if .. else" under that umbrella
also.

Byron.

Re: [9fans] bug or a feature?

[Byron Rakitzis]

>No reason to have a stack.

Ok, I see how the code generator works now!

Byron.

Re: [9fans] bug or a feature?

[presotto]

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

Running

if(test -e /){
	echo musthappen
	if(test -e /notthere)
		echo wonthappen
}
if not{
	echo canthappen
}

yields just 'musthappen'

You were perhaps afraid it would also print canthappen?

Looks like td sets the variable to true before the
comparison and to false on the way out of an if body
(see Xwastrue and where its emitted).  No reason to
have a stack.

[-- Attachment #2: Type: message/rfc822, Size: 2670 bytes --]

From: Byron Rakitzis <byron@rakitzis.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug or a feature?
Date: Fri, 26 Jul 2002 19:43:22 -0700
Message-ID: <200207270243.g6R2hMc04796@rakitzis.com>

>i'm happiest with
>
>        if foo
>                bar
>        if not
>                baz

Maybe someone can settle this for me.

I found "if not" an atrocity because it's not something lexically
scoped. This is apparently legal rc according to the grammar:

	if not foo
	if not bar
	if not baz

It's up to the interpreter to flag it as an error.

Granted there are many "runtime" as opposed to "parse" errors which
rc will flag for you, but it strikes me as singularly awful that the
control structure of the language should be one of those things.

Also, without thinking really hard about it, I'm not sure how
if not would work for nested ifs. Does this work the way you
would expect?

	if (foo) {
		stuff
		if (bar) {
			more stuff
		}
	}
	if not {
		!foo stuff
	}

A peek at the plan9 rc source suggests there is a global variable
called "ifnot" which makes me very, very nervous. But I don't run
plan9 at home so I can't test this code sample. What if foo is true
and bar is false?

TD was justifiably proud of rc's yacc grammar -- I suppose I felt I
was doing it one better by bringing "if .. else" under that umbrella
also.

Byron.

Re: [9fans] bug or a feature?

[Lyndon Nerenberg]

>>>>> "Douglas" == Douglas A Gwyn <DAGwyn@null.net> writes:

    Douglas> It is the application that
    Douglas> *doesn't* explicitly check this, but rather proceeds using
    Douglas> the default result of the globbing, that is the interesting
    Douglas> case.  How often does that result in acceptable behavior?

Rarely, I suspect. The fact that almost no code actually checks for the
no-match case strongly implies that that behaviour is counter-intuitive
to (or perhaps more accurately, unexpected by) most people.

I'm beginning to think that globbing should just come out of the shell.
On most current hardware the cost of spawning `{ls *.foo} is negligible.

--lyndon

Re: [9fans] bug or a feature?

[Douglas A. Gwyn]

Lyndon Nerenberg wrote:
> Can anyone point out a piece of code that actually uses the current
> behaviour in the no-match case *other* than to test for the original
> pattern to look for a failed match? I have yet to see one.

That proves nothing, since no correctly functioning code could
assume otherwise.
It is the application that *doesn't* explicitly check this,
but rather proceeds using the default result of the globbing,
that is the interesting case.  How often does that result in
acceptable behavior?

Re: [9fans] bug or a feature?

[Dan Cross]

> given that i can't write
>
> 	if foo
> 		bar
> 	else
> 		baz
>
> i'm happiest with
>
> 	if foo
> 		bar
> 	if not
> 		baz
>
> as compared with
>
> 	if foo{
> 		bar
> 	}else
> 		baz
>
> or
>
> 	if foo
> 		bar; else
> 		baz
>
> am i misunderstanding unix rc?

No, you're not.

I *always* put statements following if or else in braces, so for me,
I'd much rather see else.  I suppose the lesson is that neither rc
implementation makes everyone happy.  I guess this will remain an issue
where Bourne's shell is superior to rc; clearly td thought it was a
wart and that the former did better; I believe his reasons still
stand.

	- Dan C.

Re: [9fans] bug or a feature?

[Russ Cox]

given that i can't write

	if foo
		bar
	else
		baz

i'm happiest with

	if foo
		bar
	if not
		baz

as compared with

	if foo{
		bar
	}else
		baz

or

	if foo
		bar; else
		baz

am i misunderstanding unix rc?

Re: [9fans] bug or a feature?

[Tharaneedharan Vilwanathan]

Hi,

I used regular files to try venti and did just like the example in the man
page says.

I faced 2 problems. The man page says what should be the size of the index
file nor the utility takes a default value (in contrast, fmtarenas takes a
default value). For 512MB arena file, what should be the sie of the index
file? I created two 50MB files. Am I right?

Next, after doing all the steps given in the example, I tried to do 'vac' on
a directory. It said like "no space left". I tried to vac a small file.
Still the same problem.

Any clues?

Thanks
dharani

Re: [9fans] bug or a feature?

[Dan Cross]

> > The rationale is explained in the following paragraphs, but apparantly,
> > Unix rc has fixed that.  Indeed, the specific example given in td's
> > paper is handled in a reasonable way.
>
> requiring braces is just as much of a hack
> as if not.

Err, Unix rc doesn't require braces for td's example.  requiring a newline
or ; seperator certainly isn't any better, though, for the else case.

	- Dan C.

Re: [9fans] bug or a feature?

[Russ Cox]

> The rationale is explained in the following paragraphs, but apparantly,
> Unix rc has fixed that.  Indeed, the specific example given in td's
> paper is handled in a reasonable way.

requiring braces is just as much of a hack
as if not.

Re: [9fans] bug or a feature?

[Dan Cross]

> > (And while we're at it, can we add ``else'' to Plan 9 rc?)
>
> i was hoping someone would add if not to unix rc.

Why?  `if not' is a hack, even according to td's rc paper, which has this
to say about it:

	The one bit of large-scale syntax that Bourne unquestionably
	does better than rc is the if statement with else clause.

The rationale is explained in the following paragraphs, but apparantly,
Unix rc has fixed that.  Indeed, the specific example given in td's
paper is handled in a reasonable way.

btw- there seems to be a problem with the html version of the rc paper
on the Bell Labs web site; my browser shows the latter half in italics.

	- Dan C.

Re: [9fans] bug or a feature?

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> i thought that version of glob announced 'no match'

Hopefully on stderr, not stdout.

Re: [9fans] bug or a feature?

[Russ Cox]

> shell globbing. Or set noglob in the shells that support it.  The fact
> that noglob exists says to me that the no-match pass-through globbing
> behaviour has been found to be problematic in the past.

no, it only means someone felt like putting it in
and was motivated enough to write the code.

russ

Re: [9fans] bug or a feature?

[Lyndon Nerenberg]

>>>>> "Geoff" == Geoff Collyer <geoff@collyer.net> writes:

    Geoff> I do think that the current behaviour is more helpful than
    Geoff> expanding to a null list would be.  If the pattern doesn't
    Geoff> match, you've very likely made a mistake.  I'd rather have
    Geoff> ``cat ?akefile'' print

    Geoff> 	cat: can't open ?akefile: '?akefile' directory entry not
    Geoff> found

    Geoff> and exit than have it just sit there reading standard input.

But shell globbing is a shell function, therefore the shell should
report non-matches. If you want the application to do the globbing (the
ls and tar examples) you should quote the arguments to protect them from
shell globbing. Or set noglob in the shells that support it.  The fact
that noglob exists says to me that the no-match pass-through globbing
behaviour has been found to be problematic in the past.

--lyndon

Re: [9fans] bug or a feature?

[Russ Cox]

> (And while we're at it, can we add ``else'' to Plan 9 rc?)

i was hoping someone would add if not to unix rc.

Re: [9fans] bug or a feature?

[Pavel Mihaylov]

На 13 юни 2002 г. (четвъртък), в 2.49 часа, Geoff Collyer писа:
> 
> I do think that the current behaviour is more helpful than expanding
> to a null list would be.  If the pattern doesn't match, you've very likely
> made a mistake.  I'd rather have ``cat ?akefile'' print
> 
> 	cat: can't open ?akefile: '?akefile' directory entry not found
> 
> and exit than have it just sit there reading standard input.
> 

I just played with some common shells, the behavior of zsh (my choice in
Unix world) and csh seems to solve your case.

% echo nonex?
zsh: no matches found: nonex?
% bash
$ echo nonex?
nonex?
$ csh
> echo nonex?
echo: No match.
> ksh
$ echo nonex?
nonex?

Re: [9fans] bug or a feature?

[Dan Cross]

> I've always understood the utility of passing through a failed glob pattern
> to be that some programs do their own globbing (as I recall, find and tar
> are the two main candidates, maybe restor) and if the user forgets
> to (or deliberated doesn't) quote the pattern and it doesn't match anything,
> the program gets to glob it.  How useful this is may depend upon your
> feelings about quoting in general.

The argument around, ``what does quoting mean to me?'' is probably
beyond the scope of this discussion.  Find tends not to be an issue,
since we don't have a find on Plan 9.

> I do think that the current behaviour is more helpful than expanding
> to a null list would be.  If the pattern doesn't match, you've very likely
> made a mistake.  I'd rather have ``cat ?akefile'' print
>
> 	cat: can't open ?akefile: '?akefile' directory entry not found
>
> and exit than have it just sit there reading standard input.

I disagree for reason that the current behavior is ambiguous, as
illustrated by the following example:

term% mkdir t
term% cd t
term% ls
term% touch 'foo?'
term% ls -l
--rw-rw-r-- M 14826 cross cross 0 Jun 12 19:59 foo?
term% echo foo?
foo?
term% echo bar?
bar?
term% echo Rats!
Rats!
term%

Of course, it's probably foolish to name a file, ``foo?'', but one
might imagine contexts in which that happens.  Besides, if the
expansion of the null argument list is propogated into the program's
argument vector, then it will indeed look for something non-existant,
though the error message might be less useful than otherwise.

	- Dan C.

(And while we're at it, can we add ``else'' to Plan 9 rc?)

Re: [9fans] bug or a feature?

[Geoff Collyer]

I've always understood the utility of passing through a failed glob pattern
to be that some programs do their own globbing (as I recall, find and tar
are the two main candidates, maybe restor) and if the user forgets
to (or deliberated doesn't) quote the pattern and it doesn't match anything,
the program gets to glob it.  How useful this is may depend upon your
feelings about quoting in general.

I do think that the current behaviour is more helpful than expanding
to a null list would be.  If the pattern doesn't match, you've very likely
made a mistake.  I'd rather have ``cat ?akefile'' print

	cat: can't open ?akefile: '?akefile' directory entry not found

and exit than have it just sit there reading standard input.

Re: [9fans] bug or a feature?

[Lyndon Nerenberg]

>>>>> "Dan" == Dan Cross <cross@math.psu.edu> writes:

    Dan> Rather, it's an historical artifact; I agree with Doug and
    Dan> Scott that it deserves reconsideration.

Can anyone point out a piece of code that actually uses the current
behaviour in the no-match case *other* than to test for the original
pattern to look for a failed match? I have yet to see one.

--lyndonf

Re: [9fans] bug or a feature?

[Dan Cross]

> somehow it seemed to me an empty list would be the proper way.

I agree.  It seems that way to me, too.

> as it was already said -- the current behaviour is a feature, not a bug

Rather, it's an historical artifact; I agree with Doug and Scott that
it deserves reconsideration.

	- Dan C.

Re: [9fans] bug or a feature?

[Scott Schwartz]

Given that rc, unlike sh, is able to distinguish empty lists and empty
strings, that seems like a natural way to represent a failed glob.
Given that commands in rc and sh are able to return status, that seems
like a natural way to represent a failed glob.  The current behavior
never seemed right to me.

Re: [9fans] bug or a feature?

[Dennis Ritchie]

Forsyth:

 > i thought that version [6th ed] of glob announced 'no match'
 > (which csh inherits) and bourne's sh was first to
 > pass it through to the command as-is if no names matched.

This is so.  I just looked at the source.
I think the change was generally accepted
as an improvement, or at least neutral.

	Dennis

Re: [9fans] bug or a feature?

[andrey mirtchovski]

not to drag this any further, here's what the Rc paper has to say
about globbing (section 4):

<quote>
A pattern is replaced by a list of arguments, one for each path name
matched, except that a pattern matching no names is not replaced by
the empty list; rather it stands for itself.
</quote>

somehow it seemed to me an empty list would be the proper way.  as it
was already said -- the current behaviour is a feature, not a bug

>  > i thought that version [6th ed] of glob announced 'no match'
>  > (which csh inherits) and bourne's sh was first to
>  > pass it through to the command as-is if no names matched.
>
> This is so.  I just looked at the source.
> I think the change was generally accepted
> as an improvement, or at least neutral.
>
> 	Dennis

Re: [9fans] bug or a feature?

[forsyth]

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

i thought that version of glob announced 'no match'
(which csh inherits) and bourne's sh was first to
pass it through to the command as-is if no names matched.

[-- Attachment #2: Type: message/rfc822, Size: 2074 bytes --]

To: <9fans@cse.psu.edu>
Subject: Re: [9fans] bug or a feature?
Date: Tue, 11 Jun 2002 15:19:08 -0600 (MDT)
Message-ID: <Pine.LNX.4.33.0206111518190.14579-100000@snaresland.acl.lanl.gov>

On Tue, 11 Jun 2002, andrey mirtchovski wrote:

> On Tue, 11 Jun 2002, rob pike, esq. wrote:
>
> > This is long-standard behavior for shells.  Feature.
>
> darn it, i didn't know this has been there since unix 6th ed...

I just showed Andrey the 9/19/73 man page for glob(VIII) and he now stands
corrected.

ron

Re: [9fans] bug or a feature?

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> This is long-standard behavior for shells.  Feature.

Indeed, but since so many other aspects of Unix were rethought
for Plan 9, it deserves some consideration; it's certainly
contrary to simplicity and regularity.  Perhaps someone knows
the history of this decision, but my *guess* is that it was
deemed to be more useful in "typical" interactive use:
	% cp foo.* bar
	cp: foo.*: nonexistent file
As of 6th Edition Unix there was a separate "glob" utility.

For some purposes, e.g. find . whatever -print | xargs ...
I find myself providing an extra argument "/dev/null" to
the command invoked under xargs control; e.g. when it's
"grep" and I want to be sure to see the filename even if
the grep is invoked with just one filename argument (that
works around an irregularity in "grep", again likely to be
due to thinking about interactive use).  Too bad there is
nothing similar that could be used as an "empty string"
placeholder.  (I introduced that notion in the 1999 C
standard as part of the specification for handling empty
arguments to function-like macros, and it made it easy to
be sure that the empty arguments didn't vanish until we
really wanted them to.)

Re: [9fans] bug or a feature?

[Lucio De Re]

On Tue, Jun 11, 2002 at 03:19:08PM -0600, Ronald G Minnich wrote:
>
> I just showed Andrey the 9/19/73 man page for glob(VIII) and he now stands
> corrected.
>
You dind't show him the "C"  shell man page, though, did you?  Not
that I don't find the "C" shell frustrating specifically because of
_that_ behaviour, in fact, quite unforgivable.  Specially when used
with "find" ;-)

++L

Re: [9fans] bug or a feature?

[Ronald G Minnich]

On Tue, 11 Jun 2002, andrey mirtchovski wrote:

> On Tue, 11 Jun 2002, rob pike, esq. wrote:
>
> > This is long-standard behavior for shells.  Feature.
>
> darn it, i didn't know this has been there since unix 6th ed...

I just showed Andrey the 9/19/73 man page for glob(VIII) and he now stands
corrected.

ron

Re: [9fans] bug or a feature?

[andrey mirtchovski]

On Tue, 11 Jun 2002, rob pike, esq. wrote:

> This is long-standard behavior for shells.  Feature.

darn it, i didn't know this has been there since unix 6th ed...

i sincerely apologise for my ignorance

Re: [9fans] bug or a feature?

[Russ Cox]

> this causes cpurc to fail on diskless machines.

termrc says

	for(disk in /dev/sd??) {
		if(test -f $disk/data && test -f $disk/ctl)
			disk/fdisk -p $disk/data >$disk/ctl >[2]/dev/null
		for(part in $disk/plan9*)
			if(test -f $part)
				disk/prep -p $part >$disk/ctl >[2]/dev/null
	}

cpurc doesn't mention disks.

Re: [9fans] bug or a feature?

[rob pike, esq.]

> shouldn't rc return an empty list if the glob matching does not
> succeed?  currently it returns the actual string it attempted to glob,

This is long-standard behavior for shells.  Feature.

-rob

Re: [9fans] bug or a feature?

[andrey mirtchovski]

> cpurc doesn't mention disks.

some locally modified cpurc which includes crud for our local network.
my fault.

[9fans] bug or a feature?

[andrey mirtchovski]

shouldn't rc return an empty list if the glob matching does not
succeed?  currently it returns the actual string it attempted to glob,
as in:

p9% for(i in /dev/sd??) echo $i
/dev/sdC0
/dev/sdD0
p9% for(i in /dev/sd?) echo $i
/dev/sd?
p9%

this causes cpurc to fail on diskless machines.

proposed behaviour:

p9% for(i in /dev/sd??) echo $i
/dev/sdC0
/dev/sdD0
p9% for(i in /dev/sd?) echo $i
p9% for(i in '/dev/sd?') echo $i
/dev/sd?
p9%