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,
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 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
>
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,
> 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 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
> > >
>
> 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
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 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 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 wou
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,
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
14 matches
Mail list logo
