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

Previous Next

Full log

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

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79442 <at> debbugs.gnu.org
Subject: Re: bug#79442: RFE: process-lines equivalent for NUL-separated output
Date: Sun, 14 Sep 2025 11:11:02 +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?

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.

Previous Next

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