From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ugly hack
Message-ID: <20030216170019.Q9084@cackle.proxima.alt.za>
References: <20030215174605.I9084@cackle.proxima.alt.za> <5058bc09efabbfadfc80effc0d3ba1f1@plan9.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <5058bc09efabbfadfc80effc0d3ba1f1@plan9.bell-labs.com>; from Russ Cox on Sun, Feb 16, 2003 at 09:19:38AM -0500
Date: Sun, 16 Feb 2003 17:00:19 +0200
Topicbox-Message-UUID: 62af0c7c-eacb-11e9-9e20-41e7f4b1d025

On Sun, Feb 16, 2003 at 09:19:38AM -0500, Russ Cox wrote:
>
> This is not the right place for such a hack.
> You are attempting to fix a bug in the kernel
> by patching the shell.  Down that path lies
> madness.  See http://plan9.bell-labs.com/sys/doc/lexnames.ps.
>
Well, the shell does not make use of any special kernel features
to expand globbed arguments, it recursively descends the directory
tree.  I'm addressing that aspect and I'm quite pleased with the
results.

If the kernel were to provide an equivalent function, I'd certainly
be keen to see it incorporated in the shell and any other similar
command and would try to motivate for it to be as powerful and/or
practical as possible.

I did read Rob's paper a while back, but I don't recall it addressing
filename expansion.  I could be mis-remembering, of course.

In defense of my point of view, I must add the following: adding
the "dironly" filter to the shell code (in the Readdir() function
of plan9.c - I have an interesting challenge in duplicating this
in unix.c, ironically) not only makes rc's behaviour consistent
with my Unix-based expectations but also reduces the resources
required for expanding big and/or deep directories quite considerably.

I think it was echo /*/*/*/*/*/*/*/* that blew up with the release
shell and completed (apparently successfully, although one may
question the sanity of such an operation) with the modified shell.

It goes without saying that echo /*/*/*/*/*/*/*/*/ is not even
vaguely useful under the original shell, even if there was as much
virtual memory available as required.

Now, I'm happy to confess that I don't know where the inconsistency
Geoff discovered originates, he may well be right that it stems
from poor kernel behaviour, but I'm not convinced.  The modified
shell seems to work correctly in both instances of:

term% srv myrtle myrtle /n/kremvax
post...
term% cd /n/kremvax/usr/share/sendmail
term% echo */.
LICENSE/. README/. cf/. domain/. feature/. hack/. m4/. mailer/. ostype/. sh/. siteconfig/.
term% /sys/src/cmd/rc/8.out -c 'echo */.'
cf/. domain/. feature/. hack/. m4/. mailer/. ostype/. sh/. siteconfig/.
term% /sys/src/cmd/rc/8.out -c 'echo */..'
cf/.. domain/.. feature/.. hack/.. m4/.. mailer/.. ostype/.. sh/.. siteconfig/..
term% echo */..
cf/.. domain/.. feature/.. hack/.. m4/.. mailer/.. ostype/.. sh/.. siteconfig/..
term%

The above mirrors the Unix (NetBSD) shell behaviour (I use pdksh,
incidentally) which, interestingly, the Plan 9 version does not:

term% ape/psh
bind: /386/bin/pub: '/386/bin/pub' does not exist
$ pwd
/n/kremvax/usr/share/sendmail
$ echo */
cf/ domain/ feature/ hack/ m4/ mailer/ ostype/ sh/ siteconfig/
$ echo */.
LICENSE/. README/. cf/. domain/. feature/. hack/. m4/. mailer/. ostype/. sh/. siteconfig/.
$ echo */..
cf/.. domain/.. feature/.. hack/.. m4/.. mailer/.. ostype/.. sh/.. siteconfig/..
$

So, I see that I may be chasing the wrong wild goose, but I'm only
tangentially masking what may be a kernel error.  The changes to
rc just happened to be misguided, initially, and accidentally caused
the additional problem to be fixed once I corrected my poor
understanding.  I would certainly be curious to get to the bottom
of Geoff's anomaly.

++L