Re: Built-in printf Sits Awkwardly with UDP.
On 2011-07-20 14:34 +0100, Ralph Corderoy wrote: > No. Here's my understanding of how it currently works. The built-in > printf works out a character to print at a time; no foresight needed or > used. It asks the C library to print it with putchar(3). The C library > can implement buffering to avoid too many expensive write(2) system > calls. bash has the C library buffer stdout by lines. Each time > putchar(3) is called the character is appended to the buffer. If the > character was '\n' or the buffer is now full then write(2) is called to > pass the buffer to the kernel and the buffer then treated as empty. > > When printf is finished the buffer is flushed, e.g. if there's anything > in it then write(2) is called. > > The C library provides two other modes of buffering, see setvbuf(3). > bash could easily detect that stdout is a regular file, have a new > stream be duplicated from file descriptor 1, and set it to > block-buffered. If standard output is a log file, log entries could remain latent for a very long time. The buffering mode we really want is buffered with a forced flush at reasonable intervals, E.G. one second after the last write. Unfortunately, there's no such thing in stdio. -- André Majorel http://www.teaser.fr/~amajorel/
Re: integer addition crash
Many thanks, guys!
On Wed, Jul 20, 2011 at 7:46 PM, Jonathan Nieder wrote:
>
> Hope that helps,
> Jonathan
>
> [*] http://tiswww.case.edu/php/chet/bash/FAQ
> question E8 ("Why does the arithmetic evaluation code complain about
> `08'?")
>
On Thu, Jul 21, 2011 at 7:47 AM, Pierre Gaston wrote:
>
> integer with a leading 0 are considered as octal by bash and 08 is not
> valid in base 8.
> you can force the base doing:
> echo $((10#08+1))
>
Re: Built-in printf Sits Awkwardly with UDP.
Andre Majorel writes: > On 2011-07-20 14:34 +0100, Ralph Corderoy wrote: > If standard output is a log file, log entries could remain > latent for a very long time. > > The buffering mode we really want is buffered with a forced > flush at reasonable intervals, E.G. one second after the last > write. Unfortunately, there's no such thing in stdio. That sounds like a bad design for a log file anyhow. Log entries should get flushed quickly, otherwise you lose the last few log entries before a segfault or signal and have fewer clues about the cause. -- Ben Pfaff http://benpfaff.org
[PATCH] use `job_control ' only when JOB_CONTROL is set
Hi,
job_control variable is declared conditionally (ifdef JOB_CONTROL) but
later it is used unconditionally. This results in build failure if
job control is disabled.
Patch attached.
--
Robert Millan
=== modified file 'execute_cmd.c'
--- execute_cmd.c 2011-07-21 21:35:21 +
+++ execute_cmd.c 2011-07-21 22:27:27 +
@@ -2202,7 +2202,11 @@
/* If the `lastpipe' option is set with shopt, and job control is not
enabled, execute the last element of non-async pipelines in the
current shell environment. */
- if (lastpipe_opt && job_control == 0 && asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
+ if (lastpipe_opt
+#if defined (JOB_CONTROL)
+ && job_control == 0
+#endif
+ && asynchronous == 0 && pipe_out == NO_PIPE && prev > 0)
{
lstdin = move_to_high_fd (0, 0, 255);
if (lstdin > 0)
