Please consider shipping a more powerfull version of lesspipe (maybe in a separate package). The version from http://sf.net/projects/lesspipe can deal with much more filetypes. It would also be nice if less would use the lesspipe script by default.
Hi, one of the reasons the Debian less' lesspipe does not handle some filetypes is that they are already text by itself (e.g. manpages, html files). As less is a viewer for text files I will never include a filter for such files. I'll look over which binary files can be handled by that other lesspipe and include them. Thomas Nikolaus Rath wrote:
Nikolaus Rath wrote: Last time I checked, there was no good way for a package to add such environment variables to the shell rc files. The file /etc/profile e.g. belongs to the package base-files. So this is probably more of a general system configuration/installation issue... Thomas
it would be nice if you could provide the text preprocessors, such as for man pages, as an option, perhaps as a separate script. it is not trivial for users to figure out how to process man pages to work with less. recently, my setup which worked fine on man zshall stopped including the other pages, and the zsoelim error messages disappeared because less took over the screen and they did not appear after less quit. i don't have the time now to try to fix it, so i am stuck with running less without good man page support or running man without good paging support (i like to go to the next file inside less rather than one at a time). we get it that you don't want to have less preprocess text :-). but doing so as an option should be beneficial, without affecting default behavior. thanks.
Hi, well, that's right, I don't want text(file) processors for less :-) Frankly spoken, including optional text(file) processors would very likely raise questions and requests to make (at least some of) them standard... What I have done a few years ago was to offer users a standard interface to integrate their own custom file processors. I still believe that's the right way to go to process text files. As far as manpages are concerned: man itself can use less as a pager program. But maybe this does not offer all the features that you'd like to have? Thomas-------- Original-Nachricht -------- Datum: Thu, 22 Jun 2006 21:27:19 -0700 Von: gambarimasu+reportbug@gmail.com An: Debian Bug Tracking System <205702@bugs.debian.org> Betreff: Bug#205702: less: provide text preprocessors as an option for users
Hi, well, that's right, I don't want text(file) processors for less :-) Frankly spoken, including optional text(file) processors would very likely raise questions and requests to make (at least some of) them standard... What I have done a few years ago was to offer users a standard interface to integrate their own custom file processors. I still believe that's the right way to go to process text files. As far as manpages are concerned: man itself can use less as a pager program. But maybe this does not offer all the features that you'd like to have? Thomas-------- Original-Nachricht -------- Datum: Thu, 22 Jun 2006 21:27:19 -0700 Von: gambarimasu+reportbug@gmail.com An: Debian Bug Tracking System <205702@bugs.debian.org> Betreff: Bug#205702: less: provide text preprocessors as an option for users
thanks for your reply. clearly you don't want text preprocessors for yourself. but why not provide the most common ones for those who want it? i don't think they will ask you to make it default. instead they will be grateful for saving them the debugging. man using less does not work because i want all of the man pages in less so that i can go back and forth among the man pages. instead it only lets you go to the next file and you have to press return.
Sorry guys, but it's just too strange that less understands Office doc files with catdoc and does not understand OpenOffice sxw/ods. Why not use full featured lesspipe or at least leave it as an option to the user? What about a second package? About updating profile, don't kill me, but env-update is one thing I like about Gentoo that I'd like to see in Debian.
So, you know of a tool like catdoc for OpenOffice files? Please define "full featured". There already is. It's up to the user to use it. Thomas
Dear Anìbal, the current lesspipe file is used in Debian only; other distributions seem to use alternatives such as the one suggested at the beginning of this bug report, or the following one (for Fink): http://www-zeuthen.desy.de/~friebel/unix/lesspipe.html I think that the major flaw of the current lesspipe script in Debian is that it supposes that to each suffix corresponds one and only file type. This causes the bugs 432623 and 397191 for instance. Migrating to or providing an alternative that can use the output of the `file' command could solve these problems. Have a nice day,
I'm not the OP, but... There's my script sxw2txt (based on Liam Morland's), included in Wolfgang Friebel's lesspipe. Charset conversion, archive support (I mean being able to read files in an archive, such files being processed themselves by lesspipe, recursively).
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/, ...) and, most of all, filetype detection through `file` in case no extension is detected. This allows supporting common cases like: * ~/.bin/myscript is a shell-script (use color) * /bin/ls is an ELF (use readelf -a) * ~/bin/data is data (use hexdump -C) Moreover, Gentoo's version of lesspipe: - has better code: use of functions which open way to go back and forth between file detection and various fallback methods - use a more granular way to define its behavior (according to arguments values and not only arguments count) which makes it vastly superior. (eg: a ~/.lessfilter file could makes some custom things in order to detect a filetype and just then rerun lesspipe while specifying the extension) Please note that Gentoo's lesspipe use /bin/bash (would be interesting to know which Debian setup(s) make lesspipe /bin/sh dependant) ¹ http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/less/files/lesspipe.sh
Friebel's version can do that too, and recursively (the recursion depth is limited, but sufficient in practice). 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 ?
I agree that it isn't much readable. Well, not that exactly. The
main problem is that it lacks comments / internal documentation.
This didn't prevented me from doing some local changes.
been installed (the "&& return 0 || return 1" is probably useless,
though, except if the goal was to make it work with "set -e").
I wonder why filecmd() isn't merged with filetype(). Otherwise it
is useful.
msg() seems to be new (I still use an old version, where it isn't
present).
I don't think that show() is useless: it has recursive calls.
I completely disagree. This is standard POSIX shell syntax, which
can be found in many shell scripts, and I had never heard of any
complaint. It's faster than invoking sed.
As a comparison, zsh internal scripts are really unreadable, because
this kind of transform is often done in a nested way, with various
flags that change the behavior.[*] But here, this is simple enough.
[*] As examples:
lopts+=("${^tmp[@]}":${${${opt//:/-}//\[/(}//\]/)})
"$tmpargv[(I)(|\([^\)]#\))(|\*)${opt}(|[-+]|=(|-))(|\[*\])(|:*)]"
\${tmp#\${(j(${sep}))~\${(@)\${(@)keys[2,(rn:num:)\$key]}/*/*}}${~sep}}
Yes, a "case" construct may be better.
Hey. Just for the records: I've filed an RFP[0] for the lesspipe alternative from: https://github.com/wofr06/lesspipe respectively https://www-zeuthen.desy.de/~friebel/unix/lesspipe.html which, AFAICS, is also the one used in gentoo. Should it get packaged, than maybe both could simply happily coexist (and this bug would still become obsolete). :D Cheers, Chris. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043249