[9fans] ls question

[9fans] ls question

[David Tolpin]

cpu% bind -b tmp tmp
cpu% ls tmp
sam.err
sam.err
cpu% ls tmp/sam.err
tmp/sam.err
cpu%

I understand why it is so, but is it how it should be?

Re: [9fans] ls question

[Russ Cox]

David Tolpin wrote:

>cpu% bind -b tmp tmp
>cpu% ls tmp
>sam.err
>sam.err
>cpu% ls tmp/sam.err
>tmp/sam.err
>cpu%
>
>I understand why it is so, but is it how it should be?
>  
>

Yes.  Try this.

mkdir a b c d
 >a/f
 >b/f
bind a c
bind -a b c
bind a d
bind -b b d
ls -ln c
ls -ln d
ls -l c/f
ls -l d/f

Russ

Re: [9fans] ls question

[Russ Cox]

> ls -ln c
> ls -ln d


this was supposed to be ls -lnq.  sigh.

Re: [9fans] ls, rc question

[David Tolpin]

I am not asking why there are two file names in the directory listing. I understand it.

I think that behaviours of rc and ls are confusing. I would either expect rc's globbing
to only match one path name, or ls to display all files.

man rc says 'A pattern is replaced by a list of arguments, one
for each path name matched'. Not for each directory entry. For
each path name. There is one path name /dev/user for two files.

cpu% ls -q /dev|grep user
(0000000000000015 0 00) /dev/user
(000000000000000c 0 00) /dev/user

Globbing expands this to two elements:

cpu% echo /dev/user*
/dev/user /dev/user

I think this is not what the manual says. 

Then,

cpu% ls -q /dev/user*
(0000000000000015 0 00) /dev/user
(0000000000000015 0 00) /dev/user

I understand why it is so. But I think that consistency is sacrificed
for simplicity. Either rc should do what the manual says and return
one match for /dev/user* (so that /dev/user* and /dev/user is the same
thing), or ls -q /dev/user should recursively list all directory
entries matching the path name.

David Tolpin

Re: [9fans] dirread

[David Tolpin]

man 2 dirread

:...
:The data returned by a read(2) on a directory is a set of complete directory
:entries in a machine-independent format, exactly equivalent to the result of
:a stat(2) on each file or subdirectory in the directory.

But it is not so. stat(2) on each file in the directory, when
there are multiple files with identical names, will return
data for the first entry only.

What am I missing?

David

Re: [9fans] dirread

[ron minnich]

On Fri, 19 Mar 2004, David Tolpin wrote:

> 
> man 2 dirread
> 
> :...
> :The data returned by a read(2) on a directory is a set of complete directory
> :entries in a machine-independent format, exactly equivalent to the result of
> :a stat(2) on each file or subdirectory in the directory.
> 
> But it is not so. stat(2) on each file in the directory, when
> there are multiple files with identical names, will return
> data for the first entry only.

Let's see how much more I can get wrong. 

Pretend you have a union of /tmp and /tmp2 all bound onto /tmp. /tmp and 
/tmp2 have a file a in them. 

You read the dir and you get the union. So that sort of makes sense. 
You'll see all the /tmp/a twice.

You stat the entry, and the pathname resolutions rules apply, so even if 
there are multiple /tmp/a files, the stat of /tmp/a always resolves to 
"the one on top", thus you only get that stat info.

ron

Re: [9fans] dirread

[boyd, rounin]

> What am I missing?

lots ...

http://plan9.bell-labs.com/sys/doc/lexnames.html

Re: [9fans] dirread

[rsc]

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

the data for the file you cannot get at is
exactly equivalent to the result of stat(2)
if only you could get at it, except that your
name space is keeping you from doing that.
but it's still there.  ;-)

russ

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

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dirread
Date: Fri, 19 Mar 2004 03:31:37 +0400 (AMT)
Message-ID: <200403182331.i2INVbsA096235@adat.davidashen.net>


man 2 dirread

:...
:The data returned by a read(2) on a directory is a set of complete directory
:entries in a machine-independent format, exactly equivalent to the result of
:a stat(2) on each file or subdirectory in the directory.

But it is not so. stat(2) on each file in the directory, when
there are multiple files with identical names, will return
data for the first entry only.

What am I missing?

David

Re: [9fans] ls, rc question

[rsc]

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

if you want, you can think of this as a bug in read(2):
if a file is covered up, it should be completely hidden.
it turns out that actually implementing this is quite hard,
that it doesn't really break much (you've found about
all of it!) to leave it as is, and that it results in things
like /bin/ls giving interesting information about the union.

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

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question
Date: Fri, 19 Mar 2004 03:00:51 +0400 (AMT)
Message-ID: <200403182300.i2IN0p5T095713@adat.davidashen.net>


I am not asking why there are two file names in the directory listing. I understand it.

I think that behaviours of rc and ls are confusing. I would either expect rc's globbing
to only match one path name, or ls to display all files.

man rc says 'A pattern is replaced by a list of arguments, one
for each path name matched'. Not for each directory entry. For
each path name. There is one path name /dev/user for two files.

cpu% ls -q /dev|grep user
(0000000000000015 0 00) /dev/user
(000000000000000c 0 00) /dev/user

Globbing expands this to two elements:

cpu% echo /dev/user*
/dev/user /dev/user

I think this is not what the manual says. 

Then,

cpu% ls -q /dev/user*
(0000000000000015 0 00) /dev/user
(0000000000000015 0 00) /dev/user

I understand why it is so. But I think that consistency is sacrificed
for simplicity. Either rc should do what the manual says and return
one match for /dev/user* (so that /dev/user* and /dev/user is the same
thing), or ls -q /dev/user should recursively list all directory
entries matching the path name.

David Tolpin

Re: [9fans] ls, rc question

[David Tolpin]

> if you want, you can think of this as a bug in read(2):

In fact, I think both read(2) and stat(2) are OK.

The bug (or just inexact wording in the manual for read(2)).

But then either globbing should work differently (and looking
at the code in rc, i think it is easy to make it work as with union);
or the manual for rc should be changed as well.

Besides, then why bind(,,MBEFORE|MAFTER) is said to create a 'union' 
then? It is very confusing too. It does not. It creates a list, 
and name-oriented calls ([a-z]*stat, open) are restricted to only retrieve 
the first element in the list. Other calls can still traverse the list.


> that it doesn't really break much (you've found about
> all of it!) to leave it as is, and that it results in things
> like /bin/ls giving interesting information about the union.

Do you think that rc globbing returning as many identical words
as there are directory entries with the same name is in any
way useful too?

Re: [9fans] ls, rc question

[boyd, rounin]

> From: "David Tolpin" <dvd@davidashen.net>

got a problem with simple graphs?

Re: [9fans] ls, rc question

[ron minnich]

Well, I guess it's confusing the way some union stuff works, but once you
start trying to do things with unions to make them less weird, it can get
ugly fast, see this from a bsd list:

"  Perhaps one situation would be, modify a lower-layer file so that the
modified file now exists in the upper layer, with the original still in
the lower layer.  Then try to delete the file. The upper-layer version
will be deleted, but we don't want the lower-layer version to now start
showing up, because we 'delete'd it.  We also don't want to delete the
lower-layer version, because it's a union filesystem, and that's one of
the features of a union mount -- the lower layer is not allowed to change
(much).  So, cover up the lower-layer version with 'whiteout' in the upper
layer so that it becomes not visible to the union-mount, but still exists
via non-union-mount access. "

Also see rm -W on bsd. 

Or how about this: "Running find(1) over a union tree has the side-effect 
of creating a tree of shadow directories in the upper layer."

BSD does do this: "In this example, /b is layered over an empty directory
/mnt, then /a is layered over the new view of /mnt.  Duplicate names are
suppressed so that only one occurrence of `x' (and also `.' and `..')  
will appear." (see
http://www.usenix.org/publications/library/proceedings/neworl/full_papers/mckusick.a)

Seems once you start to try to get smart there's no end to it.

I've had it put to me that union mounts would so hopelessly confuse users
that they can't be used. The first time I showed them to a quite smart CS
person she blanched a bit -- "how can anybody use that given you don't
really know what those two files are?" And here I was showing it off --
"see how you can build kernels outside the kernel tree". The only reaction
was: "yeah but having two pccpu files show up in ls is hopelessly
confusing. " I had to disagree :-)

The thing is, reads from a union directory do in fact give you the union. 
But what would you do for stat etc? I'm not sure you could do much 
different that has been done without really making the kernel pretty 
dirty (see above).

ron

Re: [9fans] ls, rc question

[boyd, rounin]

yeah, you could get yourself into a real bind ...

Re: [9fans] ls, rc question

[Charles Forsyth]

>>The thing is, reads from a union directory do in fact give you the union. 

i think the argument is provoked by the assumption that it's a union of sets, preventing duplicates,
but the system happens to work with bags, not sets, where union can (must) allow duplicates.
i'd agree it's sometimes annoying but it's both explicable and understandable,
and (i'd say) not theoretically indefensible.   at a practical level, making the duplicates
visible happens to make it easy to illustrate (bind a directory to itself:
look, everything in it is duplicated).

Re: [9fans] ls, rc question

[Richard Miller]

>>>The thing is, reads from a union directory do in fact give you the union. 
> 
> i think the argument is provoked by the assumption that it's a union of sets, preventing duplicates,
> but the system happens to work with bags, not sets, where union can (must) allow duplicates.

Sorry, David is correct on this point.  Sets and bags are both
unordered, and union is therefore commutative.  But directories are
ordered -- the ordering is essential to resolve the ambiguity of
duplicate names.  So the accurate mathematical model is a sequence
(aka list), and bind is not union of sets or bags, but append of
sequences -- a non-commutative operator, hence the need to specify
MBEFORE or MAFTER.

-- Richard

Re: [9fans] ls, rc question

[boyd, rounin]

> Sorry, David is correct on this point.

BULLSHIT

hiding things will only wind up in nasty suprises, further down the track
...

Re: [9fans] ls, rc question

[Richard Miller]

> BULLSHIT

A soundly reasoned mathematical argument, very impressive.

Re: [9fans] ls, rc question

[Geoff Collyer]

Mathematics is a powerful tool, but not appropriate for solving all
problems.  I think that the things that made Unix and now Plan 9 most
appealing are matters of judgement and taste.  Obviously hard
technical work has also gone into those systems, but I don't believe
that that is enough to produce a compelling operating system.  I
wouldn't want to try to justify the creation or use of pipes or 9p or
namespaces or user-mode file servers solely using mathematics.

Re: [9fans] ls, rc question

[Richard Miller]

I said:
> Sorry, David is correct on this point.

<boyd@insultant.net> said:
> BULLSHIT

By "this point", I meant the observation that bind(..MAFTER|MBEFORE)
doesn't produce a union in the mathematical sense, but a list.  If
someone finds a reference anywhere in the mathematical literature to a
union operator which is non-commutative, I will happily retract my claim.

<geoff@collyer.net> said:
> Mathematics is a powerful tool, but not appropriate for solving all
> problems. ...

Agreed.  ("A mathematician, a physicist, and an engineer checked into
a hotel one night ... " No, you've all heard that one already.)

But when we use mathematical metaphors to explain the behaviour of
engineering artefacts, choosing a not-quite-right metaphor can
cause confusion.  As in this case.

-- Richard

Re: [9fans] ls, rc question

[Charles Forsyth]

>>By "this point", I meant the observation that bind(..MAFTER|MBEFORE)
>>doesn't produce a union in the mathematical sense, but a list.  If
>>someone finds a reference anywhere in the mathematical literature to a
>>union operator which is non-commutative, I will happily retract my claim.

a non-commutative union does occur when working with certain constructions
on trees (funnily enough) [for much the same reason that addition and
multiplication aren't always commutative] but i haven't got a good reference.

Re: [9fans] ls, rc question

[Charles Forsyth]

>>duplicate names.  So the accurate mathematical model is a sequence
>>(aka list), and bind is not union of sets or bags, but append of

you're right.  i was trying too hard to justify the term `union' (or not hard enough,
depending on how you look at it).  i've seen it argued elsewhere that union
directories ought to have used another term, for much these reasons.
still, they seem to work whatever you call them.

[9fans] Bind, look, everything is duplicated

[David Tolpin]

> visible happens to make it easy to illustrate (bind a directory to itself:
> look, everything in it is duplicated).

What I am proposing does not change this behaviour. Bind a directory
to itself, look (ls), everything is still duplicated. 

I do not propose a change in the behaviour of read().

I do propose a change that fixes a bug in rc's globbing routine.

Re: [9fans] ls, rc question

[Micah Stetson]

> Do you think that rc globbing returning as many identical words
> as there are directory entries with the same name is in any
> way useful too?

Of course!  Let's suppose you have a multipage document
that you want to print multiple copies of, but you want
all the copies of a single page to print together.  Well,
just split the document into one file per page and then
run 'bind -a . .' followed by 'lp *'.  How cool is that?
This example should make it clear that lp -c is a violation
of the tools approach.

Micah

(For the more serious among us, this is all 'tongue in cheek'.)

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> > Do you think that rc globbing returning as many identical words
> > as there are directory entries with the same name is in any
> > way useful too?
>
> Of course!  Let's suppose you have a multipage document
> that you want to print multiple copies of, but you want
> all the copies of a single page to print together.  Well,

Since I don't have a printer, here is a proposed change to rc/glob.c

cpu% diff /sys/src/cmd/rc/glob.c glob.c
31c31
<       word *a;
---
>       word *a, *b;
37c37,47
<       for(a = left,n = 0;a!=right;a = a->next,n++) a->word = list[n];
---
>       for(a = left,n = 0;a!=right;n++){
>               if(a->next!=right && globcmp(list+n,list+n+1)==0){
>                       b = a->next;
>                       a->next = b->next;
>                       efree((char *)list[n]);
>                       efree((char *)b);
>               }else{
>                       a->word = list[n];
>                       a = a->next;
>               }
>       }

Since rc sorts results of globbing expansion, it makes perfect
sense to only keep only one occurence of each path name. It bring
rc in synchronization with the manual; besides, repeated names
cannot be used for access to the files they are generated for so
they should be omitted.

I am not supplying it as  a patch because I actually want to know
opinions whether it makes sense.

David Tolpin

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Rob Pike]

> Since I don't have a printer, here is a proposed change to rc/glob.c

i don't like changing the shell to mask kernel behavior. it leads
to surprises.  consider unix shells that `fix' cd in a way that it
differs from the chdir system call.

i say leave it.  the current behavior doesn't break much and as
rsc says it can even be informative.

-rob

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> > Since I don't have a printer, here is a proposed change to rc/glob.c
>
> i don't like changing the shell to mask kernel behavior. it leads
> to surprises.  consider unix shells that `fix' cd in a way that it
> differs from the chdir system call.

1. There is no kernel behavior in glob.  It is just a pass over
a list, with results sorted after the pass.

2. The changes I propose make it conforming to the manual.

> i say leave it.  the current behavior doesn't break much and as
> rsc says it can even be informative.

It cannot. ls -q /dev/user* will not give information about 
two different user files. It will display the first /dev/user twice. 

There is a difference between

ls /dev |grep user

ls /dev/user*

ls /dev/user

While bringing two elements is informative in the first case (and I
do not propose to change it), in the second case it is not. It cannot
be used.

David

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

If 'echo /dev/user*' returns two-element list (if there are two files there),
then 'echo /dev/user' should return a two-element list too, if one cares
about kernel semantics in shell behavior.

If, however, it is just globbing, both should return one element.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Rob Pike]

> 1. There is no kernel behavior in glob.  It is just a pass over
> a list, with results sorted after the pass.

that's sophistry.  the data is generated by a read system call.
you're proposing making the shell differ from every other
program that reads directories.  that seems like a bad idea.

this is not a bug, it's a feature. i'd rather fix the manual than
add special code to applications.

-rob

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> > 1. There is no kernel behavior in glob.  It is just a pass over
> > a list, with results sorted after the pass.
>
> that's sophistry.  the data is generated by a read system call.
> you're proposing making the shell differ from every other
> program that reads directories.  that seems like a bad idea.

This is wrong. 

The data is generated by glob/globsort. The 'read' (in case of Plan9)
system call is buried deep into system-dependent implementations for
Unix, Plan9 and win32. Each using native calls of the underlying
operating system.

The semantics of globbing is (correctly) defined in 
a system-independent manner,  stating that each globbing result
is delivered once.

>
> this is not a bug, it's a feature. i'd rather fix the manual than
> add special code to applications.

Suppose I want to edit glob.c in rc.c. I am copying rc.c to $home/src/rc/.
and then delete definition of globsort from the file.  (This is
what I actually do when I edit system sources).

cpu% mkdir $home/src/rc
cpu% cp /sys/src/cmd/rc/glob.c $home/src/rc/.
cpu% bind -bc $home/src/rc /sys/src/cmd/rc
cpu% cd /sys/src/cmd/rc
cpu% mk
cpu% sam glob.c # delete definition of globsort
cpu% grep '^globsort' *.c
glob.c:globsort(word *left, word *right)
cpu% grep -n '^globsort' glob.c
cpu%

This is a bug.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Richard Miller]

> you're proposing making the shell differ from every other
> program that reads directories.  that seems like a bad idea.

The shell is the only program which applies a regular expression
match to the directory entries as it reads them.  If this is a
bad idea, it has a respectable history:

"Putting this expansion mechanism into the shell has several advantages:
the code only appears once, so no space is wasted and commands in general
need take no special action; the algorithm is certain to be applied
uniformly."  (D.M.Ritchie, "Unix Time-Sharing System: A Retrospective",
BSTJ July-Aug 1978)

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> From: "Richard Miller" <rm@hamnavoe.com>

Violation of protocol can result in permanent data loss -- RX02 manual

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Geoff Collyer]

But dmr's comment is talking about wildcard expansion ("filename
generation" in sh-speak), not directory-reading.  And his argument
does make sense in that context.  At minimum, you'd need to modify rc
and ape/sh to suppress duplicates.

Programs other than the shells read directories without expanding
wildcards, and if not also changed would behave inconsistently with
the shells.  They are at least: acme, bitsy/keyboard, cron, du,
exportfs, faces, gzip, listen, mk, mkfs, mothra, replica programs,
srvold9p, tar, vac, and winwatch.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> Programs other than the shells read directories without expanding
> wildcards, and if not also changed would behave inconsistently with
> the shells.

roll on VMS ...

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Geoff Collyer]

I thought my list of directory-reading programs was too short; I
forgot to grep for dirreadall also (not having ls on the list should
have been a tip-off).  It should also include: aux/depend, diff, ftpd,
history, kbmap, ls, mkpaqfs, netstat, news, pptpd, ps, rm, scp.  Not
too surprising on a system built on file servers.

The problem isn't so much breaking things as the inconsistent
behaviour that would result from suppressing duplicates only in some
programs.  This would be especially confusing to new users.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> From 9fans-admin@cse.psu.edu  Fri Mar 19 14:50:31 2004
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
> From: Geoff Collyer <geoff@collyer.net>
> Content-Type: text/plain; charset="US-ASCII"
> Date: Fri, 19 Mar 2004 02:50:50 -0800
>
> I thought my list of directory-reading programs was too short; I
> forgot to grep for dirreadall also (not having ls on the list should
> have been a tip-off).  It should also include: aux/depend, diff, ftpd,
> history, kbmap, ls, mkpaqfs, netstat, news, pptpd, ps, rm, scp.  Not
> too surprising on a system built on file servers.

Which of these programs uses globbing?

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

i'm neutral about the whole thing: i think it's fine as it is,
but woudn't fret too much if glob changed.  as it happens, i discovered only last year
that roger changed Inferno's Filepat (rhymes with cow pat) four
years ago to return a result that had the names sorted and unique
(it just required invoking an option in a lower-level routine).
i probably wouldn't have done it myself (partly for reasons below), but
on a list of changes that would end the world, it's fairly low on my list,
and i doubt it would cause much more trouble in Plan 9.
in practice, though, i find it makes very little difference, and i use both systems of course.

one reason might be that (in my experience) union mounts aren't much used in the small,
so there aren't a lot of them, and those there are tend to be used
to set up a larger structure (eg, /bin, /dev, /net, service directories) or to provide limited,
judicious replacement of one thing by another.  thus, except when
initially experimenting with the mechanism on seeing the system for the first time,
or testing things after changing the implementation, i rarely interact with union
directories through the user interface or scripts to the extent that i need worry in practice
about whether pattern matching returns duplicates or not for lp (say).
thus, i don't really care too much about the duplication effect.

furthermore, if worrying about pattern matching returning duplicates for a directory,
i'd have thought in practice it might be equally troublesome for the use of lp (say) that
	lp a*
would no longer produce duplicates, which is splendid, but
	lp a* *a* q/a*.[ch] q/*.[ch]
would of course still produce duplicates in general (as a simple example to
illustrate the point, there are probably more compelling ones).
you could therefore make good use of a nodup function (as geoff suggested) in general anyhow.
(its surrounding `{} limits the scope of the nodup operation.)
thus, you could just as well use it for the special case of duplicate names
possibly produced by a union directory.

i don't think union mount is particularly good at creating variant directory
structures for software development, because of the white-out and other problems
already mentioned; for that i suspect you want a different definition of union,
more like union of whole directory trees, and it seems both better and possible
to supply that through a user-level file server that can be precisely configured,
rather than putting too much load on the existing simple bind/union operations
in the kernel that are quite effective within their own scope.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

cheating with metacharacters will get you into woe,
union moints or not.  type ls first.

the amount of code required to fix this peculiar, but
extremely powerful, end case flies in the face of
good taste, good design and minimalism.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Presotto]

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

None, they just walk through the directory they get.

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

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
Date: Fri, 19 Mar 2004 15:12:54 +0400 (AMT)
Message-ID: <200403191112.i2JBCsTK000660@adat.davidashen.net>

> From 9fans-admin@cse.psu.edu  Fri Mar 19 14:50:31 2004
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
> From: Geoff Collyer <geoff@collyer.net>
> Content-Type: text/plain; charset="US-ASCII"
> Date: Fri, 19 Mar 2004 02:50:50 -0800
>
> I thought my list of directory-reading programs was too short; I
> forgot to grep for dirreadall also (not having ls on the list should
> have been a tip-off).  It should also include: aux/depend, diff, ftpd,
> history, kbmap, ls, mkpaqfs, netstat, news, pptpd, ps, rm, scp.  Not
> too surprising on a system built on file servers.

Which of these programs uses globbi ng?

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

>
> None, they just walk through the directory they get.

That's why I think those examples are not relevant. dirread semantics
stays intact. globbing semantics should correspond to its definition.

ls -l *.c

and 

ls -l

give different results now, without changes. The first form
will list some entries twice. The second form will list each
entry once, with some entries having the same name. 

I'm proposing to make the first form bring what it should. Namely,
to bring every entry once. How displaying the first occurence of
a file as many times as there are entries with the same name makes
it similar or consistent with the second form, I really don't get.

They are confusing now. The cause of the confusion is a bug in globbing.
The bug should be fixed.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Russ Cox]

David Tolpin wrote:

>I'm proposing to make the first form bring what it should. Namely,
>to bring every entry once. How displaying the first occurence of
>a file as many times as there are entries with the same name makes
>it similar or consistent with the second form, I really don't get.
>
>They are confusing now. The cause of the confusion is a bug in globbing.
>The bug should be fixed.
>  
>

Actually the cause of the confusion is not agreed upon,
as evidenced by the continuation of this discussion!

I'm perfectly happy with things as they are now, so that:

echo `{ls /dev | grep mouse}
echo /dev/*mouse*

produce the same output.  If you want to fix something, figure
out how to fix the kernel.  If 9P servers were required to sort
their directory entries then the kernel could just toss entries
easily during a merge.  Not that I'm proposing this.

Russ

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> I'm perfectly happy with things as they are now

I'm convinced. Many thanks for opinions.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Geoff Collyer]

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

> None, they just walk through the directory they get.

Actually, ftpd, mkfs and replica (pull at least) glob.

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

[-- Attachment #2.1.1: Type: text/plain, Size: 52 bytes --]

None, they just walk through the directory they get.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2733 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
Date: Fri, 19 Mar 2004 15:12:54 +0400 (AMT)
Message-ID: <200403191112.i2JBCsTK000660@adat.davidashen.net>

> From 9fans-admin@cse.psu.edu  Fri Mar 19 14:50:31 2004
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
> From: Geoff Collyer <geoff@collyer.net>
> Content-Type: text/plain; charset="US-ASCII"
> Date: Fri, 19 Mar 2004 02:50:50 -0800
>
> I thought my list of directory-reading programs was too short; I
> forgot to grep for dirreadall also (not having ls on the list should
> have been a tip-off).  It should also include: aux/depend, diff, ftpd,
> history, kbmap, ls, mkpaqfs, netstat, news, pptpd, ps, rm, scp.  Not
> too surprising on a system built on file servers.

Which of these programs uses globbi ng?

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[rog]

i'm in a minority here, so i'll say this and then shut up.

i think the symlink comparison is not really valid, as a symbolic link
is a potentially useful entity in its own right (hence tools that can
look at them in both ways) whereas a duplicate name signifies nothing
beyond the fact that the directory might be a union directory; there's
nothing useful that can be done with the name.

what this discussion boils down to is epitomised by boyd's:

> large N% of the time it's not a problem, so Leave It Alone:

basically union directories are used hardly at all, and when they are,
it's generally only in "special purpose" places, such as /bin, /cron,
etc.  of course, they're crucial in the places where they are used,
but it's not really the general mechanism that one gets the impression
of when reading the documentation (as one quickly realises when trying
to do unusual things with it, such as bind onto directories in
/n/dump).

i have a feeling almost nothing would break if the kernel was changed
to disallow reading of union directories completely...

> the arguments seem to focus on whether with a change here or there
> they could be got to do a little more work (eg, by allowing * to
> iterate exactly once over all services, protocols, say).
> i don't think it's that essential in practice.

not essential.

it'd just be nice.

for what it's worth, i had a look through the programs that
geoff mentioned, categorising how they react to union directories.

no (or unlikely) adverse consequences:
	pptpd
		controls own namespace
	bitsy/keyboard
	faces
	ps
	winwatch
		displays duplicates (but union unlikely)
	aux/depend
	exportfs
		reflects duplicates in exported namespace
	cron
	du
	aux/listen
	mk
		do their own duplicate elimination
	history
		could produce erroneous results on snap (but union unlikely)

displays duplicate entries/info:
	acme
	news
		display duplicate entries
	netstat
		displays duplicate info

inefficient:
	mkfs
	gzip/zip
	scp
		produces duplicate copy of file
	vac
		stores duplicate directory entries

questionable:
	rm
		removes all entries, including hidden ones

erroneous:
	ip/ftpd
	ls
		displays duplicates, with non-stable reordering of entries.
	diff
		reports spurious extra entries
	tar
		doesn't work properly, (but probably for reasons
		unrelated to union directory reading (try {tar c /bin | tar t})

unknown:
	replica/revproto
		not sure.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Scott Schwartz]

Rog writes:
| i'm in a minority here, so i'll say this and then shut up.
 
Just to give you some moral support, I think you've made
a lot of sense.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

>i have a feeling almost nothing would break if the kernel was changed
>to disallow reading of union directories completely...

but of course it would: i couldn't ls it at all.  i couldn't traverse the hierarchy at all.
you should spend more time in the Windows or OS worlds
where such restrictions are (were) commonplace!

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[rog]

> i couldn't traverse the hierarchy at all.

you could walk into it, which is all most things do operationally...

ls is nice ("look, here's a union directory and this is what's in it")
but i reckon almost none of the tools that are used by the system in
its day to day running actually read union directories.

union directory reading is most useful interactively.  most
non-trivial uses require elimination of duplicates.  for example, even
du(1) gets things wrong, i now realise.

> >>	rm
> >>		removes all entries, including hidden ones
> 
> it did years ago, but i don't think it does now.

it does.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

> >>	rm
> >>		removes all entries, including hidden ones
> 
> it did years ago, but i don't think it does now.

>it does.[?]

term% mkdir a
term% mkdir b
term% >a/x
term% >b/x
term% bind -b b a
term% ls a
a/x
a/x
term% rm a/x
term% ls a
a/x

i'm fairly sure it once had some code to do that but it doesn't now.

rm -r will remove them all -- but that's exactly what it's
supposed to do: empty the directory, surely!
indeed, it's interesting that here's an example where the underlying
mechanism seems to encourage just the right behaviour!

i also note that ls a showed two x's the first time,
then i removed one, leaving one, which seems good accounting
to me ...  in fact, with the `show only one name' approach,
surely it would be the Ruby principle of least surprise
to leave `a' empty so rm should revert to its `questionable' behaviour!

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

come to think of it, if i expect {rm -r a} to empty (and delete) `a'
might i not expect {rm a/*} and especially {rm -r a/*}
to remove all removable names from `a'?

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[ron minnich]

On Tue, 23 Mar 2004, Charles Forsyth wrote:

> come to think of it, if i expect {rm -r a} to empty (and delete) `a'
> might i not expect {rm a/*} and especially {rm -r a/*}
> to remove all removable names from `a'?

seems right. There's a lot of subtleties to the union thing. I think that 
Plan 9's decision (present it to the users in its entirety) is the right 
one.

ron

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> seems right. There's a lot of subtleties to the union thing. I think that 
> Plan 9's decision (present it to the users in its entirety) is the right 
> one.

yup

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[rog]

> > come to think of it, if i expect {rm -r a} to empty (and delete) `a'
> > might i not expect {rm a/*} and especially {rm -r a/*}
> > to remove all removable names from `a'?
> 
> seems right. There's a lot of subtleties to the union thing. I think that 
> Plan 9's decision (present it to the users in its entirety) is the right 
> one.

it's a trade-off.  some things work better, some things work worse.

having said that, the above is the only occasion i've seen that makes
use of the duplicate names in any kind of a sensible manner (but
remove (and rename) is a strange operation in a union directory anyway
- remove("x") does not necessarily mean that "x" goes away).  i
excluded write operations originally, and marked the rm behaviour as
"questionable" because i believe it can be argued both ways.  union
directories themselves cannot be removed, so one's on fairly shaky
ground trying to rm -r them...

most tools read a directory in order to enumerate its accessible
items.  in that context, seeing unique names only is more correct.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[a]

// ...union directories are used hardly at all, and when they are,
// it's generally only in "special purpose" places...

for what it's worth, the lab i was in at BL did a fairly complete
overlay on top of 1127's file server with our own tree. as i recall
our /lib/namespace approached 350 lines. we were pushing hard on
what the kernel was expecting that file to do, and did run into
issues on occasion, but for the most part it just worked, and was
very nice to use in practice. obviously, we would've been SOL had
the kernel not allowed reading union directories.

if i remember correctly, one user even had a fairly complicated
additional overlay of his own as his home directory was split
between our own and 1127's file servers (and he managed to be a
huge user on both ;-).
ア

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Geoff Collyer]

The place where our massive overlay didn't work too well was building
kernels from 1127 sources with a few of our own source files.  The
overlay file server that Russ and I wrote attempted to solve that but
also required a minor change to mk.  Unfortunately we wrote it using
the first public version of lib9p, which has since changed quite a
bit.  I'd like to take another stab at it once I've finished my
current round of file servers.

Actually most of my files remained on 1127's file servers, where they
had started out.  I had relatively few files on our departmental file
server, though obviously the overlay worked well enough that Anthony
couldn't tell. ☺  I felt a little bad about hogging 1127's optical
storage, but then Ken had ~160GB of compressed music on ours by the
end, which relieved my guilt somewhat.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Richard Miller]

> i don't like changing the shell to mask kernel behavior. it leads
> to surprises.  consider unix shells that `fix' cd in a way that it
> differs from the chdir system call.

But filename pattern matching in the shell is already different from
just reading a directory in the kernel.  By saying 'ls /tmp/*.c'
instead of 'ls /tmp' you are asking for a selection of names.  The
question is how many times to select a name which matches more than
one file.

As David has pointed out, the rc manual at present unambiguously says
"A pattern is replaced by a list of arguments, one for each path
name matched" -- not "one for each file matched".  So if rc isn't
changed, the manual does need to be corrected.

But I would vote for changing rc.  Although I am (after some years
of experience) sufficiently used to unions that I don't find the
behaviour surprising, I do find it irritating: for example, when
doing 'grep XXX *.c' in a union directory produces duplicate output
for files which occur in more than one underlying directory.

-- Richard

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Geoff Collyer]

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

But in the case of a union directory with duplicate names, potentially
representing distinct files, there are multiple names, not all of them
distinct, in the directory.  Since rc(1) doesn't say ``one for each
distinct [or unique] path name matched'', one could argue that neither
code nor manual needs change.

If it's really a problem,

	fn nodup {ls -d $*|uniq}
	pr `{nodup *} | lp

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

From: Richard Miller <rm@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
Date: Fri, 19 Mar 2004 08:31:25 0000
Message-ID: <50440c6f4b6946137968d772dcf08a2a@hamnavoe.com>

> i don't like changing the shell to mask kernel behavior. it leads
> to surprises.  consider unix shells that `fix' cd in a way that it
> differs from the chdir system call.

But filename pattern matching in the shell is already different from
just reading a directory in the kernel.  By saying 'ls /tmp/*.c'
instead of 'ls /tmp' you are asking for a selection of names.  The
question is how many times to select a name which matches more than
one file.

As David has pointed out, the rc manual at present unambiguously says
"A pattern is replaced by a list of arguments, one for each path
name matched" -- not "one for each file matched".  So if rc isn't
changed, the manual does need to be corrected.

But I would vote for changing rc.  Although I am (after some years
of experience) sufficiently used to unions that I don't find the
behaviour surprising, I do find it irritating: for example, when
doing 'grep XXX *.c' in a union directory produces duplicate output
for files which occur in more than one underlying directory.

-- Richard

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Rob Pike]

are you planning to change the other shells too? what about every other 
program
that reads directories?  what does '*' really mean? you're making 
assumptions
about what's right and i don't think it's clear what's right and when 
things aren't
clear i say leave them alone until they clear up. after something like 
15 years
they still haven't cleared up.

i'm not saying the behavior is right, but i'm not admitting it's wrong, 
either.
moreover, i can explain everything that's going on by applying a very 
simple
model that is clear from the documentation. that's worth a lot.

-rob

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

> are you planning to change the other shells too? 

Yes for all which require to do so.  Are there other documented
shells for Plan9?

> what about every other program that reads directories?  

No, I do not. I am not proposing to change the behavior of dirread().

> what does '*' really mean? 

The meaning is defined in manual for rc.

you're making 
> assumptions
> about what's right and i don't think it's clear what's right 

I just read the manual.

> i'm not saying the behavior is right, but i'm not admitting it's wrong, 
> either.
> moreover, i can explain everything that's going on by applying a very 
> simple
> model that is clear from the documentation. that's worth a lot.

For every problem there always exists a simple, easy to understand,
incorrect solution.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Scott Schwartz]

> are you planning to change the other shells too?

I think having a standard glob routine that all shells (and other
programs!) used would be desirable.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[ron minnich]

On Fri, 19 Mar 2004, Scott Schwartz wrote:

> > are you planning to change the other shells too?
> 
> I think having a standard glob routine that all shells (and other
> programs!) used would be desirable.


maybe a tool! we could call it glob. The shell could call it so that we 
got standardized globbing.

I recommend putting it in /etc

ron
p.s. Yes, :-)

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[9nut]

> maybe a tool! we could call it glob. The shell could call it so that we 
> got standardized globbing.
> 
> I recommend putting it in /etc
> 
> ron
> p.s. Yes, :-)

If you get this joke, you may qualify for a Senior discount at Denny's. ☺

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[david presotto]

I would be most disturbed if 'ls' and 'ls *' returned different numbers
of entries.

The fact that 'ls -l' and 'ls -l *' show different properties bothers me
less.  I see it as a failure of  ls and not globing.  However, requiring
ls to read the whole directory every time seems silly.

I wouldn't mind if the kernel threw out the unreachable entries when
you read a directory.  However, I don't think its worth the effort or
the likely bugs.  This is what  I would change, if anything since it is
the source of the problem and 'fixing' it in rc just makes rc and globing
in general odd.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[ron minnich]

On Fri, 19 Mar 2004, david presotto wrote:

> I wouldn't mind if the kernel threw out the unreachable entries when you
> read a directory.  However, I don't think its worth the effort or the
> likely bugs.  This is what I would change, if anything since it is the
> source of the problem and 'fixing' it in rc just makes rc and globing in
> general odd.

in the mode of lnfs, for people who care, make a uniquefs that enforces 
bsd-like behavior?

ron

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

>>in the mode of lnfs, for people who care, make a uniquefs that enforces 
>>bsd-like behavior?

that was what i was alluding to earlier, although the uniqueness didn't seem to me to be
the main thing, it's having the effect of `recursive bind' (taking unions over whole
trees), white-out, and similar things that would be useful when
compiling variant versions, including experimental ones,
in the style of ClearCase (but without the need for a dedicated administrator!).

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

>>I wouldn't mind if the kernel threw out the unreachable entries when
>>you read a directory.  However, I don't think its worth the effort or

the trouble with that is that it's sometimes quite important to see
that there are duplicates and what they are, if only to diagnose
an unexpected effect caused by a union, so i think you'd need some way to
give an equivalent effect, as i think rsc mentioned earlier.

roger's away so i'll give his observation that the result of ls -l on a union
directory (or reading a union directory and sorting it)
will be less useful or even misleading unless the sort is stable.
if you can rely on that, you know the attributes of the files of the same name below in
the union appear in the correct order (which allows quick checks on the state of the union).
of course, /proc/$pid/ns will give some of that for the
directories involved, but when it is a particular file or files
that you worry about, {ls -l | grep}
seems a natural thing to use to check their attributes.
as it happens, i don't think Plan 9's sort is stable:

term% ls -l /bin|grep 8c
--rwxrwxr-x M 9 forsyth inferno    303305 Dec 10 18:11 /bin/8c
--rwxrwxr-x M 9 sys     sys    299674 Feb 17 03:59 /bin/8c
term% ls -l /bin/8c
--rwxrwxr-x M 9 sys sys 299674 Feb 17 03:59 /bin/8c

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Presotto]

The number of times I've reliably used the duplicates in a
listing to see a namespace problem has been 0.  Ns is the
only tool I've ever found useful there.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Richard Miller]

> I would be most disturbed if 'ls' and 'ls *' returned different numbers
> of entries.

term% cd /
term% ls|wc
     40      40     202
term% ls *|wc
   1056    1056   10972

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[a]

// ...ls|wc...

different cause and different context. there ls
is being instructed to do different things. i
think presotto had an implied "in a dir with only
plain files" or something similar.
ア

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Richard Miller]

> i
> think presotto had an implied "in a dir with only
> plain files" or something similar.

... and I hope he realised I was only teasing.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Presotto]

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

come on, you know what I meant.

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

From: Richard Miller <rm@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
Date: Fri, 19 Mar 2004 16:34:12 0000
Message-ID: <240892daccaec2131635fbd4917479de@hamnavoe.com>

> I would be most disturbed if 'ls' and 'ls *' returned different numbers
> of entries.

term% cd /
term% ls|wc
     40      40     202
term% ls *|wc
   1056    1056   10972

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[rog]

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

for programs that require read-write access to a namespace,
requirements are different, as charles points out.

however, most tools do not write to the namespace.

for me, one of plan 9's fundamental strengths is that while a tool is
often written to access a predefined portion of the namespace, the
actual namespace that it sees can be arranged at will for the tool in
question.

thus if a program accesses files in directory /d, i think it's
reasonable to expect that if i bind another directory, say /b, before
/d, i can expect the program to treat /d exactly as if i had really
replaced the files therein with files from /b.

the program shouldn't have to *care* whether it's dealing with a union
directory or not - that should be solely the concern of whoever's
arranging the namespace.

i think the difference between:

	bind /dev/null /bin/ls

and

	mkdir /tmp/x
	> /tmp/x/ls
	bind /dev/null /tmp/x/ls
	bind -b /tmp/x /bin

should be invisible, particularly to shell scripts, which have no
concept of sequentially reading a directory, and which are often short
and trivial, but for which the above invariants are still important.

russ:
> if a file is covered up, it should be completely hidden.
> it turns out that actually implementing this is quite hard,

i.e.  the visibility of mutiple names in a directory is an
implementation issue.  it's something that's easily solved at user
level (no problems with arbitrary buffering there, and programs can
eliminate duplicates in their own way if they like as, for example,
du(1), mk(1), cron(1) listen(1) do).

i think it should be made as easy as possible to write programs that
behave in a namespace-agnostic way.  i think that if a version of
dirreadall was available that eliminated duplicates, most (all?)
programs would wish to use it.

i think it's particularly silly that

	wc */*.[ch]

should give me erroneous results in a union directory,
and that

	echo /bin/ape/*

should be different from

	echo /bin/ape*/*

when there's only one accessible directory starting "ape" in /bin, and
the shell's sorting the globbed output anyway.

i think eliminating duplicates in two core places would break nothing,
but make parts of the system work more smoothly together.

it's one less thing to think about.

geoff points out many programs that use dirread.  a random inspection
turns up many programs that already do their own elimination of
duplicates (in different ways), and others that behave badly in the
face of duplicate directory entries (e.g.  diff).

this seems to me to point towards a systematic problem, which should
be solved centrally.

towards this end, i've attached a stable sort routine, along the same
lines as qsort(2), which can optionally eliminate duplicates.  i've
tested it to a degree, but not greatly; i haven't done any performance
analysis of it, but i doubt that's a limiting factor in this case.

i envisage ls(1) being changed to use this routine (with an option to
show/suppress duplicate entries), and perhaps a version of dirreadall
that sorts the directory entries alphabetically and eliminates
duplicates, to make it easy to replace it in existing programs.


PS it's interesting to note that ls(1) does make some sort of an
effort to do a stable sort:

	if(i == 0)
		i = (a<b? -1 : 1);

but it's simple minded (in fact, i'm a little bit surprised it doesn't
kill qsort).  a sequence field in the NDir structure could fix it.

[-- Attachment #2: mergesort.c --]
[-- Type: text/plain, Size: 1025 bytes --]

#include <u.h>
#include <libc.h>
	
int
mergesort1(int uniq, char *a, int r, int width, int (*compare)(void*, void*), char *b)
{
	int m, n0, n1, i, j, k, e, c;
	if(r <= width)
		return r;
	m = ((r/width-1)/2 + 1) * width;
	n0 = mergesort1(uniq, a, m, width, compare, b);
	n1 = mergesort1(uniq, a+m, r-m, width, compare, b);
	memcpy(b, a, n0);
	memcpy(b+n0, a+m, n1);
	e = n0+n1;
	i = 0;
	j = n0;
	k = 0;
	for(; i < n0 && j < e; k += width){
		c = (*compare)(b+i, b+j);
		if(c > 0){
			memcpy(a+k, b+j, width);
			j += width;
		}else{
			memcpy(a+k, b+i, width);
			i += width;
			if(c == 0 && uniq)
				j += width;
		}
	}
	if(i < n0){
		memcpy(a+k, b+i, n0-i);
		k += n0-i;
	}else if(j < e){
		memcpy(a+k, b+j, e-j);
		k += e-j;
	}
	return k;
}

int
mergesort(int uniq, void *a, long n, long width, int (*compare)(void*, void*))
{
	void *b;
	n *= width;
	b = malloc(n);
	if(b == nil)
		return -1;
	n = mergesort1(uniq, a, n, width, compare, b);
	free(b);
	return n / width;
}

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

presto:  ls == ls *

QED

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[ron minnich]

assume lsfilter takes a stream of plan 9 stat structs and turns them into
an 'ls'-like listing

bind -b /usr/rminnich/bin /bin

lsfilter</bin

ls /bin

should these yield the same results? If you don't care, then the libc.a 
approach is fine. If you do want the same results, I think you may be 
stuck doing the uniqueness tricks in the kernel a la BSD, which to me 
anyway is unattractive.

You end up picking your inconsistencies. Right now the inconsistencies are 
due to a very simple implementation which acts the same all the time (to 
me anyway). 

I'm not arguing either way, just wondering.

I also have to wonder about the perceived inconsistent behavior of union
directories and the hacks that people keep developing (BSD) or proposing
(this list) to deal with those inconsistencies. Could this imply that my
CS friend was right and we've got to find another way to get what unions
get us now? I.e. as much as we love them, does the very idea of unions
have a fundamental flaw that requires us to think up something newer and
cleverer? I can't imagine what that could be. Just wondering.

ron

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

>>I also have to wonder about the perceived inconsistent behavior of union
>>directories and the hacks that people keep developing (BSD) or proposing
>>(this list) to deal with those inconsistencies. Could this imply that my

i think it's only a problem when one expects them to do too much:
recursive combination of two directories is an example (yet that's
usually what's needed in general for versioning, i think).
they are an effective way of doing what they usually do now:
build up directories of services and other resources
from many sources, local and remote, including substituting
one for another.   the naming seems consistent to me.
if a name appears in a directory, i can use that name.
whether it appears once or twice, doesn't matter.

the arguments seem to focus on whether with a change here or there
they could be got to do a little more work (eg, by allowing * to
iterate exactly once over all services, protocols, say).
i don't think it's that essential in practice.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Enache Adrian]

On Sun, Mar 21, 2004 a.d., ron minnich wrote:
> should these yield the same results? If you don't care, then the libc.a 
> approach is fine. If you do want the same results, I think you may be 
> stuck doing the uniqueness tricks in the kernel a la BSD, which to me 
> anyway is unattractive.

I'm afraid the uniqueness tricks are done in library/userland in BSD.
(the McKusick paper referred to in lexnames.html already tells it).
Just try to read a "-o union" mounted directory with open/getdirentries.

The hack is in libc/gen/opendir.c. Quoting from there:
                /*
                 * The strategy here is to read all the directory
                 * entries into a buffer, sort the buffer, and
                 * remove duplicate entries by setting the inode
                 * number to zero.
                 */
Only bloating the kernel with a sort/uniq filter could be worse than that.

Regards,
Adi

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> The hack is in libc/gen/opendir.c. Quoting from there:
>                 /*
>                  * The strategy here is to read all the directory
>                  * entries into a buffer, sort the buffer, and
>                  * remove duplicate entries by setting the inode
>                  * number to zero.
>                  */
> Only bloating the kernel with a sort/uniq filter could be worse than that.

pure bsd.

i can't see the point in adding more code to handle end cases.

large N% of the time it's not a problem, so Leave It Alone:

    http://www.lyricsdepot.com/living-colour/leave-it-alone.html

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> the program shouldn't have to *care* whether it's dealing with a union
> directory or not - that should be solely the concern of whoever's
> arranging the namespace.

Absolutely.  However, I don't mind there being some obscure way to 
examine what is mounted in more detail, so long as it is not the 
facility usually used by apps.  (Consider Unix treatment of symbolic 
links; you usually want to follow them but not always, thus lstat(2) vs. 
stat(2).)

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

>>facility usually used by apps.  (Consider Unix treatment of symbolic 
>>links; you usually want to follow them but not always, thus lstat(2) vs. 
>>stat(2).)

it's a good example of how that approach breaks down:
there isn't any way to tell from the outside how any given application
will deal with symbolic links.  for instance,
some versions of ls follow them (unless given -L), others do not,
following different reasonable rationales.

if i tar up a tree, am i interested in following the links (ie, i want
the tree's contents) or recording them (ie, i want the tree's
structure)?  it might depend on the link!  fortunately tar has lots of
options, but the default is to copy the structure (-h follows all
symbolic links).

generally, the approach seems to be for directory-traversing programs
and programs such as mv do not follow the links, but programs that
open files naturally follow the links.

so cp follows the links.

unless it's cp -R!  then there are three options -H, -L, and -P
to (attempt to) control handling of symbolic links, distinguishing
between names on the command line that happen to be links,
and names in the structure that are links.

in some ways, it's rather worse with symbolic links.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> it's a good example of how that approach breaks down:
> there isn't any way to tell from the outside how any given application
> will deal with symbolic links.  for instance,
> some versions of ls follow them (unless given -L), others do not,
> following different reasonable rationales.

symlinks really mess things up.  i think the only time i use
them is to point at the current version of the file or directory
and they only ever link to a 'file' in the same directory.

the (revolting) output of ls make it very obvious what the
link points too.  i could use hard links, but sorting through
inums is no fun.

a case in point is the lunix sam Make.* files.  i symlink the
right one(s) to Makefile.  i think it's a clean approach, but
i don't symlinks because they add far too much complexity,
another system call, more bits and in practice they are
grossly abused.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Derek Fawcus]

On Mon, Mar 22, 2004 at 01:15:19PM +0100, boyd, rounin wrote:
> 
> a case in point is the lunix sam Make.* files.  i symlink the
> right one(s) to Makefile.

make -f 

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> make -f

try that in the top dir?

is it maintainable?

i just wanna cd and type make/mk and have the job done.
i save 3 chars and  lotta time poking around in files.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[a]

/ I would be most disturbed if 'ls' and 'ls *' returned
// different numbers of entries.

i was totally with David T. on this one until i read this. now i
see that the coice is really that either 'ls' and 'ls *' can agree,
-*or*- 'ls /tmp/foo' and 'ls /tmp/foo*' can agree. changing globing
as proposed will make the later true and the former false, which,
as presotto notes, is likely to be much more confusing. the fix
really would have to be a kernel-level change, and that's a much
bigger deal.

fwiw, it was a decent suggestion on a tricky point, and many 9fans
are still confusing what david was suggesting/asking for with a
dirread change which he *wasn't* asking for.
ア

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[lucio]

> If you get this joke, you may qualify for a Senior discount at Denny's. ☺

MKS tools.  Unless there was prior art that I don't know about.

I have a lot to thank Mortice Kern for.

++L

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Charles Forsyth]

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

sorry, you must be under age.

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

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c
Date: Fri, 19 Mar 2004 17:53:22 +0200
Message-ID: <b61261937c345ff6347ff41960bb239f@proxima.alt.za>

> If you get this joke, you may qualify for a Senior discount at Denny's. ☺

MKS tools.  Unless there was prior art that I don't know about.

I have a lot to thank Mortice Kern for.

++L

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[andrey mirtchovski]

>> If you get this joke, you may qualify for a Senior discount at Denny's. ☺
> 
> MKS tools.  Unless there was prior art that I don't know about.
> 
> I have a lot to thank Mortice Kern for.

Ron showed me his 6th Ed. Manual day to prove that glob was indeed a
binary, a dæmon running on the system.

andrey

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[ron minnich]

On Fri, 19 Mar 2004, andrey mirtchovski wrote:

> Ron showed me his 6th Ed. Manual day to prove that glob was indeed a
> binary, a dæmon running on the system.

not a daemon, but yeah a binary.

ron

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[lucio]

> Ron showed me his 6th Ed. Manual day to prove that glob was indeed a
> binary, a dæmon running on the system.
> 
You mean a predecessor of the Plan 9 file server concept?  <grin>

++L

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

From: "ron minnich" <rminnich@lanl.gov>
> maybe a tool! we could call it glob. The shell could call it so that we 
> got standardized globbing.

it'll never work, guv.  no chance, zero, zip, nada ...

;)

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Russ Cox]

Rob Pike wrote:

> are you planning to change the other shells too? what about every 
> other program
> that reads directories?  what does '*' really mean? you're making 
> assumptions
> about what's right and i don't think it's clear what's right and when 
> things aren't
> clear i say leave them alone until they clear up. after something like 
> 15 years
> they still haven't cleared up.
>
> i'm not saying the behavior is right, but i'm not admitting it's 
> wrong, either.
> moreover, i can explain everything that's going on by applying a very 
> simple
> model that is clear from the documentation. that's worth a lot.


continuing this...

note how much more complicated the model gets if rc and ls
(or perhaps dirreadall) start removing duplicates from the list.
right now, it took you no time at all to find the existence of duplicates,
and then once you realize they exist, you notice them everywhere.

if the bulk of directory-processing programs remove duplicates
for themselves, then some day you run across a program that
doesn't (either out of neglect or because it doesn't fit the way the
program does directory processing).  now you know duplicates
exist again.  but nothing makes sense -- why haven't you noticed
before?  why do some programs show them and others not?
the explanation isn't simple or regular or predictable -- some do, some 
don't,
depending on their code. 

i'd rather live in the first world, where all programs agree.
the alternate universe, where illusions come and go depending on
the program, where shortcomings of the kernel are fixed by hacking
around them in user space, it's a terrible way to live.  if you want
modern unix, you know where to find it.

the clearest example i can think of in modern unix where this
happens is the handling of .. by shells in order to make symlinks
look not like symlinks, while the kernel is still broken, as rob points
out in http://plan9.bell-labs.com/sys/doc/lexnames.pdf.  there are
plenty of others.

russ


p.s. amusingly enough, now we've filled in all the context necessary
to read boyd's first post in this thread, where he posted that url
and nothing else!

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[David Tolpin]

>
> continuing this...
>
> note how much more complicated the model gets if rc and ls
> (or perhaps dirreadall) start removing duplicates from the list.
> right now, it took you no time at all to find the existence of duplicates,
> and then once you realize they exist, you notice them everywhere.

I didn't propose ls to remove duplicates from the list. ls should not.
rc should from the list of globbing results. It is written in the manual.
>
> if the bulk of directory-processing programs remove duplicates

globbing is not directory processing.

> i'd rather live in the first world, where all programs agree.

echo x

and

echo x*

will bring different results for a directory with two entries
named x . The program does not agree with itself. Globbing has
little in common with directory reading.

> out in http://plan9.bell-labs.com/sys/doc/lexnames.pdf.  there are
> plenty of others.
>
> p.s. amusingly enough, now we've filled in all the context necessary
> to read boyd's first post in this thread, where he posted that url
> and nothing else!

I had read that article, I do know the problem with symlinks,
and this problem is not related to the one I'm discussing.

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[boyd, rounin]

> i say leave it.  the current behavior doesn't break much and as
> rsc says it can even be informative.

yup, Leave it Alone -- Living Colour

Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[Russ Cox]

Rob Pike wrote:

>> Since I don't have a printer, here is a proposed change to rc/glob.c
>
>
> i don't like changing the shell to mask kernel behavior. it leads
> to surprises.  consider unix shells that `fix' cd in a way that it
> differs from the chdir system call.


<mutters about mail reader showing messages in wrong order...>

Re: [9fans] ls question

[David Presotto]

yes

Re: [9fans] ls question

[matt]

what did you expect it to be ?

if you understand it, what for the question?

ls -q will give you the qids too see if the files are identical

directories are just files so effectively ls is doing

for (directory in bindlist)
	cat $directory | format_directory_output


m

Re: [9fans] ls question

[David Tolpin]

> what did you expect it to be ?

I would expect it to be

cpu% bind -b tmp tmp
cpu% lc -l tmp
sam.err
sam.err
cpu% lc -l tmp/sam.*
sam.err
sam.err
cpu% lc -l tmp/sam.err
sam.err
sam.err

Re: [9fans] ls question

[boyd, rounin]

la question