ridiculousfish 108fe574a0 Finally track down that cursed read test failure
The read.fish check has a test where it limits the amount of data passed to
`read` to 8192 bytes, and verifies that fish reads exactly that amount.
This check occasionally fails on the OBS builds; it's very hard to repro a
failure locally, but I finally did it.

The amount of data written is limited via `yes` and `dd`:

    yes $line | dd bs=1024 count=(math "$fish_read_limit / 1024")

The bug is that `dd` outputs a fixed number of "blocks" where a block
corresponds to a single read. As `yes` and `dd` are running concurrently,
it may happen that `dd` performs a short read; this then counts as a single
block. So `dd` may output less than the desired amount of data.

This can be verified by removing the 2>/dev/null redirection; on a
successful run dd reports `8+0 records out`, on a failed run it reports
`7+1 records out` because one of the records was short.

Fix this by using `fullblock` so that dd will no longer count a short read
as a single block. `head` would probably be a simpler tool to use but we'll
do this for now.

Happily it's not a fish bug. No need to relnote it.
2022-04-02 11:33:07 -07:00
..
2021-11-11 16:46:23 +01:00
2020-02-08 13:30:48 +01:00
2019-06-26 21:19:40 +02:00
2020-01-19 15:07:06 +01:00
2021-02-15 17:08:26 +01:00
2021-06-23 21:30:10 +02:00
2020-12-29 12:48:11 +01:00
2020-02-17 11:39:53 +01:00
2021-07-21 22:33:39 +02:00
2019-07-09 10:02:50 -07:00
2021-06-24 18:17:10 +02:00
2021-06-24 20:46:03 +02:00
2021-12-13 01:24:47 -08:00
2022-02-21 22:48:43 +01:00
2021-03-02 14:53:02 +01:00
2022-03-24 10:23:04 +08:00
2020-03-16 21:21:10 +01:00
2021-06-24 18:17:10 +02:00