I'm pretty sure this bug is caused by this issue:
https://github.com/util-linux/util-linux/issues/2336
TLDR: when using the --id=NNN parameter, logger sends random UID and GID
along with the PID you specify on the command line.
Those UID/GID probably don't exist on your machine/container and you
This is not a bug but the expected behavior.
Due to the use of a pipe, "readarray blah" is executed in a sub-shell.
But "echo ${blah[@]}" is executed in the parent shell. This has nothing
to do with readarray, the command ": | blah=blah; echo $blah" would also
fail to output blah.
On the other ha
Affects xenial too. There is definitely something wrong.
Several notes on this:
1. A direct call to "echo ${f[@]:0:1}" outputs "a". The problems thus
lies in the variable assignment.
2. If first_char=${f[@]:0:1}, then echo "$first_char" outputs \001 but
"declare -p first_char" outputs \001\001
This is not a bug, although some might disagree with the current
behavior of bash.
With a command like 'yes | grep -q .', because the grep terminates early
and the yes is writing past the end of the pipe buffer, the yes process
is _always_ terminated with a SIGPIPE signal (which translates to a
re
Affects trusty too. A quick way to reproduce this is (works 9 times out of 10
here):
$ bash -c 'read -N 1000' < /dev/urandom
Trusty output:
$ bash -c 'read -N 1000' < /dev/urandom
malloc: ../.././builtins/../.././builtins/read.def:603: assertion botched
realloc: start and end chunk size
** Tags added: trusty
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1683923
Title:
Empty extglob patterns hang bash
Status in bash package in Ubuntu:
Confirmed
Bug descr
Not a bug IMHO, but that may be open to debate. At least the observed behavior
conforms to the bash manual which reads:
- ((expression)) is strictly equivalent to: let "expression"
- parameter expansion is performed _before_ the expression is evaluated
Therefore, ((++a[$b])) translates to let "++
World splitting is correct; demonstration by the reporter is wrong.
The read command yields the expected array. When the array a is
substituted, the command
printf -- '-%s-\n' ${a[*]}
is interpreted as
printf -- '-%s-\n' a b c d
which produces the reported output indeed. On the other hand, the
In my opinion, this is not a bug (and probably not a feature either) but
the expected behavior.
bash's printf is a slightly modified version of the underlying printf()
function provided by the C standard library. The printf(3) manual
explicitly states that the precision is a number of _bytes_, not
Reattributing to the gtk+3.0 package...
This is not a problem with the yad package. According to the logs, the
only reason yad can't be installed is because its dependency
libgtk-3-0:i386 hasn't been properly configured. libgtk-3-0:i386 itself
hasn't been configured because its dependency libgtk-3
Thanks. IMHO, the title should no longer mention NTFS. The behavior can
be observed on any filesystem.
Try this, for example, on an ext* FS:
# touch foo
# ln foo bar
# gzip bar
gzip: bar has 1 other link -- unchanged
# bzip2 bar
bzip2: Input file bar has 1 other link.
# xz bar
xz: bar: Input file
This is the normal (yet unexplained AFAIK) behavior of many compression
tools like gzip, bzip2 and xz, to refuse to compress a file with a link
count > 1, unless you give the --force option. The actual questions here
are "why do my NTFS files have a link count of 2?" (see
COMP6366_V01_02_15_2011.wm
12 matches
Mail list logo
