GNU bug report logs - #79442
RFE: process-lines equivalent for NUL-separated output

Previous Next

Full log

Message #20 received at 79442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 79442 <at> debbugs.gnu.org
Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output
Date: Sun, 14 Sep 2025 07:04:27 +0300

> From: Tim Landscheidt <tim <at> tim-landscheidt.de>
> Cc: 79442 <at> debbugs.gnu.org
> Date: Sun, 14 Sep 2025 01:59:58 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.