Home / Alt manpages / unlink(1)

  • unlink(1)
  • User command
  • linux

Remove One File Safely with unlink

GNU unlink removes exactly one named file and does nothing else: no bin, no confirmation prompt, no built-in restore. It deletes the directory entry immediately, so the checking has to happen before you press Enter, not after.

  • Time: about ten minutes.
  • You need: a shell, a file you are certain can be removed, and permission to modify its containing directory. No elevated privileges are needed for a file you own.
  • Version used here: GNU coreutils 9.4, package version 9.4-3ubuntu6.3.

Warning

Unlink is destructive. Make a copy first if the contents might matter, and check the path before pressing Enter. If the file is valuable, stop here and use your normal backup or recovery process instead.

1. Check the installed command

Confirm which executable your shell will run and read the local version. These checks are ordinary and read-only:

$ command -v unlink
/usr/bin/unlink
$ unlink --version
unlink (GNU coreutils) 9.4

The installed manual has a deliberately small interface. Its normal form is unlink FILE, and the only documented options are --help and --version. There is no recursive mode, force option, interactive prompt or wildcard mode.

Checkpoint

If command -v finds an unexpected program, pause and inspect your PATH before removing anything. The examples below describe the GNU command shown by the version check.

2. Inspect the exact path

Replace /path/to/file with the file you actually intend to remove, never leave the placeholder in the command. Inspect the path first, without changing anything:

$ ls -l -- /path/to/file
-rw-r--r-- 1 alice alice 1234 Sep 27 10:15 /path/to/file
$ file -- /path/to/file
/path/to/file: ASCII text

Your output will differ; check the complete path, owner, size and file type. The -- tells ls and file that the following value is a path, even if its name starts with a hyphen. It does not turn a mistaken path into a safe one, so read the output before continuing.

For a relative path, print the directory you are currently in first:

$ pwd
/home/alice/project
$ ls -l -- ./old-output.txt

A relative path is interpreted from the current directory, and each shell has its own. Changing directory in another terminal window does not follow you here.

3. Make a recovery copy when needed

There is no general unlink undo. Once the final directory entry is gone and no process still has the file open, the data may be reclaimed. If the contents might matter, copy them to a clearly different destination before deletion:

$ cp --preserve=all -- /path/to/file /path/to/file.backup
$ cmp -- /path/to/file /path/to/file.backup

A successful cmp with no output means the copies compare equal. Keep the backup until you have confirmed the deletion was correct. Restoring later is a separate, state-changing operation of its own:

$ cp --preserve=all -- /path/to/file.backup /path/to/file

Do not use a backup name that could itself be confused with the source. If the original file is sensitive, protect the backup with the same care and remove it deliberately, only once the retention decision is clear.

4. Remove exactly one file

After the path check, pass one pathname to unlink:

$ unlink -- /path/to/file

On success, GNU unlink prints nothing and exits with status zero; the blank output is expected. The command acts on one directory entry, so the pathname can be absolute or relative. Quote a path that contains spaces, wildcard characters or shell punctuation:

$ unlink -- "/path/to/old report.txt"

Do not add a glob such as *.tmp. The command accepts exactly one operand, and the shell may expand a glob into several operands before unlink even starts, which produces an error rather than a controlled batch operation. If you need to remove several files, review a separate, explicit workflow instead of turning this one-file example into a blind loop.

Checkpoint

No output is not proof that you targeted the intended file. Verify the path in the next step.

5. Verify the directory entry is gone

Run the same read-only listing check:

$ if test -e /path/to/file; then
>     echo "still exists"
> else
>     echo "removed"
> fi
removed

If the command succeeds and the check reports removed, the pathname no longer resolves to an existing file. A process that already had the file open can still hold its contents temporarily, but that does not make the pathname available again, and it does not mean a running service has reloaded a replacement.

For a simple shell check, this is also enough:

$ test ! -e /path/to/file && echo removed
removed

6. Understand the common failures

If the path does not exist, GNU unlink reports an error and exits non-zero:

$ unlink -- /path/to/missing-file
unlink: cannot unlink '/path/to/missing-file': No such file or directory
$ echo $?
1

Treat this as a path-checking problem: re-run pwd and inspect the parent directory rather than immediately substituting a broader path.

A directory is never accepted:

$ unlink -- /path/to/directory
unlink: cannot unlink '/path/to/directory': Is a directory
$ echo $?
1

That is a useful boundary. unlink does not recursively delete directory contents, so do not reach for a recursive removal command merely because the target turned out to be a directory; decide first whether you really intend to remove its contents, then use a separately reviewed procedure.

Permission errors usually concern the containing directory, not just the file's mode bits. On a shared or protected location, ask the directory owner or administrator for the correct procedure. Using sudo changes which account performs the deletion and raises the consequence of a path mistake; it is not a repair for a typo.

An extra operand is also an error:

$ unlink -- /tmp/first /tmp/second
unlink: extra operand '/tmp/second'
Try 'unlink --help' for more information.

The exact diagnostic can vary with quoting and locale, but the important result is the non-zero status. Review the command line rather than assuming one of the files was removed.

7. Keep service and security boundaries in view

Removing a configuration, socket, lock or executable can disrupt a service even when unlink itself finishes successfully. Before changing a service-owned path, identify the owning service, its restart behaviour and your rollback copy. A running process may keep using an open inode while future starts fail because the name is gone.

Do not run this command from an automated job until the pathname is constructed and logged safely. Never combine untrusted input with a deletion command without strict validation: a filename that looks harmless in a message can resolve differently after a directory change, symlink replacement or deployment step.

Done means

  • Confirmed the tool. You checked the GNU unlink version and the exact command path.
  • Inspected the target. You looked at the complete pathname and its file details first.
  • Backed up what mattered. You made and checked a recovery copy when the contents mattered.
  • Removed exactly one file. You passed exactly one intentional file path to unlink.
  • Verified the result. The command returned status zero and a follow-up check confirmed the path is gone.
  • Know the limits of recovery. Restoring requires a separate backup, and open processes may still hold the old contents.