instability in Berkeley versus A

[haahr at siemens.UUCP]

> > Nobody is arguing that the functionality isn't useful; it's just misplaced.
> > 
> > For an explanation of why "one program, one function, done well" is a good
> > way to build a system, see almost any discussion of the "Unix philosophy".
> 
> The problem is, that its very hard to define the "one function" in any
> way that's acceptable to more than a handful of people.
> 
> For listing a directory, my idea of "one function" would be to
> simply read the directory and print the names.  no more.  no
> sorting, no looking up attributes (stat calls), none of this
> unnecessary crud.  In fact, "ls" can do this, but you have to
> tell it "-f".
> 
> The real point is, of course, that by the time that you
> run a sh script like
> 
> 	ls | sort | mtimes | sizes | owner | links | permissions
> 
> every time you want what you would normally get with "ls -l"
> the whole system will die.

Yes.  But, aside from the fact that ls had the -l option, what makes
ls -l anything but another example of creeping featurism.  Berkeley ls
just takes a bad trend and makes it worse.  I want my ls command to be
what 4.2 and sysV call ls -1f.  This is useful to pipe to programs.
For a user interfaced version (maybe lsc) i would set a sh script or
alias of ls | grep -v '^\.' | sort | columnate.  If I find that this is
terribly slow, then maybe incorporate the checking for files beginning
with '.' into ls and provide a '-a' option, maybe even '-A' (same as
'-a' but without files '.' and '..') or maybe make it an option to trim
those files.  Next, if sorting is that important and the extra exec and
pipe I/O is a real slowdown, then add an option to for sorting, or even
make that the default.

ls -l is really a separate case.  It provides completely different
information.  Why not have one program which takes a list of named
files and produces ls -l style output.  Default might be the same as
ls or might be something else, and it might handle named directories
differently (ls -ld always seemed awkward to me, why not ls -l name and
ls -l name/*).   I personally think of ls -l as a very different program
from vanilla ls, and consider the bundling of the two a design problem.
Maybe I'm alone in this.

You suggest that the function that ls provide could be done as separate
filters.  Why not just provide wc like command line options for which
fields you want (lsl -is for inode number and size) and make the default
all.  Simple to implement.  Separate function from other programs
(program to return data from inode rather than list files in a directory).
Easy to understand what it does (no -[a-zA-Z]).  However, for the sake of
compatibility, things probably shouldn't be changed.  But ls -l isn't
a good example of anything.

> 		... surely sorting & columnising stand or
> fall together?

No more so than sorting and removing files that start with '.' are linked
or listing files and printing stat information on files are inseparably
bound.

> The real problem, is that there are people who imagine that
> the "one function" that a program is supposed to solve is
> the "one" that it originally solved, and that any change,
> either to delete "wrong" functionality, or add "new" functionality
> is automatically a "bad thing".  ...

It's just that the original design in Unix is, on average, good.  Not
to say that everything is the best it could possibly be, just not bad.

>				   ... (This is quite apart from the
> problem of incompatible versions, which really is a problem).

Yes.  No question there.

> Had "ls" output file names in columns from its first writing
> with an option to produce only 1 column when its output is
> being piped into some other program, then there would be none
> of this controversy.  (I know, people scream "but programs
> should always be written to assume that their output will
> be the input of another program")

Maybe, but I'm not sure that it would have.

> What's really hard to justify is having the output appear
> in a different form depending on where the output is going,
> but such is the price of backward compatability - and we
> *know* who it is that screams loudest whenever something
> is changed that "breaks" something, don't we?

Agreed.  But kludging things to be backward compatible in special cases
is definitely not the right way to add features.

> Robert Elz			ucbvax!kre kre at monet.berkeley.edu

> ps: K&P on this topic suggest using "pr" as a columnising filter.
> To my mind, "pr" is a paginator, its just as bad to make a paginator
> produce columns as some side effect as it is to make a directory
> listing program produce columns as a side effect - but of course,
> this was in "pr" from the beginning, so it is blessed...

It seems to me that a program for paginating might have to worry about
columns, but, yes this is probably not the best place to put a columnator.
On the other hand, it is possible to use the columnator from pr from other
programs, where with ls it's at very least kind of difficult (create a file
with the name of each line, do a ls -Cf, and hope that there aren't two
files with the same name? :-)
--
					Paul Haahr
					..!allegra!princeton!haahr