From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Tue, 31 Jul 2001 10:44:12 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: termios flag to control ecma-48 Message-ID: <3B668BFC.2438.201017@localhost> References: <3B6573E3 DOT 32619 DOT 11E0D3C AT localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com > So the relevant > question is: what is the practical consequence of raw output, and what > commands does it affect? The evidence I've seen suggests that the escape commands should be active. Cygwin and Linux act this way. The gnu termcap documentation in the "initialization for use of termcap" section distinguishes between output commands and output processing: Before starting to output commands to a terminal using termcap, an application program should do two things: Initialize various global variables which termcap library output functions refer to. These include PC and ospeed for padding (see Output Padding) and UP and BC for cursor motion (see tgoto). Tell the kernel to turn off alteration and padding of horizontal-tab characters sent to the terminal. To turn off output processing [berkeley method snipped] In POSIX or System V, you must clear the bit named OPOST. Refer to the system documentation for details. This distinction matches what cygwin and linux do. The merge of the two tty write function has the tab character work the same between raw and cooked mode. The excerpt casts doubt on the current handling of the tab char by the tty writer. It's output the same whether in raw or cooked mode. Perhaps tab in raw mode should just go directly to the tab stop instead of spacing its way there? I don't think going back to the previous raw mode behavior of sending the tab to __direct_output is good because it just prints a graphics character. Mark