Rm -f shouldn't do this, should it?



  • For safety reasons, I add an alias to my .bashrc file that looks like this: 

    alias rm='rm -i'

    This causes the "rm: remove filename.ext?" dialog to be displayed when removing files.  If you're sure of what you want to delete, you can override this by typing

    rm -f filename.ext

    Watch what happens to me when I do it, though.  ^C is when I CTRL C-ed to end the program to avoid hitting 'y' 150 times.

    cmd> alias rm='rm -i'
    cmd> alias
    alias cp='cp -i'
    alias ll='ls -l'
    alias mv='mv -i'
    alias rm='rm -i'
    cmd> rm -f *.AADC
    rm: remove B100000D20070905T2151.AADC (yes/no)? ^C
    cmd> rm -f -f -f *.AADC
    rm: remove B100000D20070905T2151.AADC (yes/no)? ^C
    cmd> alias rm=rm
    cmd> rm -f *.AADC
    cmd>

    Anyone ever experience this before?  I haven't had this issue before today.  For the record, this is Solaris 8. 



  • Doesn't happen to me, this is Slackware 12.

    renan@illusion:~$ alias rm='rm -i'
    renan@illusion:~$ alias
    alias c='cd'
    alias cls='clear'
    alias l='ls'
    alias ll='ls -la'
    alias lr='ls -lR'
    alias ls='ls --color=auto'
    alias rm='rm -i'
    renan@illusion:~$ touch bozo.bar bozs.bar
    renan@illusion:~$ rm -f *.bar
    renan@illusion:~$ ls -la *.bar
    ls: impossível acessar *.bar: Arquivo ou diretório não encontrado

    Looks like a bug in the Solaris implementation of 'rm'.




  • I would suggest just downloading GNU's coreutils and compiling that (that's where you get rm iirc) then just copy over it's rm. But you are correct, rm -f should override the -i flag.


    http://unixhelp.ed.ac.uk/CGI/man-cgi?rm



  • yes | rm *.AADC

     

    More seriously, /bin/rm *.AADC

     



  • Don't EVER alias things this way!

     

    Think of what happens if....

     

    (1)  Your .bashrc file gets deleted.

    (2)  Your .bashrc file is on a file server that hiccups.

     (3)  You come over to my computer and do a "rm *.c"  expecting it to ask you about each one.

     
    (4)  You somehow end up in the Bourne or Korn shells that don't read up .bashrc.

     

    Bad vibes....

     


     



  • GNU rm  will use whichever of -i and -f  comes *later*.
    (Advantage:  you can have rm aliased to "rm -i", and still be able to "rm -f" something;  disadvantage is that if you have a file named "-f" in your directory, you could loose data)

    Solaris rm probably has -i always override -f   (In my view, that is safer!)

     May I suggest the following tips:


    i)When deleting files with   "-" at the start, use "./" .   For example,   "rm -f ./-iamafiletobedeleted"

    ii)Always keep rm aliased to "rm -i" for safety. When you want the default behaviour, use  /bin/rm, rather than unaliasing it.

    iii)I suggest you have a script for safe deletion.  For example,
    ~/bin/cn:
    #!/bin/bash
    /bin/mv -f --backup=numbered -- "$@" /home/me/.local/share/Trash/files

    Then get into the habit of using cn  (trashCaN) instead of rm.



  • Hey, a loop! Interesting.

     I don't know much about this, but when I had an account on Solaris I had rm aliased to '\rm -i'.

    Supposedly, the backslash would make it skip aliases. HTH

     
    EDIT: forget it. I should have read the post before saying anything..  *bonk*



  • Again, I should really read the posts before saying anything

    What I meant to say is: \rm -f should work for skipping the alias.



  • [quote user="RichardNeill"]
    i)When deleting files with   "-" at the start, use "./" .   For example,   "rm -f ./-iamafiletobedeleted"
    [/quote]

    Agreed.

    @RichardNeill said:

    iii)I suggest you have a script for safe deletion.  For example,
    ~/bin/cn:
    #!/bin/bash
    /bin/mv -f --backup=numbered -- "$@" /home/me/.local/share/Trash/files

    Then get into the habit of using cn  (trashCaN) instead of rm.



    For me this gives a false sense of security. You will have a "send to trash can" command on the command line, but it won't be any good if you delete the file from within any other program.

    From The Unix Haters Handbook, page 23 (or 63 on the PDF version I have):

    "This (Changing rm's behaviour) has made (the author) somewhat incautious about deleting files, since of course I can always undelete them.

    This has made me somewhat incautious about deleting files, since of course I can always undelete them. Well, no I can’t. The Delete File command in Emacs doesn’t work this way (...) This, of course, is because the undeletion protocol is not part of the operating system’s model of files (...) As a result, I have to keep two separate concepts in my head, “deleting” a file and “rm’ing” it, and remind myself of which of the two of them I am actually performing when my head says to my hands “delete it.”"

    But this is my $0.02...


  • @Ancient_Hacker said:

    Don't EVER alias things this way!

    Think of what happens if....

    (1)  Your .bashrc file gets deleted.
    (2)  Your .bashrc file is on a file server that hiccups.
    (3)  You come over to my computer and do a "rm *.c"  expecting it to ask you about each one.
    (4)  You somehow end up in the Bourne or Korn shells that don't read up .bashrc.

     Bad vibes....

    That ancient wisdom seems to have faded into obscurity nowadays, when aliasing "rm" et al seems to be more or less the standard. Perhaps they make sense in some rare cases, these aliases, like when you have full control over all of the systems you will ever use.

    I guess those of us who insist of taking the route of caution and not rely on this kind of aliasing will just have to avoid letting the newbies into our systems... :) Actually, maybe they would be better off with a restricted shell.



  • @Renan_S2 said:


    For me this gives a false sense of security. You will have a "send to trash can" command on the command line, but it won't be any good if you delete the file from within any other program.

    "This (Changing rm's behaviour) has made (the author) somewhat incautious about deleting files, since of course I can always undelete them.

    This has made me somewhat incautious about deleting files, since of course I can always undelete them. Well, no I can’t. The Delete File command in Emacs doesn’t work this way (...) This, of course, is because the undeletion protocol is not part of the operating system’s model of files (...) As a result, I have to keep two separate concepts in my head, “deleting” a file and “rm’ing” it, and remind myself of which of the two of them I am actually performing when my head says to my hands “delete it.”"

    Of course, the answer to this is to have automatic nightly backups. (There is some very clever trickery you can do with rsync and hard links, but that's another story).  You'll never make things totally foolproof - not even with something like libsafe. The best rule I have is:

    1)All file manipulations are done from the shell (except occasionally, using GUI programs such as konqueror, or sometimes with eg OpenOffice -> Save-As) 

    2)When I want to delete a file, I always use "cn" (as above). I almost never use "rm".

    3)If I really want to permanently kill it, I use rm (usually after doing  "cd ~/trash" first!). The alias of rm -> "rm -i" provides a second level of stupidity-protection. 

     In the end, you have to go with what works for you - find a habit and stick to it.  



  • As long as you aren't in the habit of using rm -i to interactively select which files you do and don't want to delete, then I don't think the usual alias is that big of a risk. Only use a wildcard with rm if you really mean it.



  • Basically, I'm always overriding the -i with -f anyways.  The alias is for the other users of the system who use the same functional login as me. 

    Having this alias is standard for every login if you install Fedora Core, by the way.



  • Wow.   I can't remember the last time I accidently deleted a file with rm.  I don't use any alias tricks like that either... I guess I'm just paranoid enough to triple check what I type before hitting enter.

     
    It also doesn't hurt that I have a BackupPC server running a monthly rotation of full and incremental backups... :) 

     I have had programs delete huge swaths of files by not checking for an empty path variable, thus deleting from the root of the program.   That has made me double check all variables that get fed to deletion routines... run them through verification methods to make sure they are sane.
     


Log in to reply