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?

  • 1
    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... Nov 25, 2019 at 17:02
  • No xe has not. The question says "without any option or argument". Adding the option --help is not "without any option or argument".
    – JdeBP
    Nov 26, 2019 at 15:49
  • 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?
    – tapzx2
    Jun 11, 2021 at 20:00

2 Answers 2


The standard synopsis for the rm utility is specified in the POSIX standard1&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 "$?"

... 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 "$?"

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.

1 since the 2016 edition, after resolution of this bug, see the previous edition for reference.
2 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?".

  • 4
    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
    – Grump
    Nov 25, 2019 at 9:36
  • 3
    @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
    Nov 25, 2019 at 13:37
  • 3
    @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".
    – Kusalananda
    Nov 25, 2019 at 15:55
  • 3
    @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.
    – Kusalananda
    Nov 25, 2019 at 16:11
  • 1
    @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.
    – Kusalananda
    Nov 25, 2019 at 17:27

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

  • 2
    It is 100% accurate, however is in not precise. Nov 23, 2019 at 9:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .