Hi,
I've just reported what I think to be a bug on Ubuntu but it's present
in pure bash 4.2 built from source too so I'm reporting it here. I'm
not subscribed to the list so please CC me. I take it there's no public
bug-tracker for bash and it's all done privately based on this list?
If any Ubu
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
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 wou
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 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 tha
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'
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
> 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 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 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
Hi,
Please keep me CC'd.
bash package 4.4.012-2 on Arch Linux,
`version 4.4.12(1)-release (x86_64-unknown-linux-gnu)'.
I'm trying to enable history expansion in a non-interactive bash with
`set -H'.
$ printf '%s\n' ': foo' 'echo !!' 'set -H' ': bar' 'echo !!' |
> bash
!!
!!
Hi,
bash 5.0.0-1 on Arch Linux. I'm manipulating a variable that's intended
to hold a regular expression for vim(1), but bash thinks it fails
pathname expansion even though I see no glob meta-character within it.
$ shopt -s failglob
$ ls -d foo
ls: cannot access 'foo': No such file o
Hi,
4.3.42(1)-release
`cd foo bar xyzzy' changes directory to foo, complaining if it doesn't
exist. It doesn't complain about the unwanted extra arguments. This
can cause problems; `cd *04' ends up in 2015-04, not 2016-04.
Keith Thompson raised this in 2010,
https://lists.gnu.org/archive/html
Hi Chet,
> > `cd foo bar xyzzy' changes directory to foo, complaining if it
> > doesn't exist. It doesn't complain about the unwanted extra
> > arguments. This can cause problems; `cd *04' ends up in 2015-04,
> > not 2016-04.
>
> If you want this behavior, you can build bash with CD_COMPLAINS
>
14 matches
Mail list logo
