Adding streams for standard out and standard err

Adding streams for standard out and standard err

[Phillip Lord]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]


For a while I've wanted Emacs to have the ability to write to standard
out, and/or standard err, when not running in batch. Mostly, I've wanted
for debugging, as it involves touching no buffers at all.

Comments welcome...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-streams-for-stdout-stderr.patch --]
[-- Type: text/x-diff, Size: 2643 bytes --]

From eac3394997a122d57f90bea2ca850ac609104840 Mon Sep 17 00:00:00 2001
From: Phillip Lord <phillip.lord@russet.org.uk>
Date: Mon, 18 Jul 2016 23:28:05 +0100
Subject: [PATCH] Add streams for stdout, stderr

* src/print.c (Fstdout,Fstderr): New function
---
 doc/lispref/streams.texi | 21 +++++++++++++++++++++
 src/print.c              | 20 ++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/doc/lispref/streams.texi b/doc/lispref/streams.texi
index 41bc71e..7d26c9f 100644
--- a/doc/lispref/streams.texi
+++ b/doc/lispref/streams.texi
@@ -530,6 +530,27 @@ Output Streams
 Calling @code{concat} converts the list to a string so you can see its
 contents more clearly.
 
+Two functions which are specifically designed for use as output
+streams:
+
+@table @asis
+@cindex @code{stdout} output stream
+@item @var{stdout}
+Prints to the system standard output (as opposed to the
+@var{standard-output}), regardless of whether Emacs is running
+interactively or not.
+
+@item @var{stderr} output stream
+Prints to the system standard error, regardless of whether Emacs is
+running interactively or not.
+@end table
+
+These functions are predominately useful for debugging, as they are a
+mechanism for producing output that does not change any buffer. Note
+that these functions do not flush their output; in general, no output
+will be produced until a newline.
+
+
 @node Output Functions
 @section Output Functions
 
diff --git a/src/print.c b/src/print.c
index 5531210..f5a38c3 100644
--- a/src/print.c
+++ b/src/print.c
@@ -264,6 +264,24 @@ printchar_to_stream (unsigned int ch, FILE *stream)
     }
 }
 
+DEFUN ("stdout", Fstdout, Sstdout, 1, 1, 0,
+       doc: /* Output character CHARACTER to system standard output. */)
+     (Lisp_Object character)
+{
+  CHECK_NUMBER (character);
+  printchar_to_stream (XINT(character), stdout);
+  return character;
+}
+
+DEFUN ("stderr", Fstderr, Sstderr, 1, 1, 0,
+       doc: /* Output character CHARACTER to system standard error. */)
+     (Lisp_Object character)
+{
+  CHECK_NUMBER (character);
+  printchar_to_stream (XINT(character), stderr);
+  return character;
+}
+
 /* Print character CH using method FUN.  FUN nil means print to
    print_buffer.  FUN t means print to echo area or stdout if
    non-interactive.  If FUN is neither nil nor t, call FUN with CH as
@@ -2301,6 +2319,8 @@ priorities.  */);
   /* prin1_to_string_buffer initialized in init_buffer_once in buffer.c */
   staticpro (&Vprin1_to_string_buffer);
 
+  defsubr (&Sstdout);
+  defsubr (&Sstderr);
   defsubr (&Sprin1);
   defsubr (&Sprin1_to_string);
   defsubr (&Serror_message_string);
-- 
2.9.2

Re: Adding streams for standard out and standard err

[Andreas Schwab]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> +Two functions which are specifically designed for use as output
> +streams:
> +
> +@table @asis
> +@cindex @code{stdout} output stream
> +@item @var{stdout}
> +Prints to the system standard output (as opposed to the
> +@var{standard-output}), regardless of whether Emacs is running
> +interactively or not.
> +
> +@item @var{stderr} output stream
> +Prints to the system standard error, regardless of whether Emacs is
> +running interactively or not.
> +@end table

That's not a good name for these functions.  Since they do the printing
their name should include `print'.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Adding streams for standard out and standard err

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Wed, 20 Jul 2016 23:48:43 +0100
> 
> For a while I've wanted Emacs to have the ability to write to standard
> out, and/or standard err, when not running in batch. Mostly, I've wanted
> for debugging, as it involves touching no buffers at all.

Can we take a step back and talk about the need and the use cases?

Here're some thoughts related to this:

 . We already have (append-to-file START END FILENAME), which can be
   used to write a buffer or a string to a file.  FILENAME can be
   "/dev/stderr" on Posix platforms, for example, or it can be a real
   file name.

 . On TTY frames, writing to standard streams can end up on the
   screen, in which case it will mess up the display.

 . On GUI frames, writing to standard streams can end up in some
   unpredictable place on the system, or even in the bitbucket,
   depending on what window system, desktop, and window manager are
   installed.  On some systems, standard streams have invalid file
   descriptors in GUI sessions.

So this proposed functionality sounds (a) not really necessary, and
(b) somewhat unreliable/dangerous.  If you have specific use cases
where the existing functionality doesn't fit the bill, and the issues
mentioned above are non-issues, please describe those use cases.

Thanks.

Re: Adding streams for standard out and standard err

[Paul Eggert]

On 07/21/2016 04:21 PM, Eli Zaretskii wrote:
>   . We already have (append-to-file START END FILENAME), which can be
>     used to write a buffer or a string to a file.  FILENAME can be
>     "/dev/stderr" on Posix platforms, for example, or it can be a real
>     file name.

Wouldn't the proposed primitives often be more efficient than 
append-to-file, since they would use stdio buffering?

Presumably people using the new primitives would know about their 
problems with tty and/or GUI frames, just as they know about the similar 
problems that append-to-file has with /dev/stderr.

Re: Adding streams for standard out and standard err

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 21 Jul 2016 16:40:10 +0200
> 
> On 07/21/2016 04:21 PM, Eli Zaretskii wrote:
> >   . We already have (append-to-file START END FILENAME), which can be
> >     used to write a buffer or a string to a file.  FILENAME can be
> >     "/dev/stderr" on Posix platforms, for example, or it can be a real
> >     file name.
> 
> Wouldn't the proposed primitives often be more efficient than 
> append-to-file, since they would use stdio buffering?

Probably.  But is performance relevant to the use cases we intend them
to be used?  I'm not sure; I've got the impression that the use cases
Phillip had in mind are all in the context of debugging.  After all,
why else would you want to write something to a standard stream in an
_interactive_ session?  And how is performance relevant to debugging
printfs?

> Presumably people using the new primitives would know about their 
> problems with tty and/or GUI frames, just as they know about the similar 
> problems that append-to-file has with /dev/stderr.

I'm not so sure.  But that's not the important part of my reasoning.

Re: Adding streams for standard out and standard err

[Phillip Lord]

Andreas Schwab <schwab@suse.de> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> +Two functions which are specifically designed for use as output
>> +streams:
>> +
>> +@table @asis
>> +@cindex @code{stdout} output stream
>> +@item @var{stdout}
>> +Prints to the system standard output (as opposed to the
>> +@var{standard-output}), regardless of whether Emacs is running
>> +interactively or not.
>> +
>> +@item @var{stderr} output stream
>> +Prints to the system standard error, regardless of whether Emacs is
>> +running interactively or not.
>> +@end table
>
> That's not a good name for these functions.  Since they do the printing
> their name should include `print'.


Yes, this is true, although they only print single characters, which is
pretty useless for most people. In actual use, they look like this:

(print "hello" 'stdout)


Extending the name to reflect the full function:

(print "hello" 'printchar-to-stdout)

Seemed a bit duplicative to me.

Phil

Re: Adding streams for standard out and standard err

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Wed, 20 Jul 2016 23:48:43 +0100
>> 
>> For a while I've wanted Emacs to have the ability to write to standard
>> out, and/or standard err, when not running in batch. Mostly, I've wanted
>> for debugging, as it involves touching no buffers at all.
>
> Can we take a step back and talk about the need and the use cases?

Mostly debugging, I think. For example, I find debugging the undo code
very taxing. Using GDB is hard because the debug code gets called so
often (I admit to being barely competent at using GDB). Logging to a
buffer touches other buffers. Logging to a variable works, but you can
only see the value of the variable when all is done.

Dumping to stdout, while interacting with a live emacs would give me an
independent channel to getting output, as well as post-hoc debugging.


> Here're some thoughts related to this:
>
>  . We already have (append-to-file START END FILENAME), which can be
>    used to write a buffer or a string to a file.  FILENAME can be
>    "/dev/stderr" on Posix platforms, for example, or it can be a real
>    file name.

We do, and I am grateful that you pointed this out to me. But
append-to-file also writes to the mini-buffer. This makes interactive
use difficult, or painful. Of course, this could be fixed.

Still,

(append-to-file (print buffer-undo-list) nil "/dev/stderr")

seems clunky compared to:

(print buffer-undo-list 'stdout)


>  . On TTY frames, writing to standard streams can end up on the
>    screen, in which case it will mess up the display.

Yep. I would imagine that debugging to standard out will not become
popular as a tool for debugging TTY display.

>  . On GUI frames, writing to standard streams can end up in some
>    unpredictable place on the system, or even in the bitbucket,
>    depending on what window system, desktop, and window manager are
>    installed.  On some systems, standard streams have invalid file
>    descriptors in GUI sessions.

It can also end up in some entirely predictable place, which is enough.


> So this proposed functionality sounds (a) not really necessary, and
> (b) somewhat unreliable/dangerous.  If you have specific use cases
> where the existing functionality doesn't fit the bill, and the issues
> mentioned above are non-issues, please describe those use cases.


I think it has no problems that append-to-file does not not have, and is
neater, more concise and it's use is clearer.

Probably adding a stdin stream would be good also; still, that's a
separate issue.

Phil

Re: Adding streams for standard out and standard err

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Thu, 21 Jul 2016 16:40:10 +0200
>> 
>> On 07/21/2016 04:21 PM, Eli Zaretskii wrote:
>> >   . We already have (append-to-file START END FILENAME), which can be
>> >     used to write a buffer or a string to a file.  FILENAME can be
>> >     "/dev/stderr" on Posix platforms, for example, or it can be a real
>> >     file name.
>> 
>> Wouldn't the proposed primitives often be more efficient than 
>> append-to-file, since they would use stdio buffering?
>
> Probably.  But is performance relevant to the use cases we intend them
> to be used?

You are correct in this case, performance is irrelevant. In fact,
buffering is a bit of a pain. It took me a few minutes to work out why

(print "hello" 'stdout)

worked but

(princ "hello" 'stdout)

didn't -- the latter gets buffered.


>> Presumably people using the new primitives would know about their 
>> problems with tty and/or GUI frames, just as they know about the similar 
>> problems that append-to-file has with /dev/stderr.
>
> I'm not so sure.  But that's not the important part of my reasoning.

It's important to the "unreliable/dangerous" part of your argument.

I will add further documentation to the patch, pointing out this
potential problem.

Phil

Re: Adding streams for standard out and standard err

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2016 19:52:58 +0100
> 
> (append-to-file (print buffer-undo-list) nil "/dev/stderr")
> 
> seems clunky compared to:
> 
> (print buffer-undo-list 'stdout)

Nothing a simple function won't heal, right?

Maybe that's all we need: a small wrapper around append-to-file.

Re: Adding streams for standard out and standard err

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 21 Jul 2016 19:52:58 +0100
>> 
>> (append-to-file (print buffer-undo-list) nil "/dev/stderr")
>> 
>> seems clunky compared to:
>> 
>> (print buffer-undo-list 'stdout)
>
> Nothing a simple function won't heal, right?
>
> Maybe that's all we need: a small wrapper around append-to-file.

Actually, adding a new stream was your idea...

http://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00207.html

I'd never heard of streams in emacs before. I thought it seemed like a
nice idea, so I thought I would give it a go.

Yes, you are probably correct, that append-to-file could be used,
without resorting to new C primitives. However, all the functionality
that we need is already in the C layer. Also append-to-file (or rather
write-region) would need updating to not send messages.

It would also allow fixing this:

(defun append-to-file (start end filename)
  (interactive "r\nFAppend to file: ")
  (prog1 (write-region start end filename t)
    (when save-silently (message nil))))

Append-to-file does not actually save-silently AFAICT, it just hides the
message quickly.

Phil

Re: Adding streams for standard out and standard err

[Davis Herring]

[Philip: I fumbled this message, sending it once just to you and losing 
my copy.  Sorry for the near-duplicate.]

> Yep. I would imagine that debugging to standard out will not become
> popular as a tool for debugging TTY display.

There are still options there: redirect stderr (since it's unbuffered) 
to a FIFO and read it with less(1), or use the multi-tty feature to 
separate the frame being debugged from the original controlling terminal...

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Re: Adding streams for standard out and standard err

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: emacs-devel@gnu.org
> Date: Thu, 21 Jul 2016 21:13:26 +0100
> 
> > Maybe that's all we need: a small wrapper around append-to-file.
> 
> Actually, adding a new stream was your idea...
> 
> http://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00207.html

It said "IF you want more flexibility".  It's not clear to me what
additional flexibility is being gained by your suggestions.

> Yes, you are probably correct, that append-to-file could be used,
> without resorting to new C primitives. However, all the functionality
> that we need is already in the C layer. Also append-to-file (or rather
> write-region) would need updating to not send messages.

Nowadays avoiding the message just needs to bind inhibit-message to a
non-nil value.

Anyway, this is a minor issue.  If I'm the only one who thinks new
primitives are unnecessary, then I won't fight the addition.  However,
if we do add them, perhaps we need to test the file descriptor for
validity and/or being different from the terminal output device, and
provide some helpful diagnostics if it isn't, because I don't really
believe in people being aware of the pitfalls.  E.g., I many times
"rediscover" the problem when I need to debug a TTY session of Emacs.

Re: Adding streams for standard out and standard err

[Phil Sainty]

I'm all for a more obvious way to write to stderr (albeit more for
batch uses in my case).

In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17390 it was pointed
out to me that a PRINTCHARFUN function for stderr already exists --
`external-debugging-output' defined in print.c

I failed to follow up on that, but at the time I was thinking that
it would be nice to have a `standard-error' variable set to this
function, just like there's a `standard-output' variable, as it
would be dramatically more discoverable that way.

As `external-debugging-output' hadn't already cropped up in this
discussion, I just wanted to point it out in case it wasn't known
to everyone.


-Phil

Re: Adding streams for standard out and standard err

[Phillip Lord]

Phil Sainty <psainty@orcon.net.nz> writes:

> I'm all for a more obvious way to write to stderr (albeit more for
> batch uses in my case).
>
> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17390 it was pointed
> out to me that a PRINTCHARFUN function for stderr already exists --
> `external-debugging-output' defined in print.c
>
> I failed to follow up on that, but at the time I was thinking that
> it would be nice to have a `standard-error' variable set to this
> function, just like there's a `standard-output' variable, as it
> would be dramatically more discoverable that way.
>
> As `external-debugging-output' hadn't already cropped up in this
> discussion, I just wanted to point it out in case it wasn't known
> to everyone.


Well, there you go, never knew about that. And, except for the name, and
the fact that it gets whitespace correct, it's identical to my stderr.

I think my name is better, but open to differences of opinion.

So, options:

1) drop my patch
2) accept my patch, make external-debbugging-output use stderr (or vice
versa), to keep the name alive.

Don't really mind. I have no use case that differentiates between stderr
and stdout.

Phil

Re: Adding streams for standard out and standard err

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 21 Jul 2016 21:13:26 +0100
>> 
>> > Maybe that's all we need: a small wrapper around append-to-file.
> However, if we do add them, perhaps we need to test the file
> descriptor for validity and/or being different from the terminal
> output device, and provide some helpful diagnostics if it isn't,
> because I don't really believe in people being aware of the pitfalls.
> E.g., I many times "rediscover" the problem when I need to debug a TTY
> session of Emacs.


As Phil Sainty has pointed out, the primitive already exists. These
checks could be added to that also.

Phil

Re: Adding streams for standard out and standard err

[Andreas Schwab]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Yes, this is true, although they only print single characters, which is
> pretty useless for most people. In actual use, they look like this:
>
> (print "hello" 'stdout)
>
>
> Extending the name to reflect the full function:
>
> (print "hello" 'printchar-to-stdout)
>
> Seemed a bit duplicative to me.

But it is not an object, but a function, and its name should describe
its function.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Adding streams for standard out and standard err

[John Wiegley]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> Can we take a step back and talk about the need and the use cases?

At least for Eshell, I have wanted the ability to open and read/write directly
to file handles before. The main problem I see is problems such as exhaustion,
since we'd then have another resource being held open and managed by Emacs.
The downsides may not be worth the limited use cases.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2