On Sun, 19 Apr 2015 10:50:06 +0100
Connor Lane Smith <cls_AT_lubutu.com> wrote:
> 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.
Rather use an "int sorttype = 'a';" and change it while parsing the flags.
> 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.
XSI only when it doesn't add too much cruft. In all other cases, these
are decision anybody with a sane mind would come up with, namely speaking
of a unified octal-escape-format, changes in wording (byte -> char in case
we are dealing with multibyte characters), being slacky with undefined
behaviour.
> 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.
Given this is an interactive matter, we are free to do it as pleased.
What makes sense for me is that output format and sorting types should
not fuck with each other.
Actually, piping ls output to cols(1) for example opens up the possibility
to columnize ls -l output.
I would do it, there's literally no reason not to allow columnizing ls -l,
and implementing output-format-stuff into ls just adds a lot to the cruft
for no practical reason.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Sun Apr 19 2015 - 13:41:42 CEST