Re: [PLUG] Interactive rm

[bergman@merctech.com]

In the message dated: Wed, 01 Feb 2006 13:01:36 EST,
The pithy ruminations from Andrew Libby on 
<Re: [PLUG] Interactive rm> were:
=> 
=> Michael C. Toren wrote:
=> 

	[SNIP!]

=> >
=> >Creating an alias won't solve Art's problem, which is using the "-i" flag
=> >when rm is passed multiple files, but not using "-i" when only a single
=> >file is specified -- rather, an alias will use "-i" in every case.  One
=> >possible solution is to create a bash function which determines how many
=> >arguments it was passed:
=> >
=> >	rm()
=> >	{
=> >	    if [ $# -lt 2 ]
=> >	    then /bin/rm $*
=> >	    else /bin/rm -i $*
=> >	    fi
=> >	}
=> >
=> >This works for the majority of cases:
=> >
=> >	[mct@ellesmere ~]$ touch foo bar baz
=> >	[mct@ellesmere ~]$ rm foo
=> >	[mct@ellesmere ~]$ rm bar baz
=> >	/bin/rm: remove `bar'? y
=> >	/bin/rm: remove `baz'? y
=> >  
=> >
=> 
=> This is a very cool solution!  A question I have is what art intended for
=> the following cases:
=> 
=> rm file1 file2
=> rm file*
=> rm file.???
=> 
=> My bet is that the first case, he'd not want interactive rm, but in the
=> second and third
=> he would.   Am I correct in my supposition that wild cards are expanded
=> prior to
=> invocation of the shell function?  That would make this desire

Yes, the shell expands wildcards, if possible.

=> impossible, wouldn't it?
=> Anyone have any idea how we might expand this solution to accommodate
=> non-wild card
=> multi parameter invocations or rm?

I don't understand the question. The shell function given above correctly 
handles non-wildcard multi-parameter invocations of rm. Whether there's the 
expansion of a wildcard by the shell, or the user supplies multiple parameters, 
the shell function should correctly count the number of arguments.



Now, there's another problem with the shell function approach...race conditions.

For example:
	[time A]:	/path/to/dir contains files named "a" "b" "c"

	[time B]:	user calls the rm function with the argument "d*"

	[time B']: 	within the shell function, the test is performed:
				if [ $# -lt 2 ]
			this test succeeds, as there are no files beginning with
			the letter "d"

	[time C]:	the following files are created:
				/path/to/dir/do_not_ever_remove_this_vital_file
				/path/to/dir/destruction_of_all_human_life_will_occur_if_this_is_removed

 	[time C']:	the shell function calls the rm command, as:
				/bin/rm $*

	[time D]:	the shell expands the argument to rm "d*"

	[time E]:	the end of all western civilization as we know it


Yes, this looks very unlikely and obscure, however, I've run into very similar 
problems in cluster failovers, where the software made assumptions that if it 
was running on the active node, then certain files would always exist...when 
the files weren't there, and the wildcard characters were passed around 
literally, to be expanded later in the code than was intended, all hell broke 
loose.

Just something to think about...

Mark

=> -- 
=> Andrew Libby                                  
=> alibby@philadelphiariders.com
=> http://philadelphiariders.com/
=> Motorcycle Enthusiasm, Fishtown Style
=> 
=> 1999 SV650
=> 1999 Laverda 750S
=> 1996 BMWR1100RS
=> 1981 Moto Guzzi CX100 (in Lemans I clothing)

----
Mark Bergman
bergman@merctech.com
Seeking a Unix/Linux sysadmin position local to Philadelphia or via telecommuting

http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug