.
*/
char *env_var = getenv(TERM);
if (env_var) {
if (!strcmp (env_var, emacs))
stdin_is_interactive = 1;
}
}
#endif
Peter
From: Christopher Wellons well...@nullprogram.com
To: sqlite-users@sqlite.org
Sent: Sunday, January 19, 2014 9:10 AM
Subject: [sqlite] Command line shell
When the shell is set to interactive (i.e. -interactive), the output
(stdout) is flushed with every prompt (shell.c:422) but stderr is not.
In some situations this leads to no error messages being displayed until
the stderr buffer fills.
This happens when running the official sqlite3 binary as
On Sun, Jan 19, 2014 at 11:10 AM, Christopher Wellons
well...@nullprogram.com wrote:
When the shell is set to interactive (i.e. -interactive), the output
(stdout) is flushed with every prompt (shell.c:422) but stderr is not.
Stderr is suppose to be unbuffered so that flushing is not
When the shell is set to interactive (i.e. -interactive), the output
(stdout) is flushed with every prompt (shell.c:422) but stderr is not.
Stderr is suppose to be unbuffered so that flushing is not required. Or is
that different for windows?
According to the stderr Linux man page stderr
On 19-01-2014 19:59, Christopher Wellons wrote:
When the shell is set to interactive (i.e. -interactive), the output
(stdout) is flushed with every prompt (shell.c:422) but stderr is not.
Stderr is suppose to be unbuffered so that flushing is not required. Or is
that different for windows?
On 19 Jan 2014, at 7:32pm, Luuk luu...@gmail.com wrote:
It is acceptable—and normal—for standard output and standard error to be
directed to the same destination, such as the text terminal. Messages appear
in the same order as the program writes them, unless buffering is involved.
(For
