Discussion: change -h to show --help

[cafkafk]

Description, and My View on This

In the realm of software development, user experience and intuitive design are
paramount. When users interact with a command-line tool, they often rely on
their prior knowledge and experience with other tools to guide their actions.
One of the most common expectations is that the -h flag will provide help or
usage information. This expectation is so deeply ingrained that it's almost a
universal standard in many command-line utilities.

The current configuration of the -h flag in EZA is for --headers. While
this might make sense from a functional standpoint, it can be a source of
confusion for many users, especially those who are accustomed to the -h flag
being associated with help in other programs.

Here are some reasons to consider changing the -h flag to indicate "help":

Consistency with Other Tools:

Many popular command-line utilities, such as curl, wget, and git, use
-h as a shorthand for help. Aligning with this convention can make EZA more
user-friendly and reduce the learning curve for new users.

Reduced User Frustration:

Imagine a scenario where a user, in need of assistance, instinctively types
-h expecting help but instead gets an unexpected output or an error.
This can be frustrating and might deter users from further exploring or using
EZA.

Ease of Discovery:

For many (including me), -h is the first flag they try when they're unsure
about a tool's usage. By aligning with this expectation, we ensure that users
can easily discover the tool's capabilities and how to use them.

EZA is shaking things up

Like our predecessor EXA, EZA makes some sensible changes regardless of
tradition. While there are historical precedents where tools like ls and
grep don't use -h for help, the modern trend and user expectation lean
heavily towards -h being associated with help.

---

In conclusion, by making this change, EZA can become more intuitive,
user-friendly, and aligned with the broader ecosystem of command-line
utilities.

That said, I know there are maintainers who disagree, thus, I think it's a good
idea to have a discussion thread for this so we can work towards a consensus

Refs: #285

[cafkafk]

Also, the current short option seems broken on fish.

[daviessm]

I don't have strong feelings either way (I tend to try --help first on commands) but have a slight preference for standardising -h to alias --help.

[cfxegbert]

I don't mind the change for -h for help. I've seen it used in other tools to follow symbolic links or human readable and we use it for headers. What would we use for the short form for the header?

[trinitronx]

Not sure whether the current goal is to keep flags consistent & portable across standard ls and eza (e.g. "drop-in replacement" for ls...) but the -h flag was already different between them:

• ls -h, --human-readable
with -l and -s, print sizes like 1K 234M 2G etc.
• eza -h, --header
Add a header row to each column.

That being said... -h is pretty standard short arg for --help. Seems fine to me.

If people are aliasing ls to eza it could break scripts which are expecting to be POSIX-compliant. However, one argument against keeping eza args similar is that it probably shouldn't be aliased to ls in such a way for non-interactive shells anyway. 🤷

[cafkafk]

I mean we also have to accept that ls is 40 years old at this point. If we want to be POSIX-compliant, perhaps we should make that a separate feature, e.g. an environment variable or a --posix flag?

[trinitronx]

I mean we also have to accept that ls is 40 years old at this point.

Yeah, that's fair. I'm all for using -h as --help, and for pushing forward with a more modern tool. I was just trying to assist with brainstorming pros & cons for or against it to help spur discussion.

If we want to be POSIX-compliant, perhaps we should make that a separate feature, e.g. an environment variable or a --posix flag?

It may not even be necessary or applicable in the case of -h... given that this flag is apparently not found in the POSIX ls standard specification anyway. It looks like only capital -H is in the standard to follow symbolic links listed on the command line. exa / eza already use -H to do something different anyway ("-H List each file’s number of hard links."

To play "devils advocate" and follow the "POSIX-compliant" argument to its logical conclusion: I went through the flags to check, and so far it looks like only -R, -a, -d, -i, -l, -n, -r, -u, -x, and -1 do similar things to the POSIX ls... and comparing the behavior of each shows some slight differences of output. So, I guess exa / eza already can't be assumed to be a "drop-in" replacement 🤷

I'm all for the --posix flag for that feature, but realize it'd take quite a bit more work to do that. I guess if enough people wanted it, the community could decide to split up the work to implement each unimplemented flag, and to bring eza's output & behavior for the other flags into compliance with the standard.

[sbatial]

I'm generally very much in favour of having -h as the help flag because the widespread use makes it very annoying when some tools use a different thing.

That being said.. As it completely changes an existing option (which some people are certainly using) it should be accompanied by an extra message (just at the top/bottom of the help text: please note. since vX.X.X -h is a shortand for help. The new shortand for --header is...) in the beginning imo