White spaces in filenames

Recently I faced an issue in tranferring a file from Windows to UNIX host. Unlike UNIX, windows as usual accepts white spaces in filenames. A file called "Copy of sqlnet.log" was transferred to a UNIX host and when tried to execute commands like cat or more, it reported the usual error of "No such file or directory" since a single file name is treated as three different filenames due to the white spaces.

But when tried with double quotes around the filename, works just fine.

UNIX-$> more "Copy of sqlnet.log" or cat "Copy of sqlnet.log"

Now, removing such a file is the most daunting task. A simple 'rm Cop*' takes the file out of your server but takes other files from the directory starting with a 'Cop' as a complement.


Method-1

Conventional method of removing a file.

UNIX-$> rm "Copy of sqlnet.log"

Removal of such a file using double quotes around it works good,as shown above. But just to innovate something new and flaunt about it to my colleagues I used the below method.


Method-2

Get the inode number of the file by a simple 'ls -li', this shows an extra field in the long listing of files. The first field of such a command's output is the inode number. To get an explanation about inode, follow my earlier post Inodes and Links

UNIX-$> ls -li

121604 -rwxr-xr-x 1 oracle oracle 96 Feb 21 18:00 oratab_bkup.txt
121621 -rw-rw-r-- 1 oracle oracle 576 Feb 21 23:55 db_check_ora_home.parm
121557 -rw-rw-r-- 1 oracle oracle 4244 Feb 22 01:00 cron_backup.txt
121638 -rw-r--r-- 1 oracle oracle 868 Feb 22 11:28 Copy of sqlnet.log

Now, use the 'find' command to remove the file with '-inum' and '-exec' arguments. -inum argument expects a file's/directory's inode number to be passed.

UNIX-$> find ./ -inum "121638" -exec rm {} ;

This method precisely fits the following anomaly. Imagine a directory full of files with extension '.dbf', User unknowingly makes a mistake and issues a command 'ls -ltr > *.dbf' to list all the files in the long format.

The output of the above command would create a file called '*.dbf' and the contents are long listing of all the '.dbf' files. Now, would anyone be really foolish enough to try 'rm *.dbf' ??? , the next thing you know is he/she is out of the Organisation (Chuckles!!!) . Well a good backup strategy should save the day .

Though the existence of such a file using up a few bytes is not a big deal, but it gives you an awkward look of your files, an entry as *.dbf. All you need to do to have a pleasant look of your '.dbf' files is to get the inode number of the file '*.dbf' and take it down.

UNIX-$> ls -li

1603 -rwxr-xr-x 1 oracle oracle 96 Feb 21 18:00 *.dbf
1628 -rw-rw-r-- 1 oracle oracle 576 Feb 21 23:55 three.dbf
1637 -rw-rw-r-- 1 oracle oracle 4244 Feb 22 01:00 two.dbf
1630 -rw-r--r-- 1 oracle oracle 868 Feb 22 11:28 one.dbf

UNIX-$> find ./ -inum "1603" -exec rm {} ;

Now, the file "*.dbf" is gone forever and a long listing of *.dbf only shows the actual files as shown below.

UNIX-$> ls -li

1628 -rw-rw-r-- 1 oracle oracle 576 Feb 21 23:55 three.dbf
1637 -rw-rw-r-- 1 oracle oracle 4244 Feb 22 01:00 two.dbf
1630 -rw-r--r-- 1 oracle oracle 868 Feb 22 11:28 one.dbf