instability in Berkeley versus AT&T releases (absurdly long)

[Robert Elz]

In article <5852 at utzoo.UUCP>, henry at utzoo.UUCP (Henry Spencer) writes:
> 
> 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.  (This asumes that each of the named
commands reads stdin, extracts the file name (last word on each line)
and prepends its info to the start of the line, to make a listing
that looks just like "ls -l" does now.  Of course, it would be nearly
impossible to do things just this way, but you get the idea.  And
imagine the flexibility, if you want reversed sort by size, just do
	ls | mtimes | sizes | nort -nr | owner | links | permissions
Try doing that with a "standard" ls!).  Really, even this is wrong,
none of these tools should worry about making the output line up in columns,
really what should happen is the output fields should be separated
by tabs, so to make a neat looking "ls -l" you would do..
    ls | sort | mtimes | sizes | owner | links | permissions | \
	cat ls.tbl.hdr - ls.tbl.trailer | tbl | nroff
I'm sure that I am still embedding some functionality here in the
wrong program, I leave it for others to correct me.

But, others might define the "one function" of a directory listing
program as producing all the information that you might want about
about the files in a directory, with options to control exactly
what information is presented, and in what form.

With such a definition, sorting (with a myriad of options
to define just what is the sort key) and columnising make
equal amounts of sense.  Even if you object to the "what form"
part of the definition, surely sorting & columnising stand or
fall together?

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".  (This is quite apart from the
problem of incompatible versions, which really is a problem).

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")

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?

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...