Re: [Bug: 21.5-b29] eol handling for process output on windows
On Mon, Oct 11, 2010 at 2:11 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Samuel Bronson writes:
> I've been seeing a lot of ^Ms in the output of various processes
> lately.
There was a bunch of work done trying to update comint to work with
more recent gdb and gud front-ends for XEmacs. Unfortunately, it
didn't work well and bunches of stuff got reverted.
I think the long-run solution is a "universal eol" eol type a la
Python. (There's also a Unicode TR that has something to say about
this.)
> I'm experimenting with the following in my init file:
>
> ;; assume process output to use DOS line-end style
> (setcar default-process-coding-system 'undecided-dos)
This probably also works, although you'll likely get stair-stepping
when you actually do work with Unix-style line endings.
That's not what I'm seeing -- does [X]Emacs even support
stair-stepping, outside of eterm?
What I'm seeing is basically the same as Python's universal newline
decoding (though I haven't exactly tried injecting Mac-style CR-only
text). Which is kind of what I expected. Really, the only app I can
think of that actually gets confused by LF-only text is notepad, which
displays some meaningless glyph for an LF (the dreaded box, perhaps?)
that has no preceding CR. All the other problems that I've seen with
that are related to terminal emulation, printing, or spurious
differences (i.e. diffing files of different eol styles that are
otherwise nearly identical).
> and that seems to work for this stuff, but I'm concerned
that this
> might run afoul of elisp programs trying to read binary data from
> processes. Any thoughts?
Programs trying to read binary data had better specify it with
'binary. If you run into a problem with binary I/O because of your
default setting, that's a bug in the program, not in your config.
Okay, that's very reassuring.
If you have some applications where you're unwilling to risk data
loss
even if you're entirely justified in changing the default, be specific
and we can audit them or you can test them.
Not at all! I was just not sure how well-behaved most code is in this
respect. (I know I myself have been guilty of leaving out the "b" far
too often in my C and Python programs, just because I was on *nix and,
presumably was either not thinking about the issue or was thinking
"nah, this is just for me and why would I be on Windows?")
Given what you've said, and that my setting doesn't seem to hurt with
LF-only process output, maybe the default should be changed on
Windows, or there should be a customize option or FAQ entry or similar
about this?
I don't really expect it makes all that much difference on Mac
anymore, since I that would probably only be relevant on classic and
... does that even have a standard API for commandline programs?
(Anyway, I assume those users have probably already figured out what
to do?)
Thanks,
-- Sam
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta