> On Thu, 23 Jun 2005, Leonard den Ottolander wrote: > > The problem with all this is that the file command does not > > reliably test the file type inside b/gzipped files so we have to do > > some trickery. > > > > Does the attached patch fix the issue (adds a test for the location > > /var/log)?
The patch didn't work for me, but I see what it's trying to do. It wouldn't work for me anyway because my logrotate doesn't bzip2 its victims. If I have time later I will mess around with it myself and see what I can do. On Friday 24 June 2005 05:52, Pavel Tsekov wrote: > Isn't it better to use the `mandir' variable to determine the > possible location of manpages instead of hardcoding `/var/log' ? I do agree that hardcoding /var/log is not ideal. Some systems might not use that path, and in fact on my own (Slackware, various versions up to and including -current as of last week) I can get there through at least two other paths: $ v /usr/adm lrwxrwxrwx 1 root root 8 2005-06-18 15:09 /usr/adm -> /var/adm/ $ v /var/adm lrwxrwxrwx 1 root root 3 2005-06-18 19:38 /var/adm -> log/ > configure would then replace `mandir' with the correct value and MC > will assume that files under that directory are manpages ? Or use I *really* do not like this idea. One of the best things about nroff viewing is to be able to read man pages of uninstalled software, even using tarfs. I do this quite a lot. > `localstatedir' to determine the location of the /var folder ? Perhaps, but there too, what if the OS has done something unusual with their syslog? You could try to read syslog.conf perhaps (bad idea, privileged file here, and what if it's a different syslogd?) Probably file(1) is the cleanest idea overall. $ file -z /usr/man/man1/ls.1.gz /usr/man/man1/ls.1.gz: troff or preprocessor input text (gzip compressed data, was "ls.1", from Unix, max compression) $ file /var/log/messages /var/log/messages: $ v $_ -rw-r----- 1 root root 165552 2005-06-24 05:54 /var/log/messages $ sudo file /var/log/messages /var/log/messages: ASCII text [EMAIL PROTECTED]:/var/log# file -z secure.1.gz secure.1.gz: ASCII text (gzip compressed data, was "secure.1", from Unix) [EMAIL PROTECTED]:/var/log# file -z wtmp.1.gz wtmp.1.gz: data (gzip compressed data, was "wtmp.1", from Unix) Here's at one which does no compression at all: [EMAIL PROTECTED]:/var/log# file debug.1 debug.1: ASCII text Indeed, I'm not convinced that this "bug" should be fixed. The fix should take into account what logrotate(8) is doing, and where. I for one am satisfied with the nroff parsing default, and pressing F8 for raw output. Or Shift-F3 (depending on termcap, doesn't work under GNU screen(1)), which is even better. As long as you are aware of the situation, that's not a problem. Oh, there is one question I have. Generally I have larger than standard $COLUMNS. Yet it appears that mc viewer's nroff formatting is hard- coded for COLUMNS=80. man(1) uses the $COLUMNS width. Would it be possible to do this in mc? Thanks, Leonard and Pavel, and also to Oleg, for bringing it up. mc is excellent, my number-one most-used tool. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header _______________________________________________ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc