From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 07:27:53 2025 Received: (at submit) by debbugs.gnu.org; 13 Sep 2025 11:27:53 +0000 Received: from localhost ([127.0.0.1]:54052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxOQ5-0004m9-5b for submit@debbugs.gnu.org; Sat, 13 Sep 2025 07:27:53 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52924) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxOQ2-0004l2-Q1 for submit@debbugs.gnu.org; Sat, 13 Sep 2025 07:27:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxOPu-0004P9-ON for bug-gnu-emacs@gnu.org; Sat, 13 Sep 2025 07:27:42 -0400 Received: from gavdos.tim-landscheidt.de ([2a01:4f8:1c0c:4bd6::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxOPs-00051P-Pa for bug-gnu-emacs@gnu.org; Sat, 13 Sep 2025 07:27:42 -0400 Received: from port-62-145-29-194.static.as20676.net ([62.145.29.194]:39218 helo=vagabond) by gavdos.tim-landscheidt.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uxOPn-0078Kp-3D for bug-gnu-emacs@gnu.org; Sat, 13 Sep 2025 11:27:36 +0000 From: Tim Landscheidt To: bug-gnu-emacs@gnu.org Subject: RFE: process-lines equivalent for NUL-separated output Organization: https://www.tim-landscheidt.de/ X-Debbugs-Cc: Date: Sat, 13 Sep 2025 11:27:34 +0000 Message-ID: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:1c0c:4bd6::1; envelope-from=tim@tim-landscheidt.de; helo=gavdos.tim-landscheidt.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Severity: wishlist The function process-lines executes a program and returns the lines of its output as a list. However using newlines as output separators is prone to errors, and therefore many programs support using NUL (?\C-@) to separate their output. Currently, with Emacs one needs to use constructs like: | (split-string | (shell-command-to-string | (concat "foo " | (shell-quote-argument "bar baz"))) | "\0" | t) It would be nice if Emacs shipped a function so that the above could be rewritten as: | (process-output "foo" "bar baz") From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 07:51:46 2025 Received: (at 79442) by debbugs.gnu.org; 13 Sep 2025 11:51:46 +0000 Received: from localhost ([127.0.0.1]:54154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxOnB-0001C3-R5 for submit@debbugs.gnu.org; Sat, 13 Sep 2025 07:51:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54320) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxOn6-0001B1-Rw for 79442@debbugs.gnu.org; Sat, 13 Sep 2025 07:51:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxOmz-0000uO-P1; Sat, 13 Sep 2025 07:51:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sJ4J0kYub7J8Shimz5RgGzugvCSEJMbBcUNjnyXYBCU=; b=T0dbO3dIw3T2 gTY5uvH3FG1dVXBDI2wfbDIuRrz9yh40/jMInVzwBGB6Ulc2mRWJc2m8p8N7XrRDX1kaaAHcydLxM D3eVHilEwCi9emvyT2FNV+PrczpjdaSlHaCk39ghPiEj61FVMQWzuANTujF4PXLfM2RQBB/zvdoJh ICJvdZbMCp4ebQOlHwctfvyoM8oUTivhS0sChbXL0/l6QnwDB4b7wfNWIpbGpI/qgKFdPudY5zvKp 4L7aaX4Td/r5WU3xnXi37enKwft/uaSA9zxrGdDGs1cs7XzaK7PZLUygEkyhpsL15qAoj/XHF/FXr G2ldPceM/vKfSQUsNY2DDA==; Date: Sat, 13 Sep 2025 14:51:30 +0300 Message-Id: <86y0qipo3h.fsf@gnu.org> From: Eli Zaretskii To: Tim Landscheidt In-Reply-To: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> (message from Tim Landscheidt on Sat, 13 Sep 2025 11:27:34 +0000) Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Tim Landscheidt > Date: Sat, 13 Sep 2025 11:27:34 +0000 > > Severity: wishlist > > The function process-lines executes a program and returns > the lines of its output as a list. However using newlines > as output separators is prone to errors, and therefore many > programs support using NUL (?\C-@) to separate their output. > > Currently, with Emacs one needs to use constructs like: > > | (split-string > | (shell-command-to-string > | (concat "foo " > | (shell-quote-argument "bar baz"))) > | "\0" > | t) > > It would be nice if Emacs shipped a function so that the > above could be rewritten as: > > | (process-output "foo" "bar baz") So you want process-lines to call split-string for you (given some optional argument)? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 08:00:46 2025 Received: (at 79442) by debbugs.gnu.org; 13 Sep 2025 12:00:46 +0000 Received: from localhost ([127.0.0.1]:54180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxOvu-0001pw-2s for submit@debbugs.gnu.org; Sat, 13 Sep 2025 08:00:46 -0400 Received: from gavdos.tim-landscheidt.de ([2a01:4f8:1c0c:4bd6::1]:46804) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxOvq-0001pd-Sc for 79442@debbugs.gnu.org; Sat, 13 Sep 2025 08:00:43 -0400 Received: from port-62-145-29-194.static.as20676.net ([62.145.29.194]:44412 helo=vagabond) by gavdos.tim-landscheidt.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uxOvm-0078Mb-2t; Sat, 13 Sep 2025 12:00:38 +0000 From: Tim Landscheidt To: Eli Zaretskii Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output In-Reply-To: <86y0qipo3h.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 13 Sep 2025 14:51:30 +0300") Organization: https://www.tim-landscheidt.de/ References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> Date: Sat, 13 Sep 2025 12:00:37 +0000 Message-ID: <87a52ywoii.fsf@vagabond.tim-landscheidt.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii wrote: >> The function process-lines executes a program and returns >> the lines of its output as a list. However using newlines >> as output separators is prone to errors, and therefore many >> programs support using NUL (?\C-@) to separate their output. >> Currently, with Emacs one needs to use constructs like: >> | (split-string >> | (shell-command-to-string >> | (concat "foo " >> | (shell-quote-argument "bar baz"))) >> | "\0" >> | t) >> It would be nice if Emacs shipped a function so that the >> above could be rewritten as: >> | (process-output "foo" "bar baz") > So you want process-lines to call split-string for you (given some > optional argument)? I'm not sure whether it is possible to add an optional argument to process-lines as it passes the remaining arguments to the executed program. How would such a call look like? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 08:57:49 2025 Received: (at 79442) by debbugs.gnu.org; 13 Sep 2025 12:57:50 +0000 Received: from localhost ([127.0.0.1]:54444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxPp6-0006HH-NQ for submit@debbugs.gnu.org; Sat, 13 Sep 2025 08:57:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50622) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxPp1-0006GW-Gn for 79442@debbugs.gnu.org; Sat, 13 Sep 2025 08:57:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxPot-0004VD-9h; Sat, 13 Sep 2025 08:57:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NFY9tYtjJF3Ao7/DWHi0fBxzzDox/P7zD98Em40MBU4=; b=BHN08uCW5DIE H5bW32z+V0FCSOLX557DobSIJtqM+njkKyD2JGu2z0LIna0BUdOwFkdIND7vEYEX3MBbLHfFauI0B XBGHONUkI3GesppPkjN2fJECA3cjJz6NLBbR8vwQEsyi5CYovpp8rl67AT2iEAL9B+Iz5WHNdVqOu 7k8FTt20m1xIy21I8SjMCghFJz0kczE6ds/trjzoSx6lNuaoLtjKcypz0gexrYixrKaJbauSu8JlI BKP23mYwdd3MCMl1Gx5XKUxzkz5WbHWZA21qYtP03heut3lBGU2W9SgpR8GyIkZDGddVkv/CSeX6V yAHlZGKUqmPVxkLNVrrScQ==; Date: Sat, 13 Sep 2025 15:57:30 +0300 Message-Id: <86wm62pl1h.fsf@gnu.org> From: Eli Zaretskii To: Tim Landscheidt In-Reply-To: <87a52ywoii.fsf@vagabond.tim-landscheidt.de> (message from Tim Landscheidt on Sat, 13 Sep 2025 12:00:37 +0000) Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Tim Landscheidt > Cc: 79442@debbugs.gnu.org > Date: Sat, 13 Sep 2025 12:00:37 +0000 > > Eli Zaretskii wrote: > > >> The function process-lines executes a program and returns > >> the lines of its output as a list. However using newlines > >> as output separators is prone to errors, and therefore many > >> programs support using NUL (?\C-@) to separate their output. > > >> Currently, with Emacs one needs to use constructs like: > > >> | (split-string > >> | (shell-command-to-string > >> | (concat "foo " > >> | (shell-quote-argument "bar baz"))) > >> | "\0" > >> | t) > > >> It would be nice if Emacs shipped a function so that the > >> above could be rewritten as: > > >> | (process-output "foo" "bar baz") > > > So you want process-lines to call split-string for you (given some > > optional argument)? > > I'm not sure whether it is possible to add an optional > argument to process-lines as it passes the remaining > arguments to the executed program. How would such a call > look like? That's not the important part of my question. I'm asking why is there a need for a new function whose only job is to call split-string. process-lines exists because several places in Emacs call it. By contrast, there was no reason until now to have a function that deals with lines of output separated by nulls. So adding such a function would mean we have a function that no one calls, and why would we do that, when the way to handle such output in a Lisp program is as simple as a single call of an existing function? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 13 22:00:06 2025 Received: (at 79442) by debbugs.gnu.org; 14 Sep 2025 02:00:06 +0000 Received: from localhost ([127.0.0.1]:58344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxc2A-00089s-0S for submit@debbugs.gnu.org; Sat, 13 Sep 2025 22:00:06 -0400 Received: from gavdos.tim-landscheidt.de ([2a01:4f8:1c0c:4bd6::1]:43268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxc26-00088e-Ji for 79442@debbugs.gnu.org; Sat, 13 Sep 2025 22:00:03 -0400 Received: from port-62-145-29-194.static.as20676.net ([62.145.29.194]:45282 helo=vagabond) by gavdos.tim-landscheidt.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uxc23-007A7O-1k; Sun, 14 Sep 2025 01:59:59 +0000 From: Tim Landscheidt To: Eli Zaretskii Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output In-Reply-To: <86wm62pl1h.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 13 Sep 2025 15:57:30 +0300") Organization: https://www.tim-landscheidt.de/ References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> <86wm62pl1h.fsf@gnu.org> Date: Sun, 14 Sep 2025 01:59:58 +0000 Message-ID: <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii wrote: >> >> The function process-lines executes a program and returns >> >> the lines of its output as a list. However using newlines >> >> as output separators is prone to errors, and therefore many >> >> programs support using NUL (?\C-@) to separate their output. >> >> Currently, with Emacs one needs to use constructs like: >> >> | (split-string >> >> | (shell-command-to-string >> >> | (concat "foo " >> >> | (shell-quote-argument "bar baz"))) >> >> | "\0" >> >> | t) >> >> It would be nice if Emacs shipped a function so that the >> >> above could be rewritten as: >> >> | (process-output "foo" "bar baz") >> > So you want process-lines to call split-string for you (given some >> > optional argument)? >> I'm not sure whether it is possible to add an optional >> argument to process-lines as it passes the remaining >> arguments to the executed program. How would such a call >> look like? > That's not the important part of my question. I'm asking why is there > a need for a new function whose only job is to call split-string. > process-lines exists because several places in Emacs call it. By > contrast, there was no reason until now to have a function that deals > with lines of output separated by nulls. So adding such a function > would mean we have a function that no one calls, and why would we do > that, when the way to handle such output in a Lisp program is as > simple as a single call of an existing function? Well, there are four calls in: | (split-string | (shell-command-to-string | (concat "foo " | (shell-quote-argument "bar baz"))) | "\0" | t) I want to reduce this to one. I don't know about the needs of Emacs core, but I use this pattern regularly to process the output of external programs where data may include newlines. As Emacs does not provide a single function for that purpose yet, any user who wants to process data that may include newlines must use this pattern as well (or a similar one). Providing a function that makes it easy to pass data properly encapsulated to an external program and retrieve its separated output would make it harder for users to write insecure code. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 14 00:04:43 2025 Received: (at 79442) by debbugs.gnu.org; 14 Sep 2025 04:04:43 +0000 Received: from localhost ([127.0.0.1]:58815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxdyk-0001oF-V7 for submit@debbugs.gnu.org; Sun, 14 Sep 2025 00:04:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40662) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxdyg-0001nz-WE for 79442@debbugs.gnu.org; Sun, 14 Sep 2025 00:04:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxdya-0001dz-0I; Sun, 14 Sep 2025 00:04:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wtEjkxbTnEnm1LWLyP/0G0ZLH1LkpA1OStF65Giza04=; b=FFJQOjZL8vtN n6pS7JIIsXfW8QS955nyCLBIba6/K8/dRylJFKWtB5ko2TgO/tsYMdKWQfuCi74j4ChUrhti9s0wk /oe5pC0Kcsc2LrjmDY+ImCKczut709eOOEerv8BFNAhf26ZkfKMn/sqD9kdDaeTMWV0gteigNCQ2K y8yDTGNOFOdRvt21bnIZGnKX7bY1hd/FmvdGVOMjaeAFmFhoNFvzBcP1LaNjgEBIRCRN7msBY6kzR GtxdRFVkW/6SqJ+rom0avDxNERZ9UF9VH95a2NZTBwAwVSctFePHGu69wZ8lzGAXJ/6+1/zVGLRUz qgnVVcXpDkv/ouGsgLUDgg==; Date: Sun, 14 Sep 2025 07:04:27 +0300 Message-Id: <86cy7tptmc.fsf@gnu.org> From: Eli Zaretskii To: Tim Landscheidt In-Reply-To: <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> (message from Tim Landscheidt on Sun, 14 Sep 2025 01:59:58 +0000) Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> <86wm62pl1h.fsf@gnu.org> <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Tim Landscheidt > Cc: 79442@debbugs.gnu.org > Date: Sun, 14 Sep 2025 01:59:58 +0000 > > Eli Zaretskii wrote: > > > That's not the important part of my question. I'm asking why is there > > a need for a new function whose only job is to call split-string. > > > process-lines exists because several places in Emacs call it. By > > contrast, there was no reason until now to have a function that deals > > with lines of output separated by nulls. So adding such a function > > would mean we have a function that no one calls, and why would we do > > that, when the way to handle such output in a Lisp program is as > > simple as a single call of an existing function? > > Well, there are four calls in: > > | (split-string > | (shell-command-to-string > | (concat "foo " > | (shell-quote-argument "bar baz"))) > | "\0" > | t) > > I want to reduce this to one. You could start by writing your own function for that if you use this frequently, no? > I don't know about the needs of Emacs core, but I use this > pattern regularly to process the output of external programs > where data may include newlines. As Emacs does not provide > a single function for that purpose yet, any user who wants > to process data that may include newlines must use this > pattern as well (or a similar one). Providing a function > that makes it easy to pass data properly encapsulated to an > external program and retrieve its separated output would > make it harder for users to write insecure code. I see your point, but I'm not convinced we should add something like that. I welcome other opinions, with rationale. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 14 07:11:14 2025 Received: (at 79442) by debbugs.gnu.org; 14 Sep 2025 11:11:14 +0000 Received: from localhost ([127.0.0.1]:60519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxkdV-0006Zo-Lw for submit@debbugs.gnu.org; Sun, 14 Sep 2025 07:11:14 -0400 Received: from gavdos.tim-landscheidt.de ([2a01:4f8:1c0c:4bd6::1]:43736) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxkdQ-0006ZJ-1B for 79442@debbugs.gnu.org; Sun, 14 Sep 2025 07:11:10 -0400 Received: from port-62-145-29-194.static.as20676.net ([62.145.29.194]:33126 helo=vagabond) by gavdos.tim-landscheidt.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uxkdL-007C6h-35; Sun, 14 Sep 2025 11:11:04 +0000 From: Tim Landscheidt To: Eli Zaretskii Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output In-Reply-To: <86cy7tptmc.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Sep 2025 07:04:27 +0300") Organization: https://www.tim-landscheidt.de/ References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> <86wm62pl1h.fsf@gnu.org> <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> <86cy7tptmc.fsf@gnu.org> Date: Sun, 14 Sep 2025 11:11:02 +0000 Message-ID: <87ikhlcmrd.fsf@vagabond.tim-landscheidt.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii wrote: >> > That's not the important part of my question. I'm asking why is there >> > a need for a new function whose only job is to call split-string. >> > process-lines exists because several places in Emacs call it. By >> > contrast, there was no reason until now to have a function that deals >> > with lines of output separated by nulls. So adding such a function >> > would mean we have a function that no one calls, and why would we do >> > that, when the way to handle such output in a Lisp program is as >> > simple as a single call of an existing function? >> Well, there are four calls in: >> | (split-string >> | (shell-command-to-string >> | (concat "foo " >> | (shell-quote-argument "bar baz"))) >> | "\0" >> | t) >> I want to reduce this to one. > You could start by writing your own function for that if you use this > frequently, no? Yes. >> I don't know about the needs of Emacs core, but I use this >> pattern regularly to process the output of external programs >> where data may include newlines. As Emacs does not provide >> a single function for that purpose yet, any user who wants >> to process data that may include newlines must use this >> pattern as well (or a similar one). Providing a function >> that makes it easy to pass data properly encapsulated to an >> external program and retrieve its separated output would >> make it harder for users to write insecure code. > I see your point, but I'm not convinced we should add something like > that. I welcome other opinions, with rationale. Then it would be prudent to add the criteria that this rationale has to meet to (emacs) Bugs. Usually, the first or second adjective in any (self-)description of Emacs is "extensible". If feature requests are ineligible if users can implement them on their own, then documenting this could save some time for all parties involved. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 14 08:12:25 2025 Received: (at 79442) by debbugs.gnu.org; 14 Sep 2025 12:12:25 +0000 Received: from localhost ([127.0.0.1]:60795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxlai-0006G8-FJ for submit@debbugs.gnu.org; Sun, 14 Sep 2025 08:12:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55830) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxlad-0006Ed-0N for 79442@debbugs.gnu.org; Sun, 14 Sep 2025 08:12:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uxlaT-0006CP-Gk; Sun, 14 Sep 2025 08:12:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=050/n+5CH29dkol56hDRarpp4fcbFfO+nL3VavoksKQ=; b=LHhimDpNvybC Vsu1noFVEdAvojwvLvQwld3XXuKH+T9FES/9rBqc8D6CHDuyIXHaAc/0XRR1X6dWJ+x2PJP+s9H8z 1kGlrN8O6a4fQE8lMRXHVbl2K8yqRF+Y6SndluGZSJW7tuALedJshhPIZAE2ox7SobL2kJPCDGNL8 3V+quwkh03Ocun6GFyfaobciNhMprBX/FSmLEFfn2e85PosfYDnv0RJUJRXZAvDn9FJWjAsZ3i6X8 IWAeaiMeUNg/5BGl7yQZf/fVmFcmOqvNudh4+X6o6+WWcrogjGvC51Tr3IAiIdwTDHuzYxOq7y9QW neNqztSQGHtvLZ/2YiRhJg==; Date: Sun, 14 Sep 2025 15:12:01 +0300 Message-Id: <86v7llnsha.fsf@gnu.org> From: Eli Zaretskii To: Tim Landscheidt In-Reply-To: <87ikhlcmrd.fsf@vagabond.tim-landscheidt.de> (message from Tim Landscheidt on Sun, 14 Sep 2025 11:11:02 +0000) Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> <86wm62pl1h.fsf@gnu.org> <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> <86cy7tptmc.fsf@gnu.org> <87ikhlcmrd.fsf@vagabond.tim-landscheidt.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Tim Landscheidt > Cc: 79442@debbugs.gnu.org > Date: Sun, 14 Sep 2025 11:11:02 +0000 > > Eli Zaretskii wrote: > > >> > That's not the important part of my question. I'm asking why is there > >> > a need for a new function whose only job is to call split-string. > > >> > process-lines exists because several places in Emacs call it. By > >> > contrast, there was no reason until now to have a function that deals > >> > with lines of output separated by nulls. So adding such a function > >> > would mean we have a function that no one calls, and why would we do > >> > that, when the way to handle such output in a Lisp program is as > >> > simple as a single call of an existing function? > > >> Well, there are four calls in: > > >> | (split-string > >> | (shell-command-to-string > >> | (concat "foo " > >> | (shell-quote-argument "bar baz"))) > >> | "\0" > >> | t) > > >> I want to reduce this to one. > > > You could start by writing your own function for that if you use this > > frequently, no? > > Yes. > > >> I don't know about the needs of Emacs core, but I use this > >> pattern regularly to process the output of external programs > >> where data may include newlines. As Emacs does not provide > >> a single function for that purpose yet, any user who wants > >> to process data that may include newlines must use this > >> pattern as well (or a similar one). Providing a function > >> that makes it easy to pass data properly encapsulated to an > >> external program and retrieve its separated output would > >> make it harder for users to write insecure code. > > > I see your point, but I'm not convinced we should add something like > > that. I welcome other opinions, with rationale. > > Then it would be prudent to add the criteria that this > rationale has to meet to (emacs) Bugs. If someone can come up with such criteria up front, I'm all ears. Usually, it's a judgment call of the Emacs maintainers, to be made on a per-case basis. > Usually, the first or second adjective in any (self-)description of > Emacs is "extensible". Emacs is extensible, but not every possible extension must be in Emacs OOTB. Many people have quite a lot of local code in their init files and local packages, without ever submitting that for inclusion in Emacs, and that is how it should be, IMO. Each one of us has his/her local needs and requirements which are not necessarily shared by or important to others. Emacs being extensible by users is important precisely for this reason. > If feature requests are ineligible if users can implement them on > their own, then documenting this could save some time for all > parties involved. It goes without saying that not every extension should be part of Emacs, I'm surprised that this is not self-evident. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 14 08:30:08 2025 Received: (at 79442) by debbugs.gnu.org; 14 Sep 2025 12:30:09 +0000 Received: from localhost ([127.0.0.1]:60870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uxlro-0007vo-Pm for submit@debbugs.gnu.org; Sun, 14 Sep 2025 08:30:08 -0400 Received: from gavdos.tim-landscheidt.de ([2a01:4f8:1c0c:4bd6::1]:48210) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uxlrh-0007tG-CX for 79442@debbugs.gnu.org; Sun, 14 Sep 2025 08:30:01 -0400 Received: from port-62-145-29-194.static.as20676.net ([62.145.29.194]:50030 helo=vagabond) by gavdos.tim-landscheidt.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uxlrd-007CHe-1R; Sun, 14 Sep 2025 12:29:53 +0000 From: Tim Landscheidt To: Eli Zaretskii Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output In-Reply-To: <86v7llnsha.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Sep 2025 15:12:01 +0300") Organization: https://www.tim-landscheidt.de/ References: <87ldmiwq1l.fsf@vagabond.tim-landscheidt.de> <86y0qipo3h.fsf@gnu.org> <87a52ywoii.fsf@vagabond.tim-landscheidt.de> <86wm62pl1h.fsf@gnu.org> <87tt15dc9t.fsf@vagabond.tim-landscheidt.de> <86cy7tptmc.fsf@gnu.org> <87ikhlcmrd.fsf@vagabond.tim-landscheidt.de> <86v7llnsha.fsf@gnu.org> Date: Sun, 14 Sep 2025 12:29:52 +0000 Message-ID: <875xdlcj3z.fsf@vagabond.tim-landscheidt.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79442 Cc: 79442@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii wrote: > [=E2=80=A6] >> If feature requests are ineligible if users can implement them on >> their own, then documenting this could save some time for all >> parties involved. > It goes without saying that not every extension should be part of > Emacs, I'm surprised that this is not self-evident. It should also have been self-evident that the feature requested here can be implemented by users themselves, yet there was a question about it, and I answered it.