9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] union directories
Date: Mon,  3 Mar 2003 13:05:41 -0500	[thread overview]
Message-ID: <0a304f2dd88c5bdb8eb1ce403c53e037@plan9.bell-labs.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0303031039150.25006-100000@carotid.ccs.lanl.gov>

> Actually I have had more Unix-oriented folks ask me if in a union ls 
> there could be an option, per-file, to display the binding for that file 
> when there is more than one. 

Per-file options are a bad idea not even worth talking about.

> I got real complaints from people about seeing multiple files with the 
> same name on an ls. 

Ls tells the truth!  I see no value in causing it to lie.
And then once ls lies, why doesn't ls *?  Why doesn't acme?
Ls does one thing.  It does it well.  It's consistent with the
rest of the system.  If you want sort -u, you know where to
find it.

There might be good arguments that directory reads should
reflect the information in the mount table, perhaps eliding
duplicates and perhaps showing you the real stat info for 
bound-over files (what you'd get with stat(2)).  Then again
there are also good arguments for the way things are now.

Read the ksh example in the lexnames paper.  The last thing we
need is user-space programs that ``patch'' kernel behaviors.
Arguing that the kernel needs fixing might be reasonable.
Changing ls to hack around perceived kernel deficiencies
is the path to madness (or to Linux, take your pick).

Russ



  reply	other threads:[~2003-03-03 18:05 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 13:18 rog
2003-03-03 17:40 ` Ronald G. Minnich
2003-03-03 18:05   ` Russ Cox [this message]
2003-03-03 18:09     ` Ronald G. Minnich
2003-03-03 18:16       ` Russ Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-03-03 20:45 Keith Nash
2003-03-03 20:51 ` Russ Cox
2003-03-03 20:00 Keith Nash
2003-03-03 20:05 ` Russ Cox
2003-03-03 18:58 rog
2003-03-03 23:17 ` anyrhine
2003-02-28 18:52 Joel Salomon
2003-02-28 18:56 ` Russ Cox
2003-02-28 21:16   ` Jack Johnson
2003-02-28 22:58   ` Geoff Collyer
2003-02-28 23:19     ` Jack Johnson
2003-02-28 23:59       ` Geoff Collyer
2003-02-15 19:37 [9fans] presentation preparation Scott Schwartz
2003-02-15 19:48 ` andrey mirtchovski
2003-02-27  9:35   ` Ralph Corderoy
2003-02-28 18:44     ` [9fans] union directories Jack Johnson
2003-02-28 18:53       ` Russ Cox
2003-03-04  9:44       ` Adrian Tritschler
2001-03-23 13:30 G. David Butler
2001-03-23 13:08 rog
2001-03-26  8:44 ` Douglas A. Gwyn
2001-03-22  3:28 rob pike
2001-03-23 10:06 ` Douglas A. Gwyn
2001-03-22  2:57 Gorka Guardiola Muzquiz
2001-03-22  2:46 Gorka Guardiola Muzquiz
2001-03-22  2:42 Gorka Guardiola Muzquiz
2001-03-22  2:37 Russ Cox
2001-03-22  2:02 Russ Cox
2001-03-22  1:56 Gorka Guardiola Muzquiz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a304f2dd88c5bdb8eb1ce403c53e037@plan9.bell-labs.com \
    --to=rsc@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).