Re: [dev] [ls] reform ls

From: Connor Lane Smith <cls_AT_lubutu.com>
Date: Sun, 19 Apr 2015 10:50:06 +0100

Hi,

On 19 April 2015 at 09:16, Quentin Rameau <quinq.ml_AT_gmail.com> wrote:
> I noticed that ls didn't really behaved as stated by POSIX so I worked
> a little on that. Here are four patches, the second one introduce big
> changes, so I'll be glad if you could review it.

1. Rather than turning off, and refusing to turn on again, flags -Srt
in presence of -f, we could just check for -f when about to sort and
avoid that whole code path.

To be honest, it's a bit weird how -St are separate booleans, given
the fact that you could really better define the behaviour of those
flags with an enum { AlphaSort, SizeSort = 'S', TimeSort = 't' },
rather than having to always ensure that Sflag and tflag are not both
true at once. That's a general complaint, though, rather than directed
at your patches.

3. Flags -go are part of XSI, and are unnecessary in POSIX proper. In
my mind sbase shouldn't bother with XSI compatibility. But the
position of the current sbase devs on POSIX compatibility isn't
entirely clear.

On 19 April 2015 at 09:33, Lee Fallat <ircsurfer33_AT_gmail.com> wrote:
> Just a question - have we (or you) considered creating programs that
> add POSIX support to other programs, rather than implementing it right
> into the program? For example, to support cat -v, instead of adding
> code for the flag, we create another program to pipe through. Then you
> create a tiny shell script to create a POSIX-compliant program.

Well, cat -v isn't POSIX. POSIX cat has just one flag, -u, which can
actually be totally ignored if your implementation doesn't buffer.
Still, I don't think that's as easy as you might think.

For example, we might want to implement ls flags -Cmx as a separate
shell script, seeing as they only really modify the output format.
(Plan 9 did exactly this with lc and mc.) However, those flags cause
flags -ln to be ignored (since they are mutually exclusive with each
other and with flag -1), which means you do actually have to
communicate to the C program that it is not in fact in -1 mode but in
some other output mode. And once you're doing that I think you might
as well just go ahead and support the flag, to be honest.

Perhaps for *some* utilities it could work, but I don't think it's a
very general solution.

cls
Received on Sun Apr 19 2015 - 11:50:06 CEST

This archive was generated by hypermail 2.3.0 : Sun Apr 19 2015 - 12:00:10 CEST