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

jwz> It's not merely truncating the command line -- it's also apparently jwz> leaving the un-read characters on the input buffer, and then jwz> interpreting them as commands afterward! More Bogons From the Unixware docs: ---------------------------------------------------------------- In UNIX System V, if the data in the line-discipline buffer exceeds MAX_CANON in canonical mode and IMAXBEL is clear, all the bytes of data saved in the buffer up to that point are discarded without any notice, but if IMAXBEL is set and the data in the line-discipline buffer exceeds MAX_INPUT, the ASCII BEL character is echoed. Further input is not stored, and any data already present in the input-queue remains undisturbed. ... If MAX_CANON is defined for this terminal-device, it is a limit on the number of bytes in a line. The behavior of the system when this limit is exceeded is implementation-dependent. If MAX_CANON is not defined for this terminal-device, there is no such limit. It should be noted that there is a possible inherent deadlock if the program and the implementation conflict on the value of MAX_CANON. With both ICANON and IXOFF set when more than MAX_CANON characters transmitted without a line-feed, transmission is stopped, the line-feed (or carriage-return if ICRLF is set) never arrives, and the read is never satisfied. A program should never set IXOFF if it is using canonical-mode unless it knows that (even in the face of a transmission error) the conditions described previously cannot be met or unless it is prepared to deal with the possible deadlock in some other way, such as time-outs. NOTE: This would only occur if the transmitting side was a communications device (for example, an asynchronous port). This normally will not happen since the transmitting side is a user at a terminal. It should also be noted that this can be made to happen in non-canonical-mode if the number of characters received that would cause IXOFF to be sent is less than VMIN when VTIME equals zero. ... A terminal associated with one of these files ordinarily operates in full-duplex mode. Characters may be typed at any time, even while output is occurring, and are only lost when the character input buffers of the system become completely full, which is rare (for example, if the number of characters in the line discipline buffer exceeds MAX_CANON and IMAXBEL (see below) is not set), or when the user has accumulated MAX_INPUT number of input characters that have not yet been read by some program. When the input limit is reached, all the characters saved in the buffer up to that point are thrown away without notice. ... (why it sometimes works to split the command line into chunks delimited by Ctrl-d) EOF (<Ctrl>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. The EOF character is not echoed unless it is escaped or ECHOCTL is set. Because EOT is the default EOF character, this prevents terminals that respond to EOT from hanging up. ---------------------------------------------------------------- Lessons? In addition to the stuff in my previous message, we might want to fiddle with stty imaxbel/stty -imaxbel stty ixoff/stty -ixoff Another thing to note: shells often save/restore tty settings around every command executed, so typing `stty -a' into a shell might not give you the same tty settings that are active while the shell is reading input (rather than executing a command). To get the true tty settings used by a shell while reading input, you must type something like stty < /dev/pts/23 into _another_ shell.