LinuxQuestions.org - Why is my safe_rm shell script deleting after I test that safe

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Why is my safe_rm shell script deleting after I test that safe_rm isn't being deleted? (https://www.linuxquestions.org/questions/linux-newbie-8/why-is-my-safe_rm-shell-script-deleting-after-i-test-that-safe_rm-isn%27t-being-deleted-4175612320/)

Why is my safe_rm shell script deleting after I test that safe_rm isn't being deleted?

Hello Everyone!

I am creating a bash script to ensure that the file that the user creates is being "deleted" (its moving the file to the recycle bin which is $HOME/deleted). In my attached code, steps 1-6 run the way that it is supposed to run. However, when I reach my last part to test that the file being "deleted" isn't safe_rm, it shows the error message that I created and I gave it the correct exit status but my whole script deletes. Luckily I have copies of it but I am wondering why its doing it. I've tried using readlinks but it appears to work for loops and my code isn't supposed to have any. I've attached a copy of my script. The issue that I am having is at #7. Am I supposed to add wild cards to my script to prevent deletion? Any suggestions and tips are greatly appreciated. Thank you very much everyone!

Code:

#!/bin/bash





##2.

create_directory(){

if [ ! -d $HOME/deleted ] ;

        then

                mkdir $HOME/deleted

fi

}

create_directory



## This will create a deleted directory in the home directory. If the the directory exist then the script will announce it.



##3.



fileName=$1



## This provides an argument for a filename.



##4.

error_checking(){



fileName=$1

if [ ! -e $1 ] ;

then

        echo "safe_rm :cannot remove '$1' : No such file or directory"

        exit 1 #will stop the script if there is no file or directory

elif [ $# -eq 0 ] ;

then

        echo "safe_rm : cannot remove '$1' : Missing operand"

        exit 1

elif [ -d $1 ] ;

then

        echo "safe_rm : cannot remove '$1' : This is a directory"

        exit 1



fi

}



error_checking $1

## This will test the three error conditions based on the file given.



##5 and ##6.



movefile_inode (){



fileName=$1

inode=$(ls -i $1 | cut -d" " -f1)

touch $HOME/.restore.info

readlink=$HOME/deleted

path=$(readlink -m $1)

echo "$1_$inode:$path">> $HOME/.restore.info ## This appends the file with its inode and absolute path into the hidden file .restore.info in the $HOME directory.

mv $1 $HOME/deleted/$1_$inode ##This will move the file into the recycle bin and the format will be filename_inode.

}



movefile_inode $1



##7.

final_testing(){



fileName=$1

if [ "$1"== *'safe_rm' ] ;

then

        echo "Attempting to delete safe_rm - operation aborted"

        exit 1

fi

}



final_testing $1

It doesn't delete it after the "final_testing" test. It deletes it before it does that test.

Also, I notice a syntax error:

Code:

if [ "$1"== *'safe_rm' ] ;

needs a space before the "==".

Thank you for your feedback. I rearranged the order and my script stopped deleting. Thank you!

Have $1 in quotes if it's in command arguments, to prevent it from expansion.

Code:

movefile_inode "$1"

Also [ ] is a command

Code:

if [ ! -e "$1" ]

The == operator and glob pattern is only defined for [[ ]] that is not a command.

Code:

if [[ $1 == *'safe_rm' ]]

A variable assignment is not a command

Code:

fileName=$1

inode=$(ls -i "$1" | cut -d" " -f1)

If in doubt, put in quotes!
$1_ is not clear, better have

Code:

echo "${1}_$inode:$path"

Code:

echo "$1"_"$inode:$path"

do not use the keyword readlink as a variable

Quote:

Originally Posted by pan64 (Post 5750507)

do not use the keyword readlink as a variable

The name "readlink" is not a shell keyword, at least not in bash. It just happens to be one of a huge number of available external commands. Using it as a variable name isn't going to confuse the shell.

Quote:

Originally Posted by rknichols (Post 5750577)

Yes, I was not precise enough. It won't confuse the shell, but the user....
sooner or later

Quote:

Originally Posted by rknichols (Post 5750577)

Quote:

Originally Posted by pan64 (Post 5750599)

Yes, I was not precise enough. It won't confuse the shell, but the user....
sooner or later

The same could be said for any of the other thousands of names in $PATH directories that someone happened to be familiar with as a command name.