Re: Tramp and conversion of \r\n into \n

[Thomas Ross <thomasross@thomasross.io>]

> Is this in "emacs -Q"?  If so, such conversion should not happen, on
> any OS.  Emacs converts CR on input, not on output, and
> process-send-string does the latter.

Yes, it is in `emacs -Q` -- this was determined to be done by the TTY
though, not Emacs. See Stefan's emails for more details. Sorry for the
confusion.

Thanks,
Thomas.

On 2021-08-05 2:16 a.m., Eli Zaretskii wrote:
>> From: Thomas Ross <thomasross@thomasross.io>
>> Date: Wed, 4 Aug 2021 21:46:02 -0400
>> Cc: APEL Martin <Martin.APEL@3ds.com>,
>>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>>> (make-process :name "hexdump" :command '("hexdump" "-v" "-e" "/1 \"%02X\n\"") :buffer "hexdump")
>>> (process-send-string "hexdump" "abc\r\n")
>>
>> on my system (Linux, Emacs 27.1):
>>
>>> 61
>>> 62
>>> 63
>>> 0A
>>> 0A
>>
>> Note that there's 61 ("a"), 62 ("b"), 62 ("c"), and two 0As (LF). The
>> first 0A should really be a 0D (CR). I believe this conversion is likely
>> done by the call to encode_coding_object inside send_process
>> (process.c), but I might be wrong. I would need to sit down and step
>> through the code with gdb to confirm.
> 
> Is this in "emacs -Q"?  If so, such conversion should not happen, on
> any OS.  Emacs converts CR on input, not on output, and
> process-send-string does the latter.
> 
>>> Content-Length: 2134<CR><LF>
>>> <CR><LF>
>>> {<...JSON here...>}<LF>
>>
>> Emacs replaces the CRs with LFs, which confuses clangd:
> 
> Again, this conversion can only happen on input, but you seem to be
> talking about output.
> 
> It is possible that some Tramp magic causes this bytestream to be
> input into Emacs at some point, as some temporary measure; in that
> case, you should look for the problem at that point, where Emacs reads
> these bytes, and disable decoding there.
>