head,tail: implement undocumented option ---presume-input-pipe

[jfinkels]

GNU head and tail have an undocumented option ---presume-input-pipe (notice the three dashes instead of two). I don't know what it does, but here is an example of it:

$ printf "%0.sa\n" {1..100} | head ---presume-input-pipe
a
a
a
a
a
a
a
a
a
a

Lack of support for this option is preventing some of the GNU test suite test cases to fail.

(See similar issue in split here #2864.)

[tertsdiepraam]

Possibly interesting context: https://lists.gnu.org/archive/html/coreutils/2020-08/msg00017.html, specifically:

In fact, look at all the spots where 'presume_input_pipe' is used, to distinguish between seekable files where lseek works, and pipes where it doesn't (there is even an undocumented 'tail ---presume-input-pipe' option that lets you force-disable the lseek optimization, to get the speed penalty of a non-seekable file even when testing on seekable input).

I think it's okay to implement it as a noop for now, though.

On the clap side of things, clap does not normally allow 3 leading dashes anymore since clap 3, but there is a workaround: to use alias instead. In rm, I've implemented it a similar flag like this:

static PRESUME_INPUT_TTY: &str = "-presume-input-tty";
// snip
App::new(uucore::util_name())
  .version(crate_version!())
  .about(ABOUT)
  .arg(
      Arg::new(PRESUME_INPUT_TTY)
      .long(PRESUME_INPUT_TTY)
      .alias(PRESUME_INPUT_TTY)
      .hide(true)
  )

I looked into GNU coreutils. The parameter is used to bypass file seek operations. In uutils I see the below code differentiate between stdin (pipe) and file

coreutils/src/uu/head/src/head.rs

Line 424 in 6c1a655

let res = match file.as_str() {

I am thinking of doing "-" || PRESUME_INPUT_PIPE. Let me know if it works. I'll make the change.

Edit: I am not correct syntactically in the proposed solution, but I guess you get the idea. What I am trying to say is that the if the flag presume-input-pipe is true, then the code will follow the same path as stdin.

Is this still required? Can someone confirm if my approach is acceptable? I don't want to work on a PR that gets eventually rejected.

[tertsdiepraam]

@DevSabb I think what you're proposing is correct, at least that's what I would expect it to do based on your information and the mailing list I posted.