Change `mktemp` so that it respects the value of the `TMPDIR`
environment variable if no directory is otherwise specified in its
arguments. For example, before this commit
$ TMPDIR=. mktemp
/tmp/tmp.WDJ66MaS1T
After this commit,
$ TMPDIR=. mktemp
./tmp.h96VZBhv8P
This matches the behavior of GNU `mktemp`.
It seems that `chrono` is the reason of deadlock or UB in android
CI. Also `chrono` had some security issues and wasn't maintained for
two years until March 2022, so other unstabilities can happen. Plus
`chrono` uses old `time` dependency.
Previously, if stdin redirect pointed to a regular file,
tailing started at the beginning of the file. However,
tailing needs to start at the current position because this
is expected by tests/tail-2/start-middle.sh.
This fixes the issue by taking the current offset into account
while going backwards through the stdin redirected file.
This fixes a bug where calling `tail - < file.txt` would result
in invoking `unbounded_tail()`.
However, it is a stdin redirect to a seekable regular file and
therefore `bounded_tail` should be invoked as if `tail file.txt` had
been called.
The previous encoding handling was unnecessarily complex. This commit removes the enum that specifies the handling and instead has two separate methods to collect the strings either with lossy conversion or by ignoring invalidly encoded strings.
Outside of tests, only `accept_any` was used, meaning that this unnecessarily complicated the code. The behaviour of `accept_any` is now the default (and only) option.
* Fix a bug in split where chunking would be skipped when the chunk size
happened to be an exact divisor of the buffer size used to read the
input stream.
The issue here was that file was being split byte-wise in chunks of 1G.
The input stream was being read in chunks of 8KB, which evenly divides
the chunk size. Because the check to allocate the next output chunk was
done at the bottom of the loop previously, it would never occur because
the current input chunk was fully consumed at that point. By moving the
check to the top of the loop (but still late enough that we know we have
bytes to write) we resolve this issue.
This scenario is unfortunately hard to write a test for, since we don't
explicitly control the input chunk size.
Fixes https://github.com/uutils/coreutils/issues/3790
