Why does rm manual say that we can run it without any argument, when this is not true?

Question

We can see that the synopsis of rm command is:

rm [OPTION]... [FILE]...

Doesn't it mean that we can use only rm command without any option or argument?
When I run the command rm on its own, the terminal then shows the following error:

rm: missing operand
Try 'rm --help' for more information.

Can anyone tell me why this is the case?

Solution 1

The standard synopsis for the rm utility is specified in the POSIX standard^1&2 as

rm [-iRr] file...
rm -f [-iRr] [file...]

In its first form, it does require at least one file operand, but in its second form it does not.

Doing rm -f with no file operands is not an error:

$ rm -f
$ echo "$?"
0

... but it just doesn't do very much.

The standard says that for the -f option, the rm utility should...

Do not prompt for confirmation. Do not write diagnostic messages or modify the exit status in the case of no file operands, or in the case of operands that do not exist. Any previous occurrences of the -i option shall be ignored.

This confirms that it must be possible to run rm -f without any pathname operands and that this is not something that makes rm exit with a diagnostic message nor a non-zero exit status.

This fact is very useful in a script that tries to delete a number of files as

rm -f -- "$@"

where "$@" is a list of pathnames that may or may not be empty, or that may contain pathnames that do not exist.

(rm -f will still generate a diagnostic message and exit with a non-zero exit status if there are permission issues preventing a named file from being removed.)

Running the utility with neither option nor pathname operands is an error though:

$ rm
usage: rm [-dfiPRrv] file ...
$ echo "$?"
1

The same holds true for GNU rm (the above shows OpenBSD rm) and other implementations of the same utility, but the exact diagnostic message and the non-zero exit-status may be different (on Solaris the value is 2, and on macOS it's 64, for example).

In conclusion, the GNU rm manual may just be a bit imprecise as it's true that with some option (-f, which is an optional option), the pathname operand is optional.

---

¹ _{since the 2016 edition, after resolution of this bug, see the previous edition for reference.}
² _{POSIX is the standard that defines what a Unix system is and how it behaves. This standard is published by The Open Group. See also the question "What exactly is POSIX?".}

Solution 2

Technically, the synopsis is correct, but it is confusing. There are cases where no filename is needed:

rm --help
rm --version

(when using GNU rm). All other cases require a filename.

Other versions of rm show the file as non-optional, e.g. in the OpenBSD manpage.

A more accurate synopsis for GNU rm would show the three variants:

rm [options...] file...
rm --help
rm --version

Comments

[Harper - Reinstate Ukraine]

You've answered your own question. The very error message you quote there shows an example of using rm without an operand. --help is an option/flag. Obviously it doesn't need an operand if it's not acting on any files...

[JdeBP]

No xe has not. The question says "without any option or argument". Adding the option --help is not "without any option or argument".

[tapzx2]

Follow up question then... why does Kali Linux's man page have the above as the man page synopsis entry for rm instead of the POSIX standard?

[ctrl-alt-delor]

It is 100% accurate, however is in not precise.

[Grump]

ugh. using -f to avoid error in the event of no files needed to be deleted is... worrying -- because it'll also ignore that files are non-writeable

[Kusalananda]

@Grump The only issue you may have is when a directory is not writable (or executable, for access). Removing a file needs modification access on its parent directory, not on the file itself (as the file data is not modified). You can remove any file as long as you have w and x permission in the directory that contains it, no matter what the ownership or permissions on the file are.

[Kusalananda]

@Grump If you lack the correct permissions on the parent directory, rm -f will still give you a "permission denied" error.

[Grump]

Indeed you can remove the file regardless of its permissions, but /bin/rm will not remove a write protected file without prompting. Your answer appears to recommend using it to suppress errors for those instances where there are no files, without warning it will also ignore file write permissions when removing files

[Kusalananda]

@Grump My answer gives no such recommendation. To test for errors you would make use of the exit status of rm, as in if ! rm ... ; then act-on-error; fi. The thing I am saying is that if a list, "$@", may be empty or contain non-existent pathnames, then using rm -f -- "$@" will not generate a diagnostic message, and more importantly, will exit with a zero exit status, since the operation did not fail. This is useful in scripts.

[Kusalananda]

@Grump Maybe you are reading something into the text I've written that isn't there? Also, could you connect your concern with the actual question as currently stated?

[Grump]

Three people agreed with me, perhaps you're missing my point? "This fact is very useful in a script that tries to delete a number of files" -- could be taken as a recommendation. "-f" will cause unwritable files to be deleted without confirmation (arguably it's original purpose) however your "recommendation" doesn't mention this potentially unexpected side effect.

[Kusalananda]

@Grump I'm sorry, but I don't know what other side-effect there would be from using rm -f than to delete the files... If you have files that you don't want to delete, don't use rm on them at all. I really don't see what this has to do with using rm without arguments. If a script didn't want to delete files without confirmation, it wouldn't use rm -f. The standard says so: "Do not prompt for confirmation." and the GNU rm manual says "never prompt".

[Grump]

but you have "recommended" -f to remove errors attempting to delete zero files, without mentioning that it was also cause it to remove files without write permission that would otherwise not be removed.

[Kusalananda]

@Grump No. Using rm -f does not "remove" any errors. Using rm -f on an empty list of files is no error, so there is no error to remove. rm -f accepts an empty list. Using -f with rm also remove all prompting, which is obvious from the text I quoted, but not the point of the question. rm without -f also removes write-protected files if there is no controlling terminal, or if standard input is redirected from /dev/null. These are external conditions that the script has nothing to say anything about. Prompting may be useful to rely on on the command line, but rarely in a script.

[Grump]

Sorry, using rm -f suppresses the errors a script may generate if run without -f, not remove them.

[terdon]

@Grump I don't think anyone would ever suggest using -f as a way to suppress errors! That would be a very bad idea indeed. Kusalananda is just using it as an example where rm can run successfully (exit status == 0) without an argument which is what the question was about. So yes, rm can indeed be run without arguments. That's all.

[Grump]

exactly @terdon, it would be a very bad thing indeed, but "This fact is very useful in a script that tries to delete a number of files" could be understood to be doing exactly that - hence my first comment. I don't disagree with the answer, just dislike that particular bit of wording.

[Kusalananda]

@Grump Good. It feels like we're getting somewhere. You disagree with a wording. Could you give an example of an improvement? I don't think that the sentence means anything other than exactly what it says.

[terdon]

@Grump the best way to deal with something like this is to go ahead and edit the answer with your preferred wording. This is a collaborative site and editing is actively encouraged. Since you don't have enough reputation to edit directly, your edit will be a "suggested edit" ad will be added to the review queue. Then, if 3 users (or the post's author) approve it, it will be applied. Since neither Kusalananda nor I can see what makes you think this answer is suggesting using this in scripts, suggesting an edit is the best way of getting your point across.

[Rich]

You should clarify that per your link, this is for the Open Group implementation.

[Kusalananda]

@Rich The Open Group provides the POSIX standard, not an implementation. GNU implements that standard. If GNU rm behaves differently from what the standard says (with regards to the functionality that the standard prescribes), then this is arguably a bug in the GNU implementation.

[Rich]

@Kusalananda It sure looks like they're offering an implementation there... but you're right. The GNU manpage on my system says SYNOPSIS rm [OPTION]... FILE... which is an error in the documentation, because it can be used in a pipeline (which I see you didn't consider in your answer). Thinking of xargs which places a FILE arg there, so it gets ever-so-slightly confusing. Elsewhere, the docs are correct. gnu.org/software/coreutils/manual/html_node/rm-invocation.ht‌​ml and man7.org/linux/man-pages/man1/rm.1.html You should still say where you got your info.