* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). [not found] ` <20190422140756.5C1042088F@vcs0.savannah.gnu.org> @ 2019-04-22 20:59 ` Michael Albinus 2019-04-23 5:45 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2019-04-22 20:59 UTC (permalink / raw) To: emacs-devel; +Cc: Philipp Stephani p.stephani2@gmail.com (Philipp Stephani) writes: Hi, [sorry that I chime in such late; I didn't follow the discussion in Bug#35328] > +@cindex standard error process > +If @var{stderr} is a buffer, Emacs will create a pipe process, the > +@dfn{standard error process}. This process will have the default > +filter (@pxref{Filter Functions}), sentinel (@pxref{Sentinels}), and > +coding systems (@pxref{Default Coding Systems}). On the other hand, > +it will use @var{query-flag} as its query-on-exit flag (@pxref{Query > +Before Exit}). It will be associated with the @var{stderr} buffer > +(@pxref{Process Buffers}) and send its output (which is the standard > +error of the main process) there. FTR, the implementation in Tramp is different from what is described here. And honestly, I even don't know, how to implement these two processes for the remote case. The current implementation in Tramp redirects stderr to a temporary file, if it is separate from stdout. This temprary file is associated with the :stderr buffer, and it runs auto-revert-mode. Maybe not very elegant, but working so far. I don't know whether we shall document this different behavior, or whether we shall find an implementation in Tramp for what is described. For the latter, I would need help, as said. Or at least ideas. Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-22 20:59 ` master 3b4e312: Improve documentation around standard error pipes (Bug#35328) Michael Albinus @ 2019-04-23 5:45 ` Eli Zaretskii 2019-04-23 7:11 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2019-04-23 5:45 UTC (permalink / raw) To: Michael Albinus; +Cc: phst, emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Date: Mon, 22 Apr 2019 22:59:01 +0200 > Cc: Philipp Stephani <phst@google.com> > > > +@cindex standard error process > > +If @var{stderr} is a buffer, Emacs will create a pipe process, the > > +@dfn{standard error process}. This process will have the default > > +filter (@pxref{Filter Functions}), sentinel (@pxref{Sentinels}), and > > +coding systems (@pxref{Default Coding Systems}). On the other hand, > > +it will use @var{query-flag} as its query-on-exit flag (@pxref{Query > > +Before Exit}). It will be associated with the @var{stderr} buffer > > +(@pxref{Process Buffers}) and send its output (which is the standard > > +error of the main process) there. > > FTR, the implementation in Tramp is different from what is described > here. And honestly, I even don't know, how to implement these two > processes for the remote case. > > The current implementation in Tramp redirects stderr to a temporary > file, if it is separate from stdout. This temprary file is associated > with the :stderr buffer, and it runs auto-revert-mode. Maybe not very > elegant, but working so far. > > I don't know whether we shall document this different behavior, or > whether we shall find an implementation in Tramp for what is > described. For the latter, I would need help, as said. Or at least ideas. I think we should at least qualify the above description with its being accurate for local processes only. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-23 5:45 ` Eli Zaretskii @ 2019-04-23 7:11 ` Michael Albinus 2019-04-23 10:28 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2019-04-23 7:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: phst, emacs-devel [-- Attachment #1: Type: text/plain, Size: 384 bytes --] Eli Zaretskii <eliz@gnu.org> writes: Hi Eli, >> I don't know whether we shall document this different behavior, or >> whether we shall find an implementation in Tramp for what is >> described. For the latter, I would need help, as said. Or at least ideas. > > I think we should at least qualify the above description with its > being accurate for local processes only. Like this? [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 1399 bytes --] *** /tmp/ediffEO055I 2019-04-23 09:08:54.501926412 +0200 --- /home/albinus/src/emacs/doc/lispref/processes.texi 2019-04-23 09:05:04.977767519 +0200 *************** *** 734,740 **** Depending on the implementation of the file name handler, it might not be possible to apply @var{filter} or @var{sentinel} to the resulting ! process object. @xref{Filter Functions}, and @ref{Sentinels}. Some file name handlers may not support @code{make-process}. In such cases, this function does nothing and returns @code{nil}. --- 734,743 ---- Depending on the implementation of the file name handler, it might not be possible to apply @var{filter} or @var{sentinel} to the resulting ! process object. The @code{:stderr} argument cannot be a pipe; if it ! is a buffer a different implementation will be used to show the buffer ! contents. @xref{Filter Functions}, @ref{Sentinels}, and ! @ref{Accepting Output}. Some file name handlers may not support @code{make-process}. In such cases, this function does nothing and returns @code{nil}. *************** *** 1908,1913 **** --- 1911,1919 ---- (while (accept-process-output stderr-process)) @end example + Reading pending standard error from a process running on a remote host + is not possible this way. + @node Processes and Threads @subsection Processes and Threads @cindex processes, threads ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-23 7:11 ` Michael Albinus @ 2019-04-23 10:28 ` Eli Zaretskii 2019-04-23 12:05 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2019-04-23 10:28 UTC (permalink / raw) To: Michael Albinus; +Cc: phst, emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Cc: emacs-devel@gnu.org, phst@google.com > Date: Tue, 23 Apr 2019 09:11:23 +0200 > > Like this? Maybe. But what do you mean by "different implementation" here: > ! process object. The @code{:stderr} argument cannot be a pipe; if it > ! is a buffer a different implementation will be used to show the buffer > ! contents. ^^^^^^^^^^^^^^^^^^^^^^^^ This sounds vague and begs questions. Can we be more clear? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-23 10:28 ` Eli Zaretskii @ 2019-04-23 12:05 ` Michael Albinus 2019-04-23 12:16 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2019-04-23 12:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: phst, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Maybe. But what do you mean by "different implementation" here: > >> ! process object. The @code{:stderr} argument cannot be a pipe; if it >> ! is a buffer a different implementation will be used to show the buffer >> ! contents. ^^^^^^^^^^^^^^^^^^^^^^^^ > > This sounds vague and begs questions. Can we be more clear? I don't believe implementation details belong into that manual. What about The @code{:stderr} argument cannot be a pipe process, file name handlers do not support pipe processes for this. A buffer as @code{:stderr} argument is accepted, its contents is shown without the use of pipe processes. Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-23 12:05 ` Michael Albinus @ 2019-04-23 12:16 ` Eli Zaretskii 2019-04-23 14:09 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2019-04-23 12:16 UTC (permalink / raw) To: Michael Albinus; +Cc: phst, emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Cc: phst@google.com, emacs-devel@gnu.org > Date: Tue, 23 Apr 2019 14:05:38 +0200 > > The @code{:stderr} argument cannot be a pipe process, file name handlers > do not support pipe processes for this. A buffer as @code{:stderr} > argument is accepted, its contents is shown without the use of pipe processes. SGTM, thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328). 2019-04-23 12:16 ` Eli Zaretskii @ 2019-04-23 14:09 ` Michael Albinus 0 siblings, 0 replies; 7+ messages in thread From: Michael Albinus @ 2019-04-23 14:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: phst, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> The @code{:stderr} argument cannot be a pipe process, file name handlers >> do not support pipe processes for this. A buffer as @code{:stderr} >> argument is accepted, its contents is shown without the use of pipe processes. > > SGTM, thanks. Pushed to master. Best regards, Michael. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-04-23 14:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20190422140753.20611.97812@vcs0.savannah.gnu.org> [not found] ` <20190422140756.5C1042088F@vcs0.savannah.gnu.org> 2019-04-22 20:59 ` master 3b4e312: Improve documentation around standard error pipes (Bug#35328) Michael Albinus 2019-04-23 5:45 ` Eli Zaretskii 2019-04-23 7:11 ` Michael Albinus 2019-04-23 10:28 ` Eli Zaretskii 2019-04-23 12:05 ` Michael Albinus 2019-04-23 12:16 ` Eli Zaretskii 2019-04-23 14:09 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).