Remove One File Safely with unlink

You will remove one named file with GNU unlink, check that it has gone, and know what to do when the command refuses. The command removes a directory entry immediately. It does not move the file to a bin, ask for confirmation, or provide a built-in restore operation.

This guide uses GNU coreutils 9.4, installed here as package version 9.4-3ubuntu6.3. Allow 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.

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. 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 intend to remove. Do not leave the placeholder in the command. First inspect the path without changing it:

$ 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

The 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. A common distraction trap is changing directory in another terminal and assuming the first shell follows it. Each shell has its own working directory.

3. Make a recovery copy when needed

There is no general unlink undo. Once the final directory entry is removed and no process has the file open, the data may be reclaimed. If you may need the contents, 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 that the deletion was correct. Restoring later is a separate state-changing operation:

$ 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 after 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 when it contains spaces, wildcard characters or shell punctuation:

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

Do not add a glob such as *.tmp. The command accepts one operand, and the shell may expand a glob into several operands before unlink starts. That 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. 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. Do not immediately substitute a broader path.

A directory is not accepted:

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

This failure is a useful boundary. unlink does not recursively delete directory contents. Do not reach for a recursive removal command merely because the target is a directory; first decide whether you really intend to remove its contents and 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 increases 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 non-zero status. Review the command line rather than assuming that 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 continue 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.