Re: Problem while viewing rotated log files

[Leonard den Ottolander <leonard den ottolander nl>]

Hi Rob,

Please compare
http://mail.gnome.org/archives/mc-devel/2005-January/msg00012.html .
Marcin Garski and I have been brainstorming ont his issue on IRC
(#mc-devel) in December.

On Fri, 2005-06-24 at 13:39, /dev/rob0 wrote:
> > On Thu, 23 Jun 2005, Leonard den Ottolander wrote:
> > > 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.

The test for /var/log could also be added to the "Manual page" section.

> 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/

As I have stated in my earlier mail, as long as "file" is buggy wrt
reporting the content type of compressed files there is nothing we can
do but use (ugly) hacks.

> > 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.

I agree. This is why Marcin Garski and I chose for the /var/log hack as
the best solution until file gets fixed. We can of course try to improve
on this method. Patches are welcome.

> > `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.

As said, file -z is buggy and hence unreliable, so we cannot (yet)
change FILE_CMD in ext.c to use -z. This is why we use path hacks in the
first place instead of doing "the right thing" and use type to test all
(or at least most) files.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research