Re: Problem while viewing rotated log files

Hi Rob,

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

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

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.


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

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