At a command line prompt in a shell, you can use a command like
rm -i *~
to delete from the current directory those files whose names end in ~. The
-i flag tells
rm (the “remove” command) to inquire before deleting. If you are not familiar with using shell commands, keep the
-i flag in there until you are familiar, because minor errors like a space in the wrong place can have major consequences.
To list the files that will be affected in the current directory, you can say any of the following.
ls -l *~
ls -la *~
To make a particular directory be the current working directory, use the
cd command and the name of the directory. For example, if you deduce that your backup disk is mounted at
/media/xyz (either via the
cat /proc/mounts command mentioned in another answer, or more directly via command
mount with no parameters, or via
df) you would say
cd /media/xyz to make the top level directory of the backup drive the current working directory.
rm -i *~ command affects files only in the current directory, and does not affect subdirectories. To treat indefinite levels of directories, use the
find approach given in another answer. However, if you know how deeply directories are nested, and the level is shallow, you might use a command like
rm -i *~ */*~ */*/*~
which as shown would delete ~ files in the current directory, its direct subdirectories, and their direct subdirectories.
Edit 2: As gertvdijk mentions in a comment, the clumsy
rm shown in previous edit can be streamlined by using
** Bash 4.0+ recursive shell globbing (1). After the command
shopt -s globstar has been entered, free-standing instances of
** will glob recursively, ie will stand for all names in current directory and its descendants. (
shopt -u globstar turns
globstar off, but since one is unlikely to type
** by mistake it seems reasonable to leave it turned on in interactive shells.) Thus, after
shopt -s globstar, the command
rm -i **/*~ will remove ~ files in current directory and its descendants. Note that if such filenames add up to more than a few million characters, the command line may become too long for bash to handle. The
find approach does not have that particular limitation.