[Beowolve]

So, I understand the basis of your comment. You have the knowledge to know that there are other things that may be "the right way" given your situation. I think what the author is getting at is that there are users who don't have that knowledge. Giving them a hint that is verbose and non arcane can make a world of difference. Speaking from personal experience, there are many developers that I have met who don't have basic *nix knowledge, much less knowledge of a terminal. The reality of the situation is that a business is going to hire people regardless of that ability. They want someone who can move the features out the door. Whether this is good or bad is probably beyond this conversation. I think, for those users, these sorts of helpful hints are extremely important because it makes them feel like they aren't stuck and helpless. I think that, to your point, it may be useful to have the CLI offer a "pro" mode in which you could set a config to not give you as verbose error messages. Annoying? Yes. However, it would strike a balance and serve both needs.

[IcePic]

Then again, on a recent linux system, the non-ability to write to the file might be permissions. Or an immutable attr, or selinux, or apparmor, or setfacl flags or a RO mount where it lies. As soon as you decide to print out the solution to "can't write to: X" you are in for a page full of advice on what to look for. Perhaps the disk was full, perhaps uid was wrong, perhaps the 5% reserved-for-root-only kicked in. You'd end up writing a unix sysadmin guide, and then perhaps the parent dir had too strict perms to allow you to write to a file in it...

[smarinov]

Also, on an unrelated note, I would never ever suggest novice users to blindly just give `chmod +w` to random locations. This is only marginally better than the `chmod 777 <root-folder-name>` that used to be so spread out in many (e.g. PHP-related) tutorials a decade or two ago.

[mixmastamyk]

Agreed, though perhaps it is just a bad example. I could imagine a situation where a single line of advice could be useful outside the realm of filesystem security or disk usage.

[jstanley]

I understand what you're saying, but this conversation is about the best way to design CLIs.

I agree that you can do lots of stuff suboptimally and still have a usable tool, but I disagree with the author on what the ideal error output looks like.

[dickeytk]

yes, exactly. I think being verbose and more human friendly is a much better way to design a tool than being terse and machine friendly.

Ultimately all we're doing is trying to save human time anyways.

[majewsky]

In practice, "being verbose" is usually the opposite of "human friendly". I much prefer a spot-on one-line error message over dozens of lines of logs with an error somewhere hidden in them. Verbose error messages usually mean that you didn't have time to design succinct ones.

Joel Spolsky's timeless advice applies: "Users can’t read anything, and if they could, they wouldn’t want to." https://www.joelonsoftware.com/2000/04/26/designing-for-peop...