From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Josselin Poiret Newsgroups: gmane.lisp.guile.user Subject: Re: Shell commands with output to string Date: Wed, 09 Mar 2022 15:14:21 +0100 Message-ID: <87r17bmcw2.fsf@jpoiret.xyz> References: <1280eba0-81c0-6e7b-d512-bbd1f83a409c@posteo.de> <87tucryzdg.fsf@gmail.com> <6d1232e036287a4cc7994d9fac5fceec@thomasdanckaert.be> <87czjdn0l1.fsf@jpoiret.xyz> <3080f6d4-e341-13a8-81e1-a6c7f6a3efb2@posteo.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user@gnu.org To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Mar 09 15:14:51 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nRx5W-0004Dn-84 for guile-user@m.gmane-mx.org; Wed, 09 Mar 2022 15:14:50 +0100 Original-Received: from localhost ([::1]:48138 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nRx5U-0002YW-Np for guile-user@m.gmane-mx.org; Wed, 09 Mar 2022 09:14:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRx5A-0002YO-F8 for guile-user@gnu.org; Wed, 09 Mar 2022 09:14:28 -0500 Original-Received: from jpoiret.xyz ([206.189.101.64]:52678) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRx58-00044j-Nq for guile-user@gnu.org; Wed, 09 Mar 2022 09:14:28 -0500 Original-Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 711E21851E4; Wed, 9 Mar 2022 14:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1646835262; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D58j15vu0QJULXtRYu5d3O6VAz5MM9HA73neuvPiwkM=; b=DM2Rwsf/o0Ukwjv1T27GVoelk4hxQHPp0PpGonPjE45jL8VyqmpRWGWzvXzuZOHPLdUn7J C+xaGdMyyulnm5vxSGBm+R8nYhhehA6mYBHGeJTvQQ4VkoiXjvbV5Fp4HDfYRpfxVnWjjv cAXY2Y45YJ4yBK0DMsB/ePOrqWILV+ipHSLaLd2Bh1mTtM6+f58jBQmisePjAzkdjmkd5X 5JKrkWHm1wWm46fs3tF+BP0fboWy4imVyekISfmpczjILtNjF+nrfjrvFI9f291aW2Tyv6 SUGPZpeEkZnpGs7nsO28jycIIHU4vDQRELmqbQ+YXCAoSUwwQJPn8uQ4k/lzbw== In-Reply-To: <3080f6d4-e341-13a8-81e1-a6c7f6a3efb2@posteo.de> Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spamd-Bar: / Received-SPF: pass client-ip=206.189.101.64; envelope-from=dev@jpoiret.xyz; helo=jpoiret.xyz X-Spam_score_int: 4 X-Spam_score: 0.4 X-Spam_bar: / X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.997, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:18175 Archived-At: Hello Zelphir, Zelphir Kaltstahl writes: > I have questions regarding this workaround: > > Can you explain how and why this works? I have tried to make sense of it and > here are my notes so far (reference: > https://notabug.org/ZelphirKaltstahl/guile-examples/src/2dead9f7bb9b40fc26eb490a93e1dc7abca7252c/shell/system-asterisk-stdout-to-stderr-redirection-bug.scm): Note that here, I used undocumented behavior of open-pipe*, which can be understood by inspecting libguile/posix.c (look for piped-process) and module/ice-9/popen.scm (look for open-pipe*). > ~~~~ > (match-let (((input . output) (pipe))) > ;; Hack to work around Guile bug 52835 -- How does > ;; duplicating the port help? From the docs: "Returns a > ;; new port which is opened on a duplicate of the file > ;; descriptor underlying port, with mode string modes as > ;; for open-file. The two ports will share a file position > ;; and file status flags. [...]" > (define dup-output (duplicate-port output "w")) The above Guile bug occurs because the current output and error ports point to the same file descriptor. Using duplicate-port makes sure that we get a port with a duplicated file descriptor! > ;; Void pipe, but holds the pid for close-pipe. > (define dummy-pipe > ;; Set current-input-port to /dev/null. -- What will be > ;; read from there? Nothing? > (with-input-from-file "/dev/null" Yes, for our use-case we don't need to feed anything to the command, but it's always possible to hook this up to a pipe if you need to. > (lambda () > ;; Set the current-output-port to the one created > ;; above using (pipe). > (with-output-to-port output > (lambda () > ;; Set the error port to the duplicated output > ;; port. This might be the redirection of stderr > ;; to stdout. > (with-error-to-port dup-output Exactly, this is the redirection. > (lambda () > ;; Run open-file*, but why is there an empty > ;; string prepended to command? Perhaps to > ;; allow using either a list or a string as > ;; a command? > (apply open-pipe* (cons "" command))))))))) Here's the undefined behavior, the first argument of open-pipe* is a mode for the pipe it opens, but here we don't want it to open any pipes, all our default ports are setup so that start_child will set the child's stdin/out/err to their file descriptors. > (close-port output) > (close-port dup-output) > (handler input) > (close-port input) > (close-pipe dummy-pipe)) > ~~~~ > > My other question is: Do I still need this workaround, if I use the following, > to run commands? And if so, why? In which cases would my code not do the right > thing? (reference: > https://notabug.org/ZelphirKaltstahl/guile-examples/src/2dead9f7bb9b40fc26eb490a93e1dc7abca7252c/shell/example-03-using-popen-get-out-and-error.scm): Looking briefly at your code, I don't think that bug could be affecting you. You can have an issue if you're trying to redirect a standard fd to another standard fd, but if you're using fresh ports it should be ok. Best, -- Josselin Poiret