tail: Refactor paths::Input::from and Settings::inputs

[Joining7943]

This pr refactors mainly the Input::from method and changes inputs in Settings from a VecDeque to a Vec.

There is no need for Settings::inputs being a VecDeque anymore and Vec is a little bit more efficient. In Input::from, unpacking AsRef<OsString> with .as_ref() just once is also a bit more efficient. Same with the comparison of OsStr with another OsStr instead of Path. Parsing the input arguments to a String and then back to an OsStr is unnecessary, since we can get the inputs raw as OsStr from clap to pass them to Input::from.

Note this pr also includes a small fix. When file headers are printed in verbose mode, the output for stdin should be equal on all platforms: ==> standard input <==. Before this change the output for non unix systems was ==> - <==.

[tertsdiepraam]

Can we do this without get_raw? Maybe with an OsStr or Path value parser?

[Joining7943]

What's the disadvantage of get_raw?

[tertsdiepraam]

Not sure there's a real disadvantage, but it feels like a workaround. Something that should only be necessary if you have parsed values and want to access the raw value as well.

[Joining7943]

I'm pretty sure it's meant as the direct way to access the parsed values as OsStr ;) imho value parsing to get an OsStr from clap is just a waste of resources.

[tertsdiepraam]

I'd be surprised if it actually did any parsing. It's just gonna expect an OsStr, which always succeeds and then can give us an OsStr as a value.

[Joining7943]

Can we do it the easy and direct way, please? From the docs of clap get_raw

Iterate over the original argument values.

With get_raw, there's nothing else between us and the OsStr, neither during compile time nor runtime and the code is clearly expressing that intent.

[tertsdiepraam]

That intent is exactly what an OsStr value parser expresses and it does it i n the clap builder, instead of at this location. It is in my opinion the most easy and direct way, because it uses claps normal parsing.

Besides: clap-rs/clap#3809

[Joining7943]

That clap issue is open waiting for decision since last year, so I think we can safely use it. Can we settle this please? If you insist I'll change it somehow, but I really don't think it's worth it.

[tertsdiepraam]

Fine. Let's hope I can make a better API than clap's if I ever find time to work on my own parser again :)

[Joining7943]

I wasn't very happy with the comparison with a new OsStr in Input::from every time this function is called, so I'm going to change it asap

UPDATE: It's changed now

[Joining7943]

@tertsdiepraam Just a quick question by the way. In the text module every variable is static. What is the advantage of using static over const in tail. Having such variables accessible in const context would be nice sometimes.

[tertsdiepraam]

I usually prefer const too. I think it's mostly legacy reasons that there's a lot of static for global constants in the codebase.

[Joining7943]

I usually prefer const too. I think it's mostly legacy reasons that there's a lot of static for global constants in the codebase.

Ok, then let's change them to const.

[tertsdiepraam]

I'm not sure, but I think this can be a b"-"?

[Joining7943]

Yeah, but it's just a single character. It doesn't play a big role here but the result is an array [u8; 1] instead of a reference to an array &[u8; 1].

[tertsdiepraam]

So you don't think

const DASH: &[u8] = b"-";

if value.as_bytes() == DASH { }

is clearer?

[Joining7943]

No not really, to me both look very similar and equally clear. However, the correct type of a byte string literal is &[u8; n] or better &'static [u8; n]. I first used b"-" but then changed it to [b'-'] to spare me the reference here and I'm sure that DASH is stored on the stack. We're talking here about a single character. If you have a longer string literal and just need it as a (reference to a) byte array than you might spare yourself a lot of typing by using a byte string literal.

[tertsdiepraam]

Actually, I think I'd actually prefer this:

let DASH = OsStr::new("-");
if value == DASH { }

Then we don't even need to think about byte strings.

[tertsdiepraam]

If you're worried about performance, they all generate the same assembly: https://godbolt.org/z/M66sjEqGe

[Joining7943]

OsStr::new can't be const. Why can't we just keep that little optimization the way it is and noone needs to look at any assembly code and rely on compiler magic?

[tertsdiepraam]

No, my priority here is clear code. I'd still push for the change even if it was technically slower, because it's not worth optimizing. The current code harder to read without any advantage.

[jdonszelmann]

Outside observer looking through some PRs: I think OsStr is the nicer option here, it's clearer what's going on. [b'-'] is hard to read. And the performance seems to be the same anyway even though if the performance were different, it would not matter.

[Joining7943]

@tertsdiepraam Sorry, these kind of code reviews lately are boring me. Take this pr or leave it. If you decide for the first you should notice some improvements in code quality.

[tertsdiepraam]

Sorry, these kind of code reviews lately are boring me.

I'm sorry to hear that. I'll take a look at the PR and thanks for your work on this in any case!

[tertsdiepraam]

I've added a small commit with my last nitpicky comments :) @sylvestre or @cakebaker could you review it?

[sylvestre]

LGTM, thanks