> 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
> > /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. 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 compression)
$ 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
[email protected]:/var/log# file -z secure.1.gz
secure.1.gz: ASCII text (gzip compressed data, was "secure.1", from Unix)
[email protected]:/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:
[email protected]:/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
Mc mailing list