Shell Programming and Scripting

While fully seconding what all the others are reasoning about: did you consider defining a shell function rm in which you could do what you want to "customize" the command?

\rm escapes an alias and a function.
Or is there an assumption that a stupid user cannot type a \ character?

Hi mohtashims,
I agree with everything bakunin, RudiC, and MadeInGermany said.

An alias won't keep users from invoking /bin/rm -f .... A shell function won't keep users from invoking /bin/rm -f ....

But, of course, there is something you can do. Replace /bin/rm with your own version of rm that generates an error message whenever anyone tries to use the -f option. You will get exactly what you want. System maintenance procedures may stop working. System boot procedures may stop working. User shell scripts may stop working. So what; you have made sure that no user is able to avoid an error message when removing a temp file that might not have been created in the first place. Why should they want to do that when they can rewrite their scripts so they will work on your perfected operating system even through their scripts work perfectly on every other POSIX-conforming system in the world.

After modifying rm, are you going to rewrite the manual pages for rm and any utility on your system that might invoke rm with a -f option as well? Or, do you just plan to tell your users that the implementation-supplied man pages are broken and that you have "fixed" the system to work more safely? If third-party software doesn't work on your system because you have fixed rm, are you going to tell those third-party suppliers to "fix" their code to work on your system; or are you going to tell users that they just shouldn't buy from those suppliers because the programmers who wrote their code used an option that you have decided is too dangerous to be allowed to be used on your "improved" system.

And, if a user wants to remove a read-only file from your system, obviously users on your system should learn to use the much safer sequence of commands:

Code:

chmod 644 file
/bin/rm file

instead of the dangerous code:

Code:

rm -f file

After all, typing two or three times as much isn't much more likely to introduce typographic errors is it? And, running two utilities instead of one and accessing a file twice instead of once won't affect system performance, will it?

Or, maybe you want your version of /bin/rm to always behave as if the -i option is in effect. Of course, if you do that, you won't be able to remove any files in a non-interactive script anymore, but so what? Why should anybody be allowed to remove any file without interactively confirming that they really wanted to remove those files? After all, there is no reason why anyone should be allowed to run a cron job that removes temporary files it uses, is there?

And, what about the yes utility? Are you going to remove it to so users can't use:

Code:

yes|rm -i /dir/* > /dev/null

(which they will quickly learn to do since the -f option is no longer available). And, after you remove the yes utility, are you going to fix all of the shells on your system so your users can't use a while loop with echo or printf to simulate the yes utility? Are you going to get rid of the C and C++ compilers so users can't write their own rm utilities and their own yes utilities? And, are you going to remove the chmod, find, rmdir, and unlink utilities from your system so they can't replace:

Code:

rm -rf file...

with the MUCH less efficient:

Code:

find file... ! -type d -exec chmod 600 {} \; -exec unlink {} \;
find file... -type d -depth -exsec chmod 600 {} \; -exec rmdir {} +

? After all, UNIX, Linux, and BSD systems are known for providing lots of ways to do some pretty common things (like remove a file).

If you could fix alias to work the way you want it to, would you remove unalias from all of the shells on your system so users can't get rid of your fix? And, would you fix alias to that an alias for rm can't be redefined?

If you treat your users like foolish children who can't be trusted to use standard operating system features, you will quickly learn that foolish children can turn into rebellious teenagers. And those rebellious teenagers will find ways to get around your restrictions until they are able to move out of your realm of control and work on an unmodified system where they can do their jobs without having to work around your "system improvements". (And don't think that your foolish and rebellious children won't talk to each other and pass around ways to get around your restrictions.)

So, yes, there are lots of things you can try to disable the rm -f option. But, you can't keep users from getting around anything you do. And, you can't keep users from accidentally removing a file (or thousands of files) if they aren't careful typing commands into a shell and when they are responding to prompts issued by every utility they invoke.

You will eventually find out that if you modify your system to become foolproof, a new breed of fool will start using your system.

So true Don, I went once long ago through that sort of bad experience... its not rm but cp I had to rewrite (not my idea but I was the system analyst at the time and was asked by IT director...) the idea was it checked how many copies on the system and allow developpers to only have 5 as we were short regularly of disk space... I lived a true nightmare as I awakened the monkey's curiosity in them... It taught me UNIX was in someway beautifully simple and to work as it does, has to stay "simple" and standard to the way it was designed... I then changed attitude altogether, I educated the staffl, show people what/how to and treat them as grown up, the more they know the less trouble/work you have later...

I couldn't stop laughing reading the last few comments and I get the point that it is not feasible to impose the default behaviour of the commands.

Anyways ... can you help me with few commands with flags as examples that override each other like -f overrides -i for rm command ?

I'm very happy to hear that you were laughing. That means you'll remember this discussion.

It is common practice any time a utility has mutually exclusive behaviors specified by a pair of options to use the behavior specified by the last one of those options found on the command line. But as always, there are exceptions. The standards seldom explicitly state that the last mutually exclusive option "shall be used" and instead state that the default behavior is undefined if a user specifies more than one mutually exclusive option unless the description of that utility explicitly overrides the default. One case where the standard always specifies that the last one shall be used is the -H, -L, and -P options that appear on many utilities that process symbolic links (such as cd, chgrp, chmod, chown, cp, etc.). In all of these cases the last specified option of these three is required to be used and any previous occurrences of these three options must be ignored by the system (just like the -f and -i rm options we have been discussing in this thread).

Although i need to study and understand this i did try the cp command and it works like you said.

Code:

bash-4.3$ cd /tmp                                                                                                                                             
bash-4.3$ ls -ltr                                                                                                                                             
total 0                                                                                                                                                       
drwxr-xr-x 3 19912 19912 16 Feb 10 01:35 Hello                                                                                                                
lrwxrwxrwx 1 19912 19912 17 Feb 10 01:36 logs -> Hello/www/output/
bash-4.3$ cd -PL logs                                                                                                                                         
bash-4.3$ pwd                                                                                                                                                 
/tmp/logs 
bash-4.3$ cd /tmp
bash-4.3$ cd -LP logs                                                                                                                                         
bash-4.3$ pwd                                                                                                                                                 
/tmp/Hello/www/output