Mailinglist Archive: opensuse (4053 mails)

< Previous Next >
[SuSE PEOPLE] Is 'less' broken in 7.2?
  • From: (Ted Harding) <Ted.Harding@xxxxxxxxxxxxxxxx>
  • Date: Wed, 01 Aug 2001 17:04:03 +0100 (BST)
  • Message-id: <XFMail.010801170403.Ted.Harding@xxxxxxxxxxxxxxxx>
[SuSE FOLK PLEASE READ, especially at the end]

... Well, actually, no, 'less' isn't broken; but I thought
it migfht be until I sussed it out. Having done that, I'm
just irritated.

On several text files, I have had the experience that

less filename

e.g.

less /usr/share/groff/tmac/tmac.s

just gives me a blank screen with, at the bottom,

/usr/share/groff/tmac/tmac.s lines ?-?/? (END)

as if it had read an empty file. On the other hand,
if you open that file in 'vim' (or any of the others
I've had this trouble with) you can see that it's
well populated and a totally normal text file.

(As one of the groff maintainers, I was about to give
you a blasting for sending out 'groff' with empty
'tmac' files; but I thought I'd better root around
before doing that).

Well, it turns out that there's a 'less' preprocessor,
/usr/bin/lessopen.sh, which examines the file and
possibly does things to it before handing it over to
'less', using 'file' to determine the type. Of course,
something like that has been the case for a long time,
and it's handy for zipped text files and like binary-
looking stuff.

But now, after testing for binary-type stuff such as
gzip, Zip, compress, bzip, etc., it then moves on to
- groff source
- tar archive
- RPM
- DVI, PS, PDF, HTML, Debian archive

and proceeds to run, respectively, 'groff' (in sundry variations),
'tar -tvvf', 'rpm -qip' then 'rpm -qlp', dvi2tty, 'ps2ascii',
'pdftotext', 'lynx', 'dpkg-deb' or 'nm'; then it send the output
to 'less.

Which is, of course, why nothing happened when I used less on
tmac.s -- 'file' recognises this as groff source and runs groff
on it. But, of course, it being a macro file, this will produce
no output from groff. Which is where this story started.

==================================

The point I want to make, SuSE, folks, is that this behaviour
of 'less' is overkill. Of course you can work round it by
'cat file | less' or 'less < file', which looks simple enough.

But there's s point of principle here. Historically, in the
GNU environment, 'less' has been the preferred tool of people
scanning text files, preferable to 'more' because you can go
back as well as forward. A classic example of "a tool which
does one job, and does it well".

But now, thanks to the admittedly valiant efforts of
Vladimir Linek (who seems to have prepared lessopen.sh specially
for SuSE), we now have something which is is trying to be a
"universal" file reader -- groff, DVI, PS, PDF, HTML, whatever,
'less' will mangle it with something that has some capability
for that file type.

Note that many of the preprocessing programs are not the most
suitable and will fail for a lot of files of the respecive type.
Even 'ps2ascii' will make an absolutely lousy job on many PS files
which, properly, would display as pure text. (I have a straight-
forward .ps file with 17 columns of plaintext data on 1151 lines,
44978 non-space ASCII characters, for which ps2ascii gives me 235
non-space ASCII characters on 84 lines).

So we now have 'new less' which tries to do many different
jobs and may well do any one of them very badly (such as displaying
/usr/share/groff/tmac/tmac.s ).

At least, in say KDE, if you click on a file in the file manager
it will normally open it with something that does a proper job
(though of course it can occasionally get that wrong too). But
even here I'm somewhat against the practice, because it associates
ONE particular application with any particular file type, and there
can be all sorts of reasons why you may want to process the file with
something else (if a groff source file, then not only 'groff', but
'vim' for editing it, or -- yes -- even 'less' for scanning it).
Nevertheless, so longas the filetype/application association does
not become too invasive, it has its uses; and the fact that it only
happens in KDE when you click in the file manager means that you can
rattle away on your command line as you please, and know what you're
going to be getting.

But what has happened with 'less' is, I think, indeed too invasive.
Unless you edit whatever it is (and hands up everyone who DOESN'T
know whatever it is) that sets your $LESSOPEN EnvVar whenever you
log in, or unset it yourself whenever you log in, or edit lessopen.sh
to cut out everything you don't want and keep what you will find useful
and not intrusive, then you will find that 'less' takes over and
does what_it_thinks_you_need without using any sort of "intelligence"
to determine what_you_want.

And if this reminds you of another operating system (whose behaviour
in this respect has at times literally had me breaking things) then
I'm in your company. I would not like to see what has been a very
sound Linux distribution, and reasonably flexible to handle and
control, go down the road of "knowing better than the user" (and,
by the way, doing a bad job of "knowing better").

Of course, as I say, having sussed it out I now know I can work
round it with 'less < file' or the like. But I shouldn't have to
because of the reasons given above, for in my mind these are bad
reasons.

If somebody wants to comsult an HTML document using lynx and view the
result with 'less' then let THEM do 'lynx -dump filename | less'
(or any other HTML interpreter if they so wish); If I need to scan the
HTML code, I want to be able to do 'less filename' and get what I expect,
not have to track down some file or other which happens to be
/usr/bin/lessopen.sh in order to find out why I didn't get it.

SO SuSE FOLKS, Please come back off this road you're going down.
==============

If you want an all-singing (even if out of tune) all dancing (even
if falling over too often) "less" with all that gizmo in lessopen.sh,
then give it a different name (even "LESS"), so that we can avoid it
unless we want it, and restore our friendly useful tool which may only
do one job but does it bloody well.

And the same for any other tools which may be going down the same road.

And, finally, if your response to the above is "Since you clearly know
how to deal with it, you can sort it out it yourself", my answer will be
"Yes, I do; and I intend to. But I damn well want you to know why
I'm doing that. If only for the sake of other people."


Thanks for getting this far.

And please take this seriously: I've been in this game too long for
the above to be an ill-considered rant. It is, rather, a protest
against indications of an imminent dumbing down [and why would anyone
want to do that ... ?] of an operating system that really only works
properly when it is understood (at any rate up to a certain level) but
then works spendidly. SuSE, with 7.2, seems to be getting to the point
where I can only use it properly if I start undoing stuff which SuSE have
done, in order to restore some of the native simplicity and transparancy
of Unix. I do not want, and indeed resent, anything which excessively
intrudes on using the system as I want. It's like driving a car which
suddenly says "I'm going to turn left here" or "here we stop for a
picnic", and it then takes me all afternoon fiddling with its settings to
get it to change its mind since I have a journey to finish.

If (as of course there isn't) there was any "intelligent intent" behind
the behaviour of 'less' with the above tmac.s file, it could only be
interpreted as "This user is trying to read a groff macro file. He doesn't
need to do that, nor know what's inside it, and probably he'd better
not in case he does something he shouldn't." Well, there _are_ systems
that behave like that; and I avoid them as far as possible.

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding@xxxxxxxxxxxxxxxx>
Fax-to-email: +44 (0)870 167 1972
Date: 01-Aug-01 Time: 17:04:03
------------------------------ XFMail ------------------------------

< Previous Next >
This Thread
  • No further messages