Re: Emacs Lisp's future

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> Date: Wed, 15 Oct 2014 09:16:20 -0400
>> From: Richard Stallman <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden
>> 
>>     I believe the commands that use shell-command-to-string are a good
>>     example of these cases.  That function is frequently used as
>>     infrastructure to query an external program about something, and the
>>     result is then used, at least in some cases, to decide how to proceed.
>> 
>> 1. The scenario we've been told about is where the invalid UTF-8 gets
>> passed on to some other program.  I don't think any harm will come if
>> Emacs itself looks at the output of the command.  Emacs does not
>> generally get confused by raw bytes.
>
> What Emacs gets from a program it can as easily send to another (or
> the same one).
>
>> 2. It would not be hard to make another function (which does strict
>> decoding) to recommend instead of shell-command-to-string for use in
>> Lisp code in certain cases.
>> 
>> 3. It would be easy enough to make shell-command-to-string do flexible
>> decoding when called interactively and do strict decoding when called
>> noninteractively -- controlled through an optional argument.
>
> I envision complaints from users if we do that.

Sounds like a recipe for a non-debuggable security nightmare.  Tampering
with content that Emacs does not know the meaning of, and doing so
differently in non-interactive use is a recipe for making Emacs do
unexpected things.

-- 
David Kastrup