Scenario:
XEmacs 21.1.4 w/file-coding but not MULE
(I think MULE is irrelevant, for this bug)
Problem:
When reading binary subprocess input (from crypt, pgp, etc.),
`call-process' in code-process.el sets `coding-system-for-read'
to `undecided', if `coding-system-for-read' is nil.
Unfortunately, `nil' represents the "binary" coding system. If
`coding-system-for-read' is `undecided' when subprocess input is
read, the first few (512?) bytes are examined to determine the
EOL type. Unfortunately, when reading binary input, \r (CR) is
a valid character, and will make the file-coding lstream input
think that CR to LF translation is required, which will corrupt
the input.
This is, er, "interesting"; `coding-system-for-read' needs to be
`nil' (for binary input), but `call-process' insists on setting
it to be `undecided'.
I'm not sure what to do. Perhaps we should allow both `t' and `nil' to
represent binary? In other words, these would be equivalent:
(get-coding-system nil) ;; for backwards compatibility
(get-coding-system t)
Perhaps we should add an explicit binary coding name?
Comments? In the meantime, I've kludged around the problem by not
having `call-process' set `coding-system-for-read' to be `undecided'.
I suspect this bug also exists in 21.2.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
