[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@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 167 1972 Date: 01-Aug-01 Time: 17:04:03 ------------------------------ XFMail ------------------------------