Re: shell buffer / tcsh command line length limit in RH 8?

jwz> Martin Buchholz wrote: jwz> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82610 jwz> Since upgrading from RH 7.2 to RH 8.0, I can no longer compose long jwz> command lines in tcsh when running in an XEmacs *shell* buffer. I don't jwz> know whether this is a bug in tcsh, or in readline, or what, but it does jwz> not happen with bash. jwz> Aha! Turns out it's xemacs's fault. >> xemacs tries to circumvent the system limit. If the command line is >> longer than 200 or so, it sends the command line in chunks of 200, >> with a '^D' character in between (!). This insanity has mostly worked >> for the past decade. "Usually" the '^D's are discarded. >> csh has always been a little special, because '^D' also does file >> completion. I remember that ten years ago, >> unset filec jwz> Bingo. "unset filec" fixes it. jwz> So if xemacs were either: jwz> - just sending all the bytes at once; or jwz> - sending them in chunks, but without the extra ^D If XEmacs sends more than MAX_CANON (usually 256) bytes all at once to the tty, it typically gets wedged in a most horrible way. Unfortunately, sending them in chunks without ^D has the same effect. EOF (Control-d or ASCII EOT) may be used to generate an end-of-file from a terminal. When received, all the characters waiting to be read are immediately passed to the program, without waiting for a newline, and the EOF is discarded. Thus, if no characters are waiting (that is, the EOF occurred at the beginning of a line) zero characters are passed back, which is the standard end-of-file indication. Unless escaped, the EOF char- acter is not echoed. Because EOT is the default EOF character, this prevents terminals that respond to EOT from hanging up. You can see the effect even today by doing: xterm bash -noediting (or Solaris /bin/sh) hold down the 'x' key. (or paste some text without newlines repeatedly) Eventually (1024 chars on Linux; 256 on Solaris) the xterm will refuse to allow any more input and will just beep at you. jwz> then it would work fine without "unset filec". The above description is only correct if icanon mode is turned on in the tty. That used to be generally true, but these days shells like to process their input characters themselves by default. The correct way to fix this bug is for XEmacs to check whether the tty is in icanon mode and the EOF character is defined. Then, and ONLY then, should the ^D trick be used to avoid MAX_CANON. It is probably also a bug that ICANON is set by XEmacs when it initializes a pty. If a user explicitly inserts a literal ^W into the shell input buffer, it is more likely that they want this passed to the shell than that they want to have the previous word be discarded by the tty. Emacs is a better editor than the tty -- the user already has backward-kill-word. I feel vaguely responsible for this, so I will make a patch. Martin