Running a command, are you saying “take this action” or “make this so”?

If the file being already 500G is not an error condition, it shouldn't generate an error. Just like a package management operation (refresh software index, remove or add a package) is idempotent, and will just do nothing if the conditions are already met.

To address the broader question: it really depends. A command is basically a function, but systemwide: you get to pick whether it's a pure function or whether it has side effects, or whether it's idempotent. Don't emit excessive errors, but don't hide them either.

First off, the name "resize" has the semantics of "take this action".

The "make this so" version would be:

    size 500G file

I think you're effectively asking, "Should an individual CLI command be imperative or declarative?"[1] I think when possible, declarative is superior.

Whether an error should be returned is a separate question. In the declarative "make this so" version, you would not return an error if the file were already 500G (ideally it would not mutate the file).

But in the imperative "take this action" version, it depends on the intended semantics of the imperative command. Compare `mkdir` (see tacostakohashi's comment) and `chmod`. In some cases you just need to know that you have what you wanted (chmod), and in others you might need to know if an actual occurred (mkdir).

---

[1]: You might think the question to be imperative vs functional. I'm not an expert, but I'm pretty sure purely functional programming is a subset of declarative programming that involves first class and higher order functions. I don't know of any CLI shell environments that support that. At the very least, though, a functional version of `size 500G file` would not change the state of the file system, and would instead "return" a 500G version via stdout.

The phrasing matters, but in general on a command line I take it as imperative commands or queries. Statements of what should happen (not what state should become true) or queries about the state of the system. "resize" suggests that the size should be changed, the error would be if 500GB can't be allocated for the file. If it were already 500GB it amounts to a no-op (though you could signal that this is the case, it shouldn't be an error because the file is the appropriate size already).

A declarative form might be ensure-size 500G file. With that it's clearer that you expect a no-op in the case the file is already the desired size. It could be the exact same command under the hood, but the name suggests a different perspective. Specifically that no-ops are in the set of expected and desirable actions that might come from the command.

Depends on if I'm thinking in an imperative or declarative programming style. ;)

I typically prefer declarative (functional). I'll often have 0-length arrays that I iterate over, and expect the program to do nothing and not generate an error.

It depends, could be either, often depends on flags.

For example, mkdir dir (error if it exists) / mkdir -p dir (no error if it exists).

The latter style allows for creating idempotent scripts, which can be nice.

I’d favour idempotence, because it allows retrying with the same result.

So more of a “make it so” approach, but it doesn’t matter if it’s imperative or declarative.

That being said, it depends on the action. “Send missile” should be imperative because it destroys something. I wouldn’t even turn it into “ensure 1 missile hit that target”, because it could lead to many missiles could be launch and that’s probably not the amount of control I’d like.

You're telling the system to "take this action"

The system needs to respond with whether or not it has been made so

In your example, the proper response from `resize 500G file` is `file is 500G`, or `cannot resize file`

Think of it this way. Your partner asks you to empty the dishwasher. But the dishwasher is already empty. Is that an error, dishwasher is already empty? Or a guess what it's already done, success!