Let mandoc pipe to less?

Let mandoc pipe to less?

[Ingo Schwarze]

Hi,

espie@ just brought up the idea to automatically pipe mandoc
output to less(1) if output is a tty.

My first, instinctive reaction was "ugh, i don't want no magic".
But trying to find cases where this might get into the way,
i couldn't at first come up with any.  I'm not yet convinced
there are indeed none.

This could also solve naddy@'s old wish to get rid of the notorious
2>&1 | less dance after -Tlint.

Do we want this?

Maybe i'm even slightly in favour, but not yet really sure.

Yours,
  Ingo


Index: main.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/main.c,v
retrieving revision 1.78
diff -u -p -r1.78 main.c
--- main.c	17 Sep 2011 14:45:22 -0000	1.78
+++ main.c	25 Sep 2011 17:58:25 -0000
@@ -17,6 +17,7 @@
  */
 
 #include <assert.h>
+#include <err.h>
 #include <stdio.h>
 #include <stdint.h>
 #include <stdlib.h>
@@ -57,6 +58,7 @@ struct	curparse {
 	char		  outopts[BUFSIZ]; /* buf of output opts */
 };
 
+static	void		  fork_pager(int);
 static	int		  moptions(enum mparset *, char *);
 static	void		  mmsg(enum mandocerr, enum mandoclevel,
 				const char *, int, int, const char *);
@@ -72,7 +74,7 @@ static	const char	 *progname;
 int
 main(int argc, char *argv[])
 {
-	int		 c;
+	int		 c, fd;
 	struct curparse	 curp;
 	enum mparset	 type;
 	enum mandoclevel rc;
@@ -116,6 +118,10 @@ main(int argc, char *argv[])
 			/* NOTREACHED */
 		}
 
+	fd = OUTT_LINT == curp.outtype ? STDERR_FILENO : STDOUT_FILENO;
+	if (isatty(fd))
+		fork_pager(fd);
+
 	curp.mp = mparse_alloc(type, curp.wlevel, mmsg, &curp);
 
 	argc -= optind;
@@ -382,4 +388,54 @@ mmsg(enum mandocerr t, enum mandoclevel 
 		fprintf(stderr, ": %s", msg);
 
 	fputc('\n', stderr);
+}
+
+static void
+fork_pager(int std_fd)
+{
+	char	*pager;
+	int	 fildes[2];
+
+	if (-1 == pipe(fildes)) {
+		warn("pipe");
+		return;
+	}
+	switch (fork()) {
+	case (-1):
+		warn("fork");
+		return;
+	case (0):  /* The child process stays mandoc. */
+		close(fildes[0]);
+		if (-1 == dup2(fildes[1], std_fd))
+			err(1, "dup2 in the formatter");
+			/* No return here, or we might get double output. */
+		close(fildes[1]);
+		return;
+	default:
+		break;
+	}
+	/*
+	 * The parent process becomes the pager.
+	 * In case of communication problems,
+	 * it does the work itself, by simply returning.
+	 */
+	close(fildes[1]);
+	if (-1 == dup2(fildes[0], STDIN_FILENO)) {
+		warn("dup2 in the pager");
+		return;
+	}
+	close(fildes[0]);
+	do {
+		pager = getenv("MANPAGER");
+		if (NULL != pager && '\0' != *pager)
+			break;
+		pager = getenv("PAGER");
+		if (NULL != pager && '\0' != *pager)
+			break;
+		pager = "/usr/bin/less";
+	} while (0);
+	execl(pager, "mandoc [pager]", NULL);
+	warn("execl: %s", pager);
+	close(STDIN_FILENO);
+	return;
 }
Index: mandoc.1
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/mandoc.1,v
retrieving revision 1.47
diff -u -p -r1.47 mandoc.1
--- mandoc.1	18 Sep 2011 10:25:28 -0000	1.47
+++ mandoc.1	25 Sep 2011 17:58:25 -0000
@@ -108,6 +108,18 @@ text from stdin, implying
 and produces
 .Fl T Ns Cm ascii
 output.
+If the output is connected to a terminal, it is automatically piped to the
+pager selected by the
+.Ev MANPAGER
+environment variable, or by
+.Ev PAGER
+if the former is undefined or empty, or to
+.Pa /usr/bin/less
+by default.
+If the
+.Fl T Ns Cm lint
+output mode is selected, the standard error output is piped in place
+of the standard output.
 .Ss Input Formats
 The
 .Nm
@@ -363,6 +375,16 @@ See
 .Sx HTML Output
 for details; beyond generating XHTML tags instead of HTML tags, these
 output modes are identical.
+.Sh ENVIRONMENT
+.Bl -tag -width MANPAGER
+.It Ev MANPAGER
+The full path to the pager utility.
+.It Ev PAGER
+The same if
+.Ev MANPAGER
+is undefined or empty; defaults to
+.Pa /usr/bin/less .
+.El
 .Sh EXIT STATUS
 The
 .Nm
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: Let mandoc pipe to less?

[Joerg Sonnenberger]

On Sun, Sep 25, 2011 at 08:02:27PM +0200, Ingo Schwarze wrote:
> espie@ just brought up the idea to automatically pipe mandoc
> output to less(1) if output is a tty.

In general, I dislike programs doing that. *cough* git *cough*
I think this behavior belongs into man(1) or similar frontends.

> This could also solve naddy@'s old wish to get rid of the notorious
> 2>&1 | less dance after -Tlint.

The bigger question here is whether the output should actually go to
stderr in first place. It's the expected output for the tool after all.

Joerg
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: Let mandoc pipe to less?

[Kristaps Dzonsons]

>> espie@ just brought up the idea to automatically pipe mandoc
>> output to less(1) if output is a tty.
>
> In general, I dislike programs doing that. *cough* git *cough*
> I think this behavior belongs into man(1) or similar frontends.
>
>> This could also solve naddy@'s old wish to get rid of the notorious
>> 2>&1 | less dance after -Tlint.
>
> The bigger question here is whether the output should actually go to
> stderr in first place. It's the expected output for the tool after all.

Hi,

Bref, I don't like the pipe to less (or more or whatever).  Not only 
does it break expected behaviour, it also breaks portability (mandoc is 
portable to "others") and with nroff.  I also don't like magic: 
utilities doing Different Things depending on output confuse me.

The -Tlint thing is a different story.  At first I thought (Ingo will 
recognise this behaviour) No Way In Hell.  But (1) mdoclint in regress 
pushes to stdout; (2) lint itself pushes to stdout; and (3) there's no 
real notion of portability/compat so we can do what works best for us. 
So basically I'm fine with sticking a dup2 in there if people think it 
will save time and effort.

Thoughts?  Do-its?

Kristaps
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: Let mandoc pipe to less?

[Joerg Sonnenberger]

On Tue, Sep 27, 2011 at 01:06:32AM +0200, Kristaps Dzonsons wrote:
> The -Tlint thing is a different story.  At first I thought (Ingo
> will recognise this behaviour) No Way In Hell.  But (1) mdoclint in
> regress pushes to stdout; (2) lint itself pushes to stdout; and (3)
> there's no real notion of portability/compat so we can do what works
> best for us. So basically I'm fine with sticking a dup2 in there if
> people think it will save time and effort.

...or do some refactoring and replace stderr with errout and just
reassign the variable?

Joerg
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: Let mandoc pipe to less?

[Ingo Schwarze]

Hi,

Christian Weisgerber wrote on Tue, Sep 27, 2011 at 08:24:36PM +0200:
> Ingo Schwarze:

>> espie@ just brought up the idea to automatically pipe mandoc
>> output to less(1) if output is a tty.

> FWIW, I dislike this.  Unix commands don't behave like this.

That's true, yes.
So, nobody likes my patch, i guess i'm dopping it.

By the way, i did find a case where it causes serious screwup.
Apply the patch, build and install mandoc, and then do this:

  cd /usr/src/bin/
  make cleandir
  make obj
  make depend
  make

You get to press "q" multiple times to exit less.  Ooops.

So now you need to type

  make | cat

Useful useless use of cat, very ugly no doubt.

>> This could also solve naddy@'s old wish to get rid of the notorious
>> 2>&1 | less dance after -Tlint.

> That's a separate issue.  Although the thought of -Tlint output
> going to stderr and completely by-passing an automatically spawned
> $PAGER highlights how mistaken linting to stderr is in the first
> place.

Hmm, quite a few people seem to agree on that.

Probably we should make mandoc/main.c, mmsg() output - that is, parser
warnings and errors - go to stdout in case of -Tlint, but leave other
error output (like usage(), [mtw]options() "Bad argument", stat(2)
errors, open(2) errors, read(2) errors, malloc(3) errors) on stderr -
that's easy because all parser errors go through mmsg() but none
of the system errors do, but instead use fprintf(3) or perror(3)
directly.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv