[clug] Going from 1 to 100 lines of ls wrapping script
steve jenkin
sjenkin at canb.auug.org.au
Tue Nov 26 22:34:39 MST 2013
Hal Ashburner wrote on 27/11/13 3:36 PM:
> Nope, you lost me here.
> Gnu does nothing if not extend POSIX. If you put #!/bin/bash at the top
> of your script you absolutely cannot expect to use every bash feature
> and be compatible with any compliant /bin/sh
> Eg busybox /bin/sh - I'd be amazed (but delighted) if the lsd script
> would run on busybox.
>
> I spoke not of "replacing ls" but merely adding yet another (IMHO useful
> - but maybe not very given the lack of interest in the fix compared to
> the original query about the problem) switch to ls.
> ls --filter-test=d
> would filter ls output and only show what passes "/usr/bin/test -d
> $dirent", this obviously trivially extends to all the arguments to
> /usr/bin/test. So I did that for me in a shell script in a way that is
> marginally better than the 1 liner i was using before.
>
> Now that looks exactly like the gnu philosphy to me, yeah it's useful,
> no it won't break existing code, yeah the approach is unsurprising, hack
> it in go!
Hal,
Thanks for the discussion.
Read what the guys who wrote Unix said of the "Unix Philosophy", Doug
McIlory quoted below.
I don't believe ESR and his "17 rules" don't represent well the Bell
Labs "Unix Philosophy", it's too big & complex.
Briefly: "Less is More".
This led Rob Pike in 1983, from Bell Labs Dept 1127, to write "cat -v
considered harmful".
He contended the flag wasn't need because "od" existed and USB/BSD
_broke_ the Unix Philosophy.
Copies of the "cat -v" paper:
<http://gaul.org/files/cat_-v_considered_harmful.html>
<http://harmful.cat-v.org/cat-v/> [dead link?]
<https://web.archive.org/web/20130824153727/http://harmful.cat-v.org/cat-v/>
[wayback copy]
"Unfortunately their advice has been completely ignored, and today Unix
has become overcome by exactly the kind of mistakes they warned against."
So, I'm not a fan of yet another flag for 'ls' as it ignores the Unix
"less is more" stance.
What's needed, IMO, is a better 'ls' whose output can be trivially
filtered by other items in the toolkit...
I enjoy having 'cat -v' available, but I use 'od' as well.
I can appreciate the "Unix Philosophy" has evolved since 1974, but can't
see that breaking some of the fundamentals doesn't constitute a radical
fork.
[The sort of 'fork' that was Windows NT being sold as a "POSIX
compatible environment". It _did_ provide an isolated execution
environment, without networking, that _was_ POSIX. I've never heard of
anyone using it.]
cheers
steve
==============================================
LINKS:
Definitive historical works from CACM, 1974 & 1978.
Short, everyone needs to read...
"The UNIX Time-sharing System--A Retrospective"
<http://cm.bell-labs.com/cm/cs/who/dmr/retro.html>
"The UNIX Time-Sharing System"
<http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html>
----------------------
Rob Pike:
<http://herpolhode.com/rob/>
Pike and Kernighan on "Program Design"
<https://web.archive.org/web/20130809061345/http://doc.cat-v.org/unix/>
LONG oral history @ Princeton:
<http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm>
----------------------
I couldn't find a copy of the Foreword from August 1978 "The Bell System
Technical Journal", so there's this, a copy of an ESR page.
<http://www.faqs.org/docs/artu/ch01s06.html>
Doug McIlroy, the inventor of Unix pipes and one of the founders of the
Unix tradition, had this to say at the time [McIlroy78]:
(i) Make each program do one thing well.
To do a new job, build afresh rather than complicate old programs by
adding new features.
(ii) Expect the output of every program to become the input to another,
as yet unknown, program.
Don't clutter output with extraneous information. Avoid stringently
columnar or binary input formats. Don't insist on interactive input.
(iii) Design and build software, even operating systems, to be tried
early, ideally within weeks.
Don't hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming
task, even if you have to detour to build the tools and expect to throw
some of them out after you've finished using them.
He later summarized it this way (quoted in A Quarter Century of Unix
[Salus]):
This is the Unix philosophy:
Write programs that do one thing and do it well. Write programs to
work together. Write programs to handle text streams, because that is a
universal interface.
--
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA
sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
More information about the linux
mailing list