GNU bug report logs - #6482
24.0.50; emacs cannot deal with long lines in compilation or shell

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6482 in the body.
You can then email your comments to 6482 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; emacs cannot deal with long lines in compilation or shell
Date: Mon, 21 Jun 2010 07:26:41 +0800

$ 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)

Message #8 received at 6482 <at> debbugs.gnu.org (full text, mbox):

From: Geoff Gole <geoffgole <at> gmail.com>
To: 6482 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: 6482
Date: Sat, 26 Jun 2010 11:24:16 +0800

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.

Message #11 received at 6482 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: geoffgole <at> gmail.com
Cc: 6482 <at> debbugs.gnu.org
Subject: ^M zaps results
Date: Sat, 26 Jun 2010 12:29:13 +0800

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.

Message #14 received at 6482 <at> debbugs.gnu.org (full text, mbox):

From: Geoff Gole <geoffgole <at> gmail.com>
To: jidanni <at> jidanni.org
Cc: 6482 <at> debbugs.gnu.org
Subject: Re: ^M zaps results
Date: Sat, 26 Jun 2010 13:29:21 +0800

>
> 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.

Message #17 received at 6482 <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: geoffgole <at> gmail.com
Cc: 6482 <at> debbugs.gnu.org
Subject: Re: ^M zaps results
Date: Sat, 26 Jun 2010 14:15:53 +0800

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.