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
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
Mc mailing list