Right, let’s talk about mv. It stands for “move,” but that’s a bit of a lie. It’s more of a “relocate and/or rename” command. It’s one of the simplest, most powerful tools in your box, and 99% of the time, it just works. That last 1% is where things get spicy, and where you’ll be glad you read this.

Think of mv less like a forklift and more like a librarian updating a card catalog. You’re not physically picking up the bits of the file and carrying them to a new location (most of the time). You’re telling the filesystem, “Hey, take this entry for old_name.txt and change it to point to new_name.txt or put it in that other directory over there.” This is why moving a 100GB file within the same filesystem is instantaneous, while copying it takes forever. You’re just changing a pointer, not duplicating all the data.

The basic syntax is brain-dead simple:

mv source target

You give it something to move and a place to put it. Let’s break down what it can actually do.

Moving a single file

This is the most straightforward use case. You’re taking one file and putting it somewhere else. The target can be a directory or a new filename.

# Move report.pdf into the 'archives' directory
mv report.pdf ./archives/

# Rename draft.txt to final_masterpiece.txt
mv draft.txt final_masterpiece.txt

# Move AND rename in one go: take notes.txt from here and put it in projects/ as ideas.md
mv notes.txt projects/ideas.md

The key thing to remember: if the target is an existing directory, the file is moved into it. If the target doesn’t exist or isn’t a directory, mv assumes you want to rename the source to that target.

Moving multiple files

You can toss a whole list of files at mv, but there’s a critical rule: the last argument must be the destination directory. It has to exist. mv isn’t psychic; it can’t guess you meant to create a new file called file1 file2 file3.

# Move all .log files into the log_backups directory
mv error.log debug.log system.log /var/log_backups/

# This will fail spectacularly because 'new_name' is not a directory
mv file1.txt file2.txt new_name  # WRONG

The -i and -n flags: Your safety nets

Here’s where we get to the designers’ “questionable choice.” By default, mv is silent and brutally overwrites any existing file at the target location. No warning. No confirmation. Just… poof, your original file is gone. This is the number one cause of rookie (and sometimes veteran) panic.

Thankfully, they gave us a couple of flags to prevent this self-own.

  • -i (interactive): Makes mv ask for confirmation before overwriting anything. This is a fantastic habit to get into.

    $ mv -i important.doc old_backup.doc
mv: overwrite 'old_backup.doc'?
# Type 'y' for yes or 'n' for absolutely not

  • -n (no clobber): The quieter, more passive-aggressive safety net. It simply refuses to overwrite an existing file. No questions asked; it just skips the move.

    # If old_backup.doc exists, this command does nothing for that file.
mv -n important.doc old_backup.doc

My strong advice? If you’re doing anything more dangerous than moving files to a new, empty directory, use mv -i. Or, even better, get in the habit of using ls on the target directory first to see what’s in there. Paranoia is a virtue at the command line.

The -v flag: For the anxious among us

While not a safety feature, the -v (verbose) flag is incredibly useful. It tells mv to actually speak up and report what it’s doing. No more guessing if your command worked as expected.

$ mv -v ~/Downloads/weird_file.iso ./projects/
'/home/you/Downloads/weird_file.iso' -> './projects/weird_file.iso'

When moves become copies (and why it matters)

Remember how I said mv usually just changes pointers? The exception is when you move a file across filesystem boundaries. If you try to mv a file from your ext4 root partition to an NTFS USB drive, the system can’t just change a pointer. The two filesystems speak different languages.

In this case, mv silently does the right thing: it copies the data to the new location on the target filesystem and then deletes the original. This means it’s no longer instantaneous, and it also means you need enough free space on the target drive for the copy to complete. If the copy succeeds but the delete fails, you could end up with two copies. It’s rare, but it’s a good reason to always sync your drives before yanking them out.

You can’t mv a directory (well, you can)

A final note: everything we’ve discussed applies to directories, too. mv is wonderfully consistent. Moving a directory works exactly the same way. The same overwrite rules apply, so be extra careful when your target is a directory that already exists. You don’t want to accidentally merge folders or overwrite something crucial. When in doubt, ls the target first. Trust me.