bug#6482: 24.0.50; emacs cannot deal with long lines in compilation or shell

bug#6482: 24.0.50; emacs cannot deal with long lines in compilation or shell

[jidanni]

$ emacs -Q -f shell
$ M='http://www.couchsurfing.org/find_cities.html?&city_name=c&state_id=3420&country_id=237&state_id=3424'
$ GET "$M"|grep -i hua #excuse me but I do not see a "hua" below
</TD></TR></TABLE></DIV>
$ GET "$M"|grep -i hua|wc #oh, emacs cannot deal with long lines
      1     198    7294

Also same problem with M-x compile with this
$ cat Makefile
F=http://www.couchsurfing.org/find_cities.html?&city_name=c&state_id=3420&country_id=237&state_id=3424
city_numbers:
	lynx -source '$F'|grep hua

In GNU Emacs 24.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2010-06-20 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20100619-2)

bug#6482: 6482

[Geoff Gole]

This has nothing to do with either line length or emacs. The html in
question contains a ^M near the end of that line, and it causes the
shell to behave a little strangely.

To illustrate, try the following in an xterm or something. Use C-v RET
to insert the ^M.

  $ grep abc <<EOF
  > abc^Mdef
  > EOF
  def

Now a longer line with a ^M towards the end:

  $ grep abc <<EOF
  > asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfsadfasdfsadfsadfsadfsadfasdfsadfsadfasdfasdfasdfsadfabc^Mdef
  > EOF
  deffasdfasdfasdfasdfasdfasdfasdfasdfasdfsadfasdfsadfsadfsadfsadfasdfsadfsadfasdfasdfasdfsadfabc

Pretty strange, but nothing to do with emacs. An additional wrinkle is
that in M-x shell C-q C-m won't produce the same behaviour, the shell
seems to see it as a newline. Use a file containing a ^M if you test
this in M-x shell.

bug#6482: ^M zaps results

[jidanni]

GG> Pretty strange, but nothing to do with emacs.

All I know is for those tests of mine, at most there was only a split
second where we could see the thousands of characters. Whereas outside
of emacs in bash in xterm, there they were left pleasingly sitting on
the screen.

bug#6482: ^M zaps results

[Geoff Gole]

>
> All I know is for those tests of mine, at most there was only a split
> second where we could see the thousands of characters. Whereas outside
> of emacs in bash in xterm, there they were left pleasingly sitting on
> the screen.
>

No, what the xterm showed you was junk with part of the text
overwritten because of the ^M. You just didn't notice because the
overwritten text didn't happen to be the bit you were interested in.

You can't expect to cleanly view text that contains control characters
at a shell prompt. Pipe it to less or something.

bug#6482: ^M zaps results

[jidanni]

GG> You can't expect to cleanly view text that contains control characters
GG> at a shell prompt. Pipe it to less or something.
OK, you win.