Hi Chet,
On 7/22/11 10:38 AM, Ralph Corderoy wrote:
On a related note, I can't interrupt this, e.g. Ctrl-C.
printf '%-92233720368547758q.\n' foo
That's interesting, since the fieldwidth (and precision) end up
getting set to 0 if they overflow INT_MAX, at least on my machine, and
On 7/25/11 8:49 AM, Ralph Corderoy wrote:
I also get, with vanilla 4.2 built from source,
$ ./install/bin/bash -c printf '%*q.\n' 10 foo -20 bar 0x8000
foo.
bar .
Segmentation fault (core dumped)
$
Thanks for the report. That's a different
On 7/22/11 12:32 PM, Ralph Corderoy wrote:
Hi Jim,
On 07/20/2011 07:34 AM, Ralph Corderoy wrote:
BTW, the code for the built-in printf has a bug. For negative
field-widths it negates a negative integer without checking it
will fit. E.g. on this 64-bit machine
$ printf
On 7/22/11 10:38 AM, Ralph Corderoy wrote:
OK, well for %b and %q bash's built-in printf calls it's own
printstr() and that does do things like `fw = -fw' without checking if
fw was already the largest negative.
On a related note, I can't interrupt this, e.g. Ctrl-C.
printf
OK, well for %b and %q bash's built-in printf calls it's own
printstr() and that does do things like `fw = -fw' without checking if
fw was already the largest negative.
On a related note, I can't interrupt this, e.g. Ctrl-C.
printf '%-92233720368547758q.\n' foo
Cheers, Ralph.
P.S.
retitle 9129 printf: RFE: reject field width larger than INT_MAX
tags 9129 notabug
thanks
Eric Blake wrote:
[adding coreutils]
On 07/20/2011 07:34 AM, Ralph Corderoy wrote:
BTW, the code for the built-in printf has a bug. For negative
field-widths it negates a negative integer without
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
Andre Majorel aym-...@teaser.fr 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
Hi Bob,
Ralph Corderoy wrote:
... But a regular file ./foo on disk does look different and it
still seems odd that
printf '\n\n\n\n\n\n\n\n\n\n\n\n' foo
does a dozen one-byte write(2)s.
But the only reason you know that there is a long string of newlines
is that your eye is
[adding coreutils]
On 07/20/2011 07:34 AM, Ralph Corderoy wrote:
BTW, the code for the built-in printf has a bug. For negative
field-widths it negates a negative integer without checking it will fit.
E.g. on this 64-bit machine
$ printf '%-9223372036854775808s.\n' foo
foo.
$
Hi Eric,
$ printf '%-9223372036854775808s.\n' foo
foo.
$
Coreutils' printf shares this misfortune. Sadly, it might even be a
bug in the underlying glibc printf(), although I haven't tried to
write a test program to check that, yet.
OK, well for %b and %q bash's
Hi Chet,
I see why it's line-buffered when writing to a terminal, but when
bash changes where stdout points it has the option to setvbuf(3) or
similar too based on what it knows about the destination, e.g.
/dev/pts/3 versus /tmp/foo versus /dev/udp/0x7f01/4242. Does it
never do
Almost exactly right, except replace unbuffered with line-buffered
output. Bash uses stdio and sets stdout and stderr to line-buffered.
The advantage of fully-buffered mode shows itself when writing large
amounts of data, which the shell does not do very often. The
advantage of
Ralph Corderoy wrote:
... But a regular file ./foo on disk does look different and it
still seems odd that
printf '\n\n\n\n\n\n\n\n\n\n\n\n' foo
does a dozen one-byte write(2)s.
But the only reason you know that there is a long string of newlines
is that your eye is looking over the
Hi,
(I'm not subscribed to the list so please keep me CC'd.)
Consider
printf 'foo bar\n' /dev/udp/localhost/4242
with bash's printf built-in, it works fine. One packet is sent.
However, make that two lines
printf 'foo\nbar\n' /dev/udp/localhost/4242
and two packets are sent, one per
On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
Hi,
(I'm not subscribed to the list so please keep me CC'd.)
Consider
printf 'foo bar\n'/dev/udp/localhost/4242
with bash's printf built-in, it works fine. One packet is sent.
However, make that two lines
printf
On Mon, Jul 18, 2011 at 10:46:19AM -0400, Steven W. Orr wrote:
On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
printf 'foo\nbar\n'/dev/udp/localhost/4242
and two packets are sent, one per line. If the aim is to send a string
of data in one packet this causes problems.
Using
On 7/18/11 10:46 AM, Steven W. Orr wrote:
On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
Hi,
(I'm not subscribed to the list so please keep me CC'd.)
Consider
printf 'foo bar\n'/dev/udp/localhost/4242
with bash's printf built-in, it works fine. One packet is sent.
However, make that
Hi Chet,
On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
Is this happening because the built-in printf is using putchar(3)
in the PC() macro and stdio thinks file descriptor 1 is still to a
tty so it's persisting in line buffering? It would seem nicer if
fewer write(2)s were done when
19 matches
Mail list logo
