On Thu, Sep 25, 2014 at 01:02:27AM +0200, Vincent Lefevre wrote:
> On 2014-09-24 18:01:04 -0300, Raphaël Droz wrote:
> > The Gentoo version of lesspipe¹ is vastly superior:
> >
> > It supports files inside archive, archive compression detection
> > (all these .(sh|txt|log|...).gz + compressed manpages and other
> > files commonly compressed in /usr/share/, ...)
>
> Friebel's version can do that too, and recursively (the recursion
> depth is limited, but sufficient in practice).
>
> > and, most of all, filetype detection through `file` in case no
> > extension is detected.
>
> Friebel's version uses "file" too.
>
> It can also do charset conversion, e.g. to be able to read an
> ISO-8859-1 file under UTF-8 locales.
I had a quick look at Friebel's version. Indeed it implements the
above requested features. Anyway, I found it much less readable that
Gentoo's version. It actually used functions, but too many of them
(although simple wrappers). I couldn't tell if its "overkill" or
"flexible" enough, but from a code readability POV it's seems more
difficult.
- Things like cmd_exist(), filecmd(), msg() or show() seems more annoying
than really useful.
- All the things like: ${rest1#$sep}, ${rest11%%$sep*}, or
${rest11#$file2} in show(), while valid bash-expression makes the code
less readable.
- All the istar(), isdvi(), ... 1 to 5 lines wrappers does not make
lesspipe more friendly as are the if/elif constructs. In this regard
the clear and simple "case" construct of the Gentoo version is more
readable and maintainable for features equality.
The only drawback I can see for the Gentoo's version is that the (GPLv2)
licence is not specified in the file's header.
To reply to the main/only opposition of the maintainer (Thomas ? or
Anibal ?) which is about adding text processor for text files.
text-processor is about converting from a meaningful text a non-text
file but is *also* about decoding a text encoded (compressed) to a text
decoded. It's about non-human-readable content to human-readable content
and a bzip'ed man-page isn't readable by most humans.
lesspipe is useful in the first place. And the most preprocessor
are added the best it is. But it does not means that the preprocessor
should be neither be hard or soft dependencies of less/lesspipe.
Neither is means that it's adequate to bundle them with less or with a
"lesspipe" package. IMHO I think their are too much way for
cluttering. Text-processors should find their own way in others
packages.
$ tar xf archive.tar.gz
$ less archive/*
# here getting automatic objdump for binaries, color for scripts, ... is
handy since we use :n to switch from file to file without having to
care about their filetype since we use less for a "quick preview of
files contents".
I should add that one of the main characteristic of the lesspipe
implementation to choose should be to be extendable through
~/.lessfilter to give most freedom for custom implementation, additional
filetypes, without be an hassle for the maintainer of less.
A lesspipe implementation lacking:
- compressed files
- iso to utf conversion
- files without extensions
- ...
would *not* be a problem if it would gives room for ~/.lessfilter
to implement it easily. But that's not the case ATM.
Other than the choice between patching Debian's version or the choice among
alternative implementations, could the maintainer give
hint/suggestion/reaction about the future of this feature request ?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
