Argument `--length=0`/`--bytes=0` should be considered an error.

[eth-p]

This one might be a bit pedantic, but a user requesting that hexyl print nothing seems like a user error. The entire point of hexyl is to print a binary preview of a file, and explicitly asking it not to defeats the purpose of using it in the first place.

---

Note: I'm doing a class assignment regarding creating tests (from scratch) for an open-source command line program, and I chose hexyl for it. You might have a couple more of these on the way, depending on what the assignment brings to light :)

[sharkdp]

Hm. I'm not sure if there is an actual use case for that, but it seems unlikely that someone uses --length=0 by accident and would be surprised by the behavior. Someone might call hexyl from a script which automatically computes a value for --length where 0 could be a valid possibility (maybe when running several hexyl calls in succession). Even if unlikely, I'm not sure if we should artificially restrict a perfectly valid execution of hexyl.

[eth-p]

That's fair, I suppose scripts might have some use for it that I haven't considered. I'm honestly just not a fan of printing an empty grid without providing an explanation for it, though. It comes off as slightly unintuitive, especially when computed through a script where I can't immediately see "oh, I set the length to 0".

As a solution, maybe a (disableable) warning could be shown rather than printing an empty grid?

Or it could probably be addressed in a more generic way by adding a header or indicator somewhere explaining that hexyl is "Showing 0 bytes of 58321".

[sharkdp]

I'm honestly just not a fan of printing an empty grid without providing an explanation for it, though

There is also --border=none which would print nothing at all. But okay, I see your point. Let's make it a hard error in that case and disallow anything but positive N.

[eth-p]

Another point that I just came across was the error description for using --length=-1:

negative offset specified, but only positive offsets (counts) are accepted in this context

[ErichDonGubler]

Disclaimer: I'm interested in resolving this. Right now, I'm just going to triage things, but I hope to have solution after I finish researching and put in my vote for my elections as a US resident.

I'm basically going to summarize what's said above, in addition to stating my opinion here (for what it's worth). Sorry if this seems redundant. :)

• I agree that, in general, a diagnostic for a non-zero non-positive length makes sense, and could be valuable to have by default. But I'm not sure if it's worth breaking people at this point. The current behavior isn't unreasonable, as @sharkdp has mentioned; IMO it does produce a logically consistent result. That all said, @sharkdp seems inclined to make this breaking change (at least in the case of --border=none, which I actually disagree with) and that's what matters in this context (since he's the primary maintainer of this repo).
• In open source contexts with a large number of users (which I don't know is applicable here -- @sharkdp?), it's generally valuable to provide a transition path where behaviors that are changing in cases like these were relied upon before. It's hard to know who may have their flows broken by this, and having a deprecation period and/or a way to get back old behavior can be important for their experience. To elaborate on how I think this behavior should be changed:
  • --length={0,-1} should be a warning printed to stderr, but not an error in the sense that hexyl should stop printing the result. I can see at least a couple of situations where programatically generated calls to hexyl may be broken:
    • Elaborating on @sharkdp's : Some scripts or applications may find it easier (or even make sense) to fall back to generating a 0, rather than special-casing logic to determine whether to call hexyl or emit its own diagnostic.
    • A UI where showing empty content makes perfect sense. For example, a borderless display for a file preview pane like that found in ranger. This is a case where --border=none could actually make a lot of sense, because these sorts of applications/users may prefer that border style in their workflow.
  • A couple of orthogonal suggestions to ease this transition:
    1. Add a flag to allow the error case to continue as currently implemented, i.e., "--allow-zero-length". This would be one way to implement disabling a warning,
    2. Have a transition period from allow-by-default to warn-by-default, to use Rust upstream parlance for linting. I have no opinion on how long this should be, but this is a courteous way to allow users that stay up-to-date with their tools (i.e., rolling release distros like Arch Linux) the time to adapt their workflows.

Thoughts?

[sharkdp]

But I'm not sure if it's worth breaking people at this point

I am always worried about breaking backwards-compatibility, but it seems rather unlikely to me that someone relies on this as a feature.

with a large number of users (which I don't know is applicable here -- @sharkdp?)

Always a very hard question to answer. But judging from these statistics...

• GitHub downloads: https://somsubhra.com/github-release-stats/?username=sharkdp&repository=hexyl
• crates.io downloads: https://crates.io/crates/hexyl
• https://formulae.brew.sh/formula/hexyl#default
• https://pkgstats.archlinux.de/packages/hexyl

.. and from the fact that there are official packages for a number of package managers, I would guess that there are a few thousand users.

Elaborating on @sharkdp's : Some scripts or applications may find it easier (or even make sense) to fall back to generating a 0, rather than special-casing logic to determine whether to call hexyl or emit its own diagnostic.

:+1:

A UI where showing empty content makes perfect sense. For example, a borderless display for a file preview pane like that found in ranger. This is a case where --border=none could actually make a lot of sense, because these sorts of applications/users may prefer that border style in their workflow.

Excellent point.

Thoughts?

I suggest that we further support --length=0 without printing any warning or error. Negative lengths are not supported (and should not be).

I'm going to close the ticket, unless there are objections.