Re: [Sbcl-devel] with-output-to-string, run-program, encodings

[Richard M K. <kr...@pr...>]

"Nikodemus Siivola" writes:
> On Aug 3, 2007 11:06 AM, Harald Hanche-Olsen <ha...@ma...> wrote:
>=20
> > While working out a test case for the environment stuff,
> > I came across this behavior:
>=20
> Very short explanation: output to existing streams doens't deal with
> external formats.

A while back I wrote some code to do this, but Juho Snellman was
uncomfortable with adding more complexity to RUN-PROGRAM's interface.
People seem to keep asking for external-format support in RUN-PROGRAM,
however, so I've updated the patch to do transcoding, but only according
to the default external format, and without adding any new options to
the interface.  So in the presumably-common case where SBCL's default
external format agrees with the character encoding an external program
uses, we'll successfully encode data going to the process and decode
data coming from the process.  For example:

(with-output-to-string (o)
    (with-input-from-string (i "=C3=80=C3=81=C3=82=C3=83=C3=84=C3=85")
      (run-program "gawk" '("{print tolower($0)}")
                   :search t :input i :output o)))

"=C3=A0=C3=A1=C3=A2=C3=A3=C3=A4=C3=A5
"

Most of the pathological cases I can think of involving an external
program that doesn't obey system locale settings would seem to be
doable with something like iconv(1) in a pipeline, so it might be
that having RUN-PROGRAM only do transcoding according to the default
external format will be adequate (for Unicode-enabled builds, anyway).

Is there any opposition offering this kind of support for
external-formats in RUN-PROGRAM?  If not, I'll install these changes.

(If you look at the attached patch, you'll see I rewrote the temporary
file generating code and de-forked the #+win32 and #-win32 versions of
the RUN-PROGRAM function.  Output to string-streams continues not to
work under Windows, but that's not new with this change.)

--
RmK