From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Redirecting standard output Date: Thu, 21 Apr 2011 15:25:29 +0200 Organization: Programmerer Ingebrigtsen Message-ID: References: <83oc402ky4.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1303392362 20122 80.91.229.12 (21 Apr 2011 13:26:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2011 13:26:02 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 21 15:25:54 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QCttK-0007y0-NL for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2011 15:25:54 +0200 Original-Received: from localhost ([::1]:50853 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCttK-0002X6-8c for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2011 09:25:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCttF-0002Wi-Va for emacs-devel@gnu.org; Thu, 21 Apr 2011 09:25:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCttB-0002jD-1D for emacs-devel@gnu.org; Thu, 21 Apr 2011 09:25:49 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCttA-0002j8-JP for emacs-devel@gnu.org; Thu, 21 Apr 2011 09:25:44 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QCtt9-0007s4-Is for emacs-devel@gnu.org; Thu, 21 Apr 2011 15:25:43 +0200 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2011 15:25:43 +0200 Original-Received: from larsi by cm-84.215.51.58.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2011 15:25:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 22 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.51.58.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAD1BMVEWTXE1vPTNCGBeHUEOw hHVsrxz3AAACRklEQVQ4jU2UgXHkMAhF8aECjJQCzkoDImwByln913T/I28mnsQj6wkEH1iJiLGW iJrIFFnRovZeq5iZv0AUi6M1CY2j4xELb6OQeFW7WqjML4KgL7hYU+32i+c8LQacBr4Cztbd349J KQq39bKOo5abWAO84COEXnE7NnNRq8mYa05xhOgPuMwuglVgwwgR19VrAjPEvZCW4LuXue9IMMQH Ij4IXjOcV3yGmxfxU97BRMA5ABw9YId+DaVhb6LNBSBv5uWiXxvAPSxieh68RI706S5rLqib8SMW fS5TpCZLqmXGSFemPUCQGzOw2it0YrFoeuK4JECMbcBCouVdkGJbXAblzcrk2/6+YDo2gDDDGyuP pD8K65mgU5hYfO6IkottIesIyc9veHyAowHmvMdvMAliKPbu9gtMwRbAQBBq4w1iBILAvzAx61eC fz2rJ0dLIIOyapmaLWGn2glXoueaVMaCpxU5Wb0EzhQi3DXbxxrOYb9/8polzDXFNPQrhKkdroKS 4UG5ICZbOZpXAORTJlI6WKbY41L+nPSCsuDvwBwAcOMOWJS5JViVncjhAjB0BNyQlVnRMSiYsE6O bmcV0Nc66x63ITj4RcUn5Zumle+wUGxkKdLkrtEJhnpZ7EBWXmhsrQ+8T8Ek3U7wWuwjNc8GSyAc ILlokqPBdmsMagNri+EmgFZC8bHAONsHdIfee0gayuAJzsMKhMbOHpI2wjZAjI4Rs1Hf42P4mcEd 6zhZ2Pr4gmlWTLx82x4kqz8za338Bxamk6DAOjcyAAAAAElFTkSuQmCC Mail-Copies-To: never X-Now-Playing: Various's _The Wire Tapper 22_: "10-20 - athens" User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:4alDTW5uNGaqMtnUf9duZkhH2TI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138609 Archived-At: I've spent a couple of hours reading the code in `call-process' in more detail. Man, that's a complicated function. Thanks for the warning, Eli. :-) Anyway, I think that redirecting STDOUT to a file would be very easy to implement, and would be quite non-invasive. (The code already has a redirect-to-fd case, the /dev/null output, so there's very little code to add. Just open something else than /dev/null, and you're there, almost.) However, redirecting STDERR to a buffer seems like it would be quite complicated, unfortunately. I thought that having STDOUT and STDERR be handled symmetrically would be a nice feature (for redirecting STDOUT to one buffer and STDERR to another, for instance), but unless I'm reading the code wrong (and I very well could be), I don't see an obvious way to do that. Does this assessment of the complexities involved seem accurate? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/