[clug] Going from 1 to 100 lines of ls wrapping script

[Hal Ashburner]

Cool links! I'll have to dig in deeper into those on the weekend.
Is it argument from authority? Nah maybe just argument by example. Well Rob
is a nice guy, I've met him and he signed a copy I had lying around of
Practise of Programming with the command "To the owner of this book: No
#ifdefs!"
Who better to counter Rob from '83 than Rob with a couple o decades more
experience, from '04!




* 8) One tool for one job? - by sczimme Given the nature of current
operating systems and applications, do you think the idea of "one tool
doing one job well" has been abandoned? If so, do you think a return to
this model would help bring some innovation back to software development?
(It's easier to toss a small, single-purpose app and start over than it is
to toss a large, feature-laden app and start over.)*

*Pike:*
Those days are dead and gone and the eulogy was delivered by Perl.

http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds


I'm not sure we can really argue /bin/ls as delivered by gnu coreutils has
minimalism as guiding factor in the presence of -D or --dired "generate
output designed for Emacs' dired mode."


/bin/ls does 4 things, it selects (give it a directory argument), it sorts,
it does some minimal filtering (eg -a)  and formats output (-l --color, -Q,
-F etc etc.). Mostly that is pretty convenient for anything ordinary I'd
want to do.


1) /bin/ls is broken for the case I've mentioned - nobody has yet disputed
that but I'm interested if people think its really fine. (I'd agree it's
good enough if ugly fwiw).
2) Assertion: can't fix it - compatibility with POSIX
3) Counter argument: an extra switch for ls can fix its filtering while
remaining compatible with everything, gnu does this kind of extension all
the time. -D
4) (3) is bad approach as we need a new ls that won't be compatible with
posix or any existant /bin/ls but is more small is beautiful. Taste?
 5) Assertion: /bin/ls is broken because nobody really cares. You may as
well learn the arcana and how to script what you need and once you do
you've no real need of proper /bin/ls filtering.
6) acknowledge, accept (5) and move on. I was testing the water to see if
it was worth getting off my backside to do something about it. No. That's
fine, it's a trivial issue after all. The patch can take an hour or two to
write and you can spend weeks messing around trying to get it accepted. We
all get patch sending fatigue. If you're in two minds asking some
experienced people is a good way to go, so that's what I did.

I'd like to examine your idea of breaking up ls so each part only does one
thing, briefly.

Breaking ls up into its constituent parts would yield a pipeline something
like (with some example switches):

select-dir-entries some_dir | direntsort --group-directories-first -c etc.
| filter-selection --a
--some_undetermined_ls_argument_to_filter_by_dirent_type |
format-dir-entries --color -l -F

Which is pretty well what the lsd script does, only the first and second
items are a single invocation of /bin/ls and last item in the pipe is also
/bin/ls because ls was like that when I got here.
 of the 100 lines, 99 of them are parsing arguments and handing them to the
correct ls invocation given the limitations of bash (pass to either first
item or third in pipeline) with test there in the middle such that the
whole thing works just like /bin/ls. And works with arguments you'd expect
to be able to give /bin/ls
 If you need to both filter what is returned and format it you need to
split ls into two processes with your filter in the middle. If we broke ls
up into smaller parts each doing the one thing you'd need a pipeline to do
simple convenient things that you can do with a simple switch now. You
could alias them, drop them in a script in your ~/bin or similar. I'm not
really convinced it's a step forward. The whole "small tools, one job only"
argument can be taken to an extreme where its no longer useful. Make
everything monolithic for convenience can yield similarly less than useful
results. What any of us does in our design decisions boils down to taste in
the circumstances we face.



On 27 November 2013 16:34, steve jenkin <sjenkin at canb.auug.org.au> wrote:

> 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
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>