Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Large programs
Message-ID: <6530@brl-smoke.ARPA>
Date: Wed, 7-Oct-87 22:09:58 EDT
Article-I.D.: brl-smok.6530
Posted: Wed Oct  7 22:09:58 1987
Date-Received: Sat, 10-Oct-87 12:49:38 EDT
References: <1046@ius1.cs.cmu.edu> <1130@gilsys.UUCP> <30035@sun.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 39

In article <30035@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>(I'm curious how
>general-purpose such a multi-column filter would be if it were to give you
>*all* the capabilities of the current multi-column "ls"; i.e., were something
>such as "ls * | <multi_column_filter>" in a directory with multiple
>subdirectories able to give a listing of the form
>	directory1:
>	file1.1		file3.1
>	file2.1		file4.1
>	directory2:
>	file1.2		file3.2
>	file2.2		file4.2

The standard DMD "mc" utility does just that, but I think it's a kludge
(not everyone agrees with me on this) because it "understands" the special
"ls" format (name1:\nentry1\n...entryN\nname2:\n...).  It might as well be
built into "ls", since almost no other utility produces this format.

The issue of "ls" columnation is not whether it is useful to have such an
option built into "ls"; given the special nature of multi-directory listing,
it obviously is.  The real issue is whether "ls" should decide on its own
whether or not to columnate, such as the Berkeley version does, or not do
so unless directed by a specific option, such as the System V version does.
From the toolkit viewpoint, I think it is obvious that the latter is correct
behavior, since no matter how much "smarts" is built into "ls", it cannot
possibly make the correct columnation decision under all circumstances.
(The Berkeley "ls" behavior is yet another example of assuming a too-
restrictive usage model, a point I keep harping on.  It works fine for
simple interactive usage, but gets out of control in a complex streams
environment where processes may be trying to get "ls" to behave sensibly
on what APPEARS to "ls" to be an "interactive device".)  By the way, I use
a non-columnating "ls", but usually I invoke it by the name "l" (which is
even LESS work than typing "ls"), where I've defined the shell function "l"
via my interactive-shell startup file:
	l(){ (set +u; exec ls -bCF $*); }
Thus I decide for myself whether I want columnation or not.

	"Symmetry -- it's the way things should be.."
		- Jane Siberry