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 _______________________________________________ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
