Re: plzip: manual gives very false numbers, real defaults are huge!

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20240507005117.1xiDarQD@steffen%sdaoden.eu>:
 |Antonio Diaz Diaz wrote in
 | <6638EA2D.3000801@gnu.org>:
 ||Steffen Nurpmeso wrote:
 ...
 ||> Thanks for the quick response on a Saturday.
 ||
 ||You are welcome. :-)
 |I realized for the first time that standard input is treated in
 |a different way via the "one_to_one" mapping of yours.  Ie while
 |doing
 |
 |  time ./plzip -9 -n0 -c < /tmp/t.tar.xz  > x1.lz
 |
 |it occurred to me that the "struct stat" is not used at all for
 |stdin, which is a pity imho, especially since S_ISREG() is tested.
 ...
 ||This would break reproducibility (obtaining identical compressed output \
 ||from 
 ||identical input) because the size of uncompressed data read from standard 
 ||input (not from a file) can't be known in advance.
 |
 |That is true.  If not a regular file, then the above saturation
 |will unfortunately not work out.  Yet, i thought, limiting a

I slept over your approach, and while i of course accept it since
this is your program (i was only completely unaware, there is no
indication in the manual page), i think more than last night that
it contradicts the Unix philosophie (everything is a file) in that
"a file is a file", and "exe FILE" and "<FILE exe" are the ones
which should be identical, whereas "cat FILE | exe" is a pipe, and
even if its data *is* "FILE", it is a pipe production that could
be anything indeed, "exe" will never know.

But you obviously spent (quite some) time to design this "data
reproducibility" approach, and furthermore my file descriptor use
cases (even those with flock, i would think) are likely just as
special, and could be done differently, maybe better.


So one last question regarding the -n@NUMBER(including 0) patch,
i would like to include this for the plzip port i have for CRUX
Linux -- i am no longer a contributor to the project-hosted
"contrib" repository, but do this in private, nonetheless people
see it.  (The project queries all registered user repositories,
and provides software which searches in that DB, for example.)
The package system (no info, no README or the like are installed,
only manuals) has a

    readme <port>
    Print the port’s README file if it exists; if set, uses $PAGER

option, it prints a port-specific README file; would it be ok for
you if i note the presence of this non-upstream patch in such
a README file, or do i have to change the program name as such?
I could also patch the manual to note the presence of the
non-upstream patch within the installed package.

Thank you!
Ciao, and greetings from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)