Configuration Information [Manually overridden, the bug happened a while ago]:
Machine: i386 (32-bit), also occurs on amd64 (64 bit)
OS: freebsd12.3-RELEASE-p6
Compiler: cc
Compilation CFLAGS: unknown, from a pre-built FreeBSD package
uname output: FreeBSD house.lr.los-gatos.ca.us 12.3-RELEASE-p6 F
4 (e.g. GNU bash, version 4.4.12(1)-release
(arm-unknown-linux-gnueabihf)):
$ BLA="1\.2"; echo 'x/'$BLA'/y/'
x/1\.2/y/
I found some discussion around this bug, but it seems not to be finally
fixed:
https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00087.htm
The Bash Reference Manual, Edition 5 and earlier versions define lists
of commands as follows:
"A list is a sequence of one or more pipelines separated by one of the
operators ..." (Bash Reference Manual 3.2.3).
Shouldn't that say commands rather than pipelines?
Ralph Jensen
ble-quotes, bash does pathname
expansion, but it doesn't contain a *, ?, or [ as listed under `Pathname
Expansion' in bash(1).
--
Cheers, Ralph.
o !!' 'set -H' ': bar' 'echo !!' |
> bash
!!
!!
$
I'd expect the second `!!' to be `: bar'.
What am I misunderstanding?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
configuration so other users aren't
caught out by it, and the damage that can follow.
What's the argument for why CD_COMPLAINS behaviour isn't the default?
The documentation doesn't match the current behaviour, matching instead
POSIX in saying there's zero or one directories.
Cheers, Ralph.
esn't it do this? If the behaviour isn't going to change
then the documentation should be altered to match.
Please keep me CC'd; I'm not subscribed.
Cheers, Ralph.
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 '%-9223372036854
ld always be flushed at the end of each printf
command, to do otherwise would break too many things and be
non-sensical. It also wouldn't match the behaviour of calling the
/usr/bin printf.
Cheers, Ralph.
P.S. Please keep me CC'd.
rogram to check that, yet.
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.
Cheers, Ralph.
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
sockets
and pipes could look the same. 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. Still, at least it explains the UDP
behaviour.
Thanks again, Ralph.
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
() 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 stdout isn't a tty, and not just for UDP use.
Cheers, Ralph.
ly based on this list?
If any Ubuntu bashers have the odd spare minute then
https://bugs.launchpad.net/ubuntu/+source/bash/+bugs could do with a bit
of love and attention. I've just marked invalid or fixed a few of the
bugs on there but there's plenty left.
Cheers, Ralph.
Report fol
17 matches
Mail list logo
