Re: Problem while viewing rotated log files

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

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 
$ file /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
root sorry:/var/log# file -z secure.1.gz
secure.1.gz: ASCII text (gzip compressed data, was "secure.1", from Unix)
root sorry:/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:
root swmfs:/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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]