Debugging du v9.3

2023-07-19 Thread Saulius Krasuckas
Hello, I am trying to build Coreutils-9.3 from source. [1] If I run ./configure && make, it builds. But I noticed that it calculates some things wrong. So I decided to enable some debugging. Any suggestions? Since I found none, I looked up at the source and noticed the DU_DEBUG define: [2]

[PATCH] doc: Improve NUM documentation for head and tail

2023-07-19 Thread Dragan Simic
Clarify that the NUM values for head and tail are indices, and briefly describe the specifics of +NUM for tail. Signed-off-by: Dragan Simic --- src/head.c | 3 ++- src/tail.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/head.c b/src/head.c index 7bba1420c..e82f9e1

Re: tail: somewhat unexpected one-by-one in -c/-n +NUM option

2023-07-19 Thread Pádraig Brady
On 19/07/2023 15:32, Martin Castillo wrote: Hi, I noticed an asymmetry between head and tail regarding the -n +N syntax of tail. For context, I was calculating checksums of 1 GiB chunks of a big file a la: for i in $(seq 500); do head -c 1G | sha1sum >chunk-$i.sha1; done < bigfile This was int

Re: fix intermittent test failure triggered by split /tmp usage

2023-07-19 Thread Pádraig Brady
On 19/07/2023 17:52, Jim Meyering wrote: On Tue, Jul 18, 2023 at 11:14 AM Pádraig Brady wrote: The new test where `split -n 1/2 /dev/zero` exhausts /tmp will trigger other false positive failures in the test suite which happens often when running tests with RUN_VERY_EXPENSIVE_TESTS set. The at

Re: fix intermittent test failure triggered by split /tmp usage

2023-07-19 Thread Jim Meyering
On Tue, Jul 18, 2023 at 11:14 AM Pádraig Brady wrote: > The new test where `split -n 1/2 /dev/zero` exhausts /tmp > will trigger other false positive failures in the test suite > which happens often when running tests with RUN_VERY_EXPENSIVE_TESTS set. > > The attached patches tackle this by conso

Re: tail: somewhat unexpected one-by-one in -c/-n +NUM option

2023-07-19 Thread Dragan Simic
On 2023-07-19 16:32, Martin Castillo wrote: This should be documented a bit more clearly and maybe be included in the gotchas list. I just prepared a patch that improves the way this behavior is documented. I'll send this patch as part of a patch series I'm currently working on. I assume,

Re: tail: somewhat unexpected one-by-one in -c/-n +NUM option

2023-07-19 Thread Dragan Simic
On 2023-07-19 16:32, Martin Castillo wrote: I assume, this is because lines are numbered one-based, so this is more intuitive to use. But when working with bytes, one usually uses offsets. Is there a more intuitive way to get the last part of a file given an offset? You may want to have a look

tail: somewhat unexpected one-by-one in -c/-n +NUM option

2023-07-19 Thread Martin Castillo
Hi, I noticed an asymmetry between head and tail regarding the -n +N syntax of tail. For context, I was calculating checksums of 1 GiB chunks of a big file a la: for i in $(seq 500); do head -c 1G | sha1sum >chunk-$i.sha1; done < bigfile This was interrupted and I tried to continue by prepend