So, Im working in a UNIX environment and I noticed that inside my working directory, which is miles miles away from my UNIX home, there is a ~.

Now, once in the past, I did rm -rf ~ from my working directory and ended up erasing my home directory completely and had to involve IT.

I do not want to do it again. At the same time, I want to know

  1. Why is ~ created in my working directory? Is it a faulty finger slip while saving (:w! but what happens is :w~ ?!!)

  2. Before checking in, there is a script that looks for extra files or folders that p4 is not aware so def this ~ might cause an issue. So how can I remove the ~ from my working directory and at the same time not erase my home?

I do have a backup command called del that I use instead of rm -rf. It just places stuff in a temporary location. I could use that and get rid of the ~. But I'm more interested in knowing why this happens, and how I can remove it?

| improve this question | | | | |
  • Normally, the shell replace ~ at the beginning of a path with your home directory. Use the full path /home/yourUserName/~ to access the directory called ~. – jofel Jun 25 '14 at 22:17
  • And ~otheruser/file can be used to reference other user's home directories, for the sake of completeness. – godlygeek Jun 25 '14 at 22:24
  • Looks like a prank! – Xolve Jun 30 '14 at 18:37

Either quote it:

rm -i '~'
rm -i "~"
rm -i \~

Or reference it by a path, instead of just a basename:

rm -i ./~
rm -i /path/to/~

Note that, despite being a funny-looking single character name, this is conceptually no different than if you had created a file named SOME$PATH by doing

touch 'SOME$PATH'

And tried to remove it by doing:


(Warning: the variable SOME$PATH is not quoted for the sake of the example here. Normally it would be enclosed in quotes 'SOME$PATH' )

In both cases, the shell is expanding the name you give, and you need to prevent that.

Also: Don't use rm -rf to remove a file! The entire purpose for rm -r is to tell rm it's OK to remove directories. If you don't want to accidentally remove entire directories while trying to remove files, don't habitually pass -r!

| improve this answer | | | | |
  • 12
    I just tested this. :w~ in vim did create a file called ~. rm ~ returned cannot remove /home/seth it is a directory. rm "~" did remove the file. Just to underline don't pass -rf automatically. – Seth Jun 25 '14 at 22:27
  • 4
    +1 for recommending to omit violent options by default. This is akin to doing kill -9 by default, which I've seen. – Celada Jun 26 '14 at 0:24
  • I see that the example rm -i $FOO intentionally does not quote the variable for the sake of the example, but still: showing a shell example involving rm and an unquoted variable as argument is VERY BAD, uh, sorry, independent of context. I'm sure that can even be prooven :) I'll add some note - but maybe you could change the example, a little? – Volker Siegel Jun 26 '14 at 0:37
  • @VolkerSiegel, Point taken - I took part of your edit, but the footnote seemed a bit too heavy handed. I also switched to a variable name even less likely to cause problems - most people don't have a file named SOME/bin:/usr/bin anywhere on their filesystem. :) – godlygeek Jun 26 '14 at 1:30
  • Yes, looks good! (I was almost going to answer: What? Heavy-handed? Did you ever experience a real quoting problem in your live? ;) Just somewhat desparate about the amount of wrong shell examples out there, in general... Hey, it's hard to understand even without wrong examples! ) – Volker Siegel Jun 26 '14 at 1:37

The tilde when used alone in the context of ls ~ will list your home dir as ~ is a shortcut to your home dir. If you did ls ~brown then you will list the contents of brown's home dir.

VIM, unless told otherwise, will create a back-up copy of a changed file: myFile myFile~.

This behavior is good as it creates a back-up but if you don't want it, add to you .vimrc file: set no backup (which I just accessed with vi ~/.vimrc).

And of course as others said, if you have a file called ~ then simply escape the char as \~

me 217 % vi this      (saved as :w~)
me 218 % ls
this  ~
me 219 % cat \~
me 220 % \rm \~
me 221 % ls
| improve this answer | | | | |

This could be effected by mistypes. If your TERM=xterm config is anything like mine, then practically every function key on your keyboard will send escape sequences like...

infocmp -1 | grep -n \~ | tail -n3
138:    kich1=\E[2~,
141:    knp=\E[6~,
142:    kpp=\E[5~,

More than half of the output of infocmp -1 contains ~tilde escapes on my machine - and I'm at a loss to understand what most of them do. I do know that zsh at least actually eats the escaped portion of the string in most cases - and leaves only the ~tilde.

For example, typing echo then <space> then F6 and <return> prints...


The actual escape sequence sent is...


Interestingly, there are other of these escape sequences which contain > characters.

infocmp -1 | grep \>

Those are commonly used escapes - reset and initialization strings. It's not difficult to imagine that a dropped keyboard or button-smash of some kind when an interactive shell is awaiting input could result in randomly truncated ~ files occurring throughout your file-system. At least, it does occasionally crop up on mine.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.