Hello Oleg,
On Mon, 2005-07-04 at 15:49, Oleg Tarasov wrote:
There are 2 ways to implement this situation:
1) if [file] in [manpath-dirs] use groff
else use normal viewing
2) if [file] in [logfile-dirs] use normal viewing
else use groff
Let's see. Most manpages are most commonly
Hello Leonard,
Leonard den Ottolander [EMAIL PROTECTED] wrote:
Viewing most .[1-9] files with groff and putting the exception on the
specific log file paths really seems the most sensible thing to do.
I agree. Anyway most of lof files are placed in */log/* and */logs/*
despite of their
Hello Oleg,
On Mon, 2005-07-04 at 15:49, Oleg Tarasov wrote:
There are 2 ways to implement this situation:
1) if [file] in [manpath-dirs] use groff
else use normal viewing
2) if [file] in [logfile-dirs] use normal viewing
else use groff
Let's see. Most manpages are most commonly
Hello,
On Sun, 3 Jul 2005, Roland Illig wrote:
Pavel Tsekov wrote:
I can assume that on a decent distro the manpages go in the same location
more or less. I.e. the package maintainers build the packages with common
set of directories. So this idea is not as bad as you seem to imply. And
Hello,
It is not possible to implement anything that suites ALL systems.
There must be a solution that suites MOST systems.
There are 2 ways to implement this situation:
1) if [file] in [manpath-dirs] use groff
else use normal viewing
2) if [file] in [logfile-dirs] use normal viewing
else
Pavel Tsekov wrote:
I can assume that on a decent distro the manpages go in the same location
more or less. I.e. the package maintainers build the packages with common
set of directories. So this idea is not as bad as you seem to imply. And
it was merely a suggestion after all.
If you only
Hello Jindrich,
On Sun, 2005-07-03 at 14:18, Jindrich Makovicka wrote:
Leonard den Ottolander wrote:
Some improvements:
- Don't match capital letters in the man regexs. There are no such man
pages on my system (Linux). Please correct me if they are on other
systems.
XFree, Perl, SDL,
Hi,
Roland Illig pointed out to me that @localstatedir@ gets expanded to
${prefix}/var/log. He proposed a match for */log/* instead which I think
is a good idea as it will also match .[1-9] files in other /log/
directories. All other .[1-9] files will be interpreted as man pages.
Comments?
Hi,
On Sun, 2005-07-03 at 15:44, Roland Illig wrote:
What about this patch?
Spoke about this with Roland and added a match for */logs/* as well.
Also match %d/%f instead of just %d in case mcview is invoked from a
different directory (i.e. not via the panels).
Committed the final patch to HEAD
Hello,
On Fri, 1 Jul 2005, Roland Illig 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)?
Isn't it
Hi,
(Continuing this discussion on mc-devel.)
On Fri, 2005-06-24 at 12:52, Pavel Tsekov wrote:
files under that directory are manpages ? Or use `localstatedir' to
determine the location of the /var folder ?
How does that work? Using @localstatedir@ instead of /var in the .in
file?
Leonard.
Pavel Tsekov wrote:
Hello,
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
Hi,
On Fri, 2005-07-01 at 00:53, Leonard den Ottolander wrote:
How does that work? Using @localstatedir@ instead of /var in the .in
file?
Checking a Makefile.in this indeed seems to be the case :) .
More specific cases of course should come first.
Leonard.
--
mount -t life -o ro /dev/dna
Hi,
(Continuing this discussion on mc-devel.)
On Fri, 2005-06-24 at 12:52, Pavel Tsekov wrote:
files under that directory are manpages ? Or use `localstatedir' to
determine the location of the /var folder ?
How does that work? Using @localstatedir@ instead of /var in the .in
file?
Leonard.
From: Oleg Tarasov [EMAIL PROTECTED]
Another problem is in those errors coming up when exiting viewing
logrotated files (no matter in raw or processed form). Errors like
Cannot adjust line and cannot break line.
Something should be done.
Workaround: Press Shift-F3 to bypass all filtering.
Hello,
Another problem is in those errors coming up when exiting viewing
logrotated files (no matter in raw or processed form). Errors like
Cannot adjust line and cannot break line.
Something should be done.
--
Best regards,
Oleg Tarasov mailto:[EMAIL PROTECTED]
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
Hello,
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)?
Isn't it
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
Hello,
/dev/rob0 [EMAIL PROTECTED] wrote:
Press F8 to switch to raw mode. Note, that saves state, so if you try
viewing a groff source file later it will be raw. You'd have to press
F8 again to toggle it back.
Switching to raw mode when viewing COMPRESSED logrotated files comes
to a view of
On Thursday 23 June 2005 08:35, Oleg Tarasov wrote:
Usually if one wants to view rotated log file (eq maillog.5.bz2)
pressing F3 did the job - file is unpacked and viewed normally.
But now something changed and these files are viewed in a strange
Feature, not a bug. :) Try browsing your man
Hi rob0, Oleg,
On Thu, 2005-06-23 at 17:43, /dev/rob0 wrote:
The groff feature has been there for many years. I agree, it's an
annoyance when viewing logrotate files, but it's minor and the benefit
is worthwhile.
The problem with all this is that the file command does not reliably
test the
Hello,
I'm running FreeBSD 5.4-STABLE and I have everything configured for
using mc in russian koi8r codepage. Also my console is configured in
VESA_132x43.
I have the latest ported version of mc installed.
Usually if one wants to view rotated log file (eq maillog.5.bz2)
pressing F3 did the job
Hi!
The secret:
blahblah.#[.gz|bz2?] is interpreted as a manpage (in section #) and mc
try to show as a manpage :-), so do word wrapping at column xx.
Gergely
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
On Thursday 23 June 2005 08:35, Oleg Tarasov wrote:
Usually if one wants to view rotated log file (eq maillog.5.bz2)
pressing F3 did the job - file is unpacked and viewed normally.
But now something changed and these files are viewed in a strange
Feature, not a bug. :) Try browsing your man
25 matches
Mail list logo
