GNU bug report logs - #76103
[PATCH] New function 'process-output'

Previous Next

Full log

View this message in rfc822 format

From: Alvaro Ramirez <alvaro <at> xenodium.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 76103 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, juri <at> linkov.net
Subject: bug#76103: [PATCH] New function 'process-output'
Date: Fri, 07 Feb 2025 09:17:34 +0000

Hi Eli,

Thanks for the questions and feedback.

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Álvaro Ramírez <alvaro <at> xenodium.com>
>> Date: Thu, 06 Feb 2025 19:06:25 +0000
>>
>> I find process-lines super convenient for glueing command line
>> utilities.
>>
>> Often wished I had a similar function that neither split into
>> lines (process-lines) nor relied on shell
>> (shell-command-to-string).
>>
>> Proposing process-output as a close cousin to process-lines.
>
> Thanks, but can you explain why shell-command-to-string is not 
> what
> you want?

1. Performance: Shell overhead isn't needed to get a process 
output.

(benchmark-run 1000
   (process-output "seq" "200")) => (1.239617 0 0.0)

(benchmark-run 1000
   (shell-command-to-string "seq 200")) => (4.049149999999999 0 
   0.0)

2. Convenience API: The existing process-lines API is simple and 
easy to reach out to when glueing command line utilities.

Would be handy to have the same convenience available via 
process-output.

 - Predictably and concisely named: easy to find, starts with 
 "process-".
 - Structure + versatility: IMO while list of args is partially 
 structured, it remains fairly versatile (benefits from other 
 list-operating functions) vs unstructured string.
 - Avoids all issues with unescaped params (compared to 
 shell-command-to-string).

> And in any case, given that the implementation is basically 4 
> lines of

Users would need to either re-implement this for each package they 
build or duplicate the 4 lines every time they want a short-lived 
process output.

> Lisp, why do we need this in Emacs,

Seems like a good core basic function to offer (same reasons as 
above) which package authors can rely on without duplicating 
across every packages.

>  and in subr.el on top of that

subr.el was chosen since that's where the existing process-lines 
lives. Happy to move to a more appropriate location. Suggestions?

> (which means it will be preloaded)?  Sounds like not justified 
> for
> such a simple function.  If some package needs it, and cannot 
> use
> shell-command-to-string (for reasons I still don't understand),
> it can easily implement it as a utility function, no?

I hope the above rationale helps. While in its entirety, it could 
be open to opinion, perhaps we can justify purely on performance 
alone?

>
> Stefan and Andrea, WDYT?

Previous Next

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