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 d
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 machi
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 '
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
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 '%-9223372036854775808s.\n' foo
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
> 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. Pl
Hi André,
> > When printf is finished the buffer is flushed, e.g. if there's
> > anything in it then write(2) is called.
>
> If standard output is a log file, log entries could remain latent for
> a very long time.
I don't see why. I'm not asking for buffering across multiple calls to
the built
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
> wr
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 t
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'
[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.
$
C
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
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
> > 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
> > advanta
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
> > nev
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 w
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.
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/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 'foo\nbar\n'>/dev/udp/l
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 pe
21 matches
Mail list logo
