From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#45198: 28.0.50; Sandbox mode Date: Sun, 20 Dec 2020 13:28:51 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Bastien , 45198@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 20 13:30:39 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kqxrC-0007ck-T0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Dec 2020 13:30:38 +0100 Original-Received: from localhost ([::1]:37612 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqxrB-0002mG-TT for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Dec 2020 07:30:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqxqd-0002kR-9Y for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60521) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kqxqd-0003ON-0l for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kqxqc-0000aB-Rm for bug-gnu-emacs@gnu.org; Sun, 20 Dec 2020 07:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Dec 2020 12:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45198 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 45198-submit@debbugs.gnu.org id=B45198.16084673502156 (code B ref 45198); Sun, 20 Dec 2020 12:30:02 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 20 Dec 2020 12:29:10 +0000 Original-Received: from localhost ([127.0.0.1]:43834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqxpm-0000Yi-Dg for submit@debbugs.gnu.org; Sun, 20 Dec 2020 07:29:10 -0500 Original-Received: from mail-ot1-f44.google.com ([209.85.210.44]:34062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqxpl-0000YW-7g for 45198@debbugs.gnu.org; Sun, 20 Dec 2020 07:29:09 -0500 Original-Received: by mail-ot1-f44.google.com with SMTP id a109so6448512otc.1 for <45198@debbugs.gnu.org>; Sun, 20 Dec 2020 04:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dWCwr+RiqpIDBg+4pc0m+Ui9BA5xHZrEqyrPzsFi9F0=; b=aDuxEzjPEOOGXNBmFchnrShY2wC/U0nMlADJPHCcCrsqFBHg3nlpCXNxfFM/tjDx4y 83VopibGX3hIvuTvyxx7XFTY3DAyJq57zB4aPpwBEmN/m0mTeJGqI7uMXu7Bzi/Cb4Om 0lrlQijMmXKi5dXBlol0YNJZaDMvpZZe31wmkkWP8cardd9+lHQ0011OvJb8003FAMfI rfbIK5PTHrVZ1UORHkOnKly4ApwbZBmGR0xj9EcvPpg1t9SuJPO02mPuffMiVoQJWMPW xWSaD9PNC0UYKu8LZGRNaV3UPQRqGW+1S/xmgMp6xQvjjncwLijurxf1OYIvTg8wJVIo j3Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dWCwr+RiqpIDBg+4pc0m+Ui9BA5xHZrEqyrPzsFi9F0=; b=eamO9yVOJ99XkeTuwHlxH+kqwZguWx4wvGqvNtatRJ3XIDpsT4RI9mv5lb8eU/vEx+ 6dY0Sh5n9ofRSi2rAAOTJBBddhj5Sd5KErUbc0k08Lw5ryi4QXxvIIfs9GIgeleT9Aso Np4BcFwGMKmGCg83olHHGJ96jnWjjEqGqaLygkoKDmjNPTfs9q2klPLyPMVFwvtWDq8n NGRPZEB+JfY5D+Wixzqnb1Vgk0tl9SJQ8DZ0JrIw6uY2EiLq1g0nUDCTsOz0ll4WgWnO Fu0/YnJeOYQNpXy+CfhvLWZfSRSK6K/diPU5fAGRDqusTQYw9F3Nxz+X9DdVkid3uKaq 8udw== X-Gm-Message-State: AOAM530Kh6wdzw6K/HsWgZ60/HX6le0rqUIfjNo26VGG2NohJ6xdtkzF n0u/qH9GLNMytZjUFHjgWp1K664zVIJP7s2an6Q= X-Google-Smtp-Source: ABdhPJx63kppc+vGSJP7aqFhrrShrODbyIShcArRhP0hwI+7CBDlqriHsUMcuj++gSLndAQu6rfY3cTu8qYthV9SRo8= X-Received: by 2002:a9d:72c4:: with SMTP id d4mr8996250otk.149.1608467343244; Sun, 20 Dec 2020 04:29:03 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:196465 Archived-At: Am So., 20. Dez. 2020 um 00:17 Uhr schrieb Stefan Monnier : > > >> I think "the right thing" would be to represent the parent as a process > >> object inside the child. I proposed dedicated functions only because > >> but when it uses stdin/stdout, providing a process object seems awkward > >> to implement. > > What would be the difference? It would be a pipe process wrapping some > > open file descriptor pair in both cases. > > Differences: > > 1- we don't have this pipe process wrapping of stdin/stdout so it's extra > C code we currently don't have. But we also don't have pipe processes wrapping file descriptors passed on the command line, or pipes that aren't close-on-exec, so core changes are needed in any case. > 2- I suspect that it wouldn't be quite so easy because it may interfere > with other preexisting uses of stdin/stdout in the C code. Yes, the read end of the pipe would have to deal with interleaved output from process-send-string and print. > > If/when someone implements that, then indeed we can just use a process > object to represent the parent in the client as well. > Yes, but again, there's no difference between the standard streams and using newly-allocated file descriptors. In both cases, you need a variant of Fmake_pipe_process that doesn't call pipe2 twice, but wraps two existing file descriptors in its infd and outfd. Whether those happen to be 0 and 1 or something passed on the command line makes no difference. On the parent process side, if you want to use a separate pipe pair, you need a way to create a pipe process that doesn't use O_CLOEXEC and allows reading out the open file descriptors to be able to pass them to the subprocess on the command line. These changes aren't large, but they are necessary if you want to go the "extra pipe pair" route.