Re: Defect in XCU rm

[Larry Dwyer <yyyyyyyyyyy@xxxxxx>]

This change would preclude a useful extension to UNIX.

There might be an implementation that allowed pathname extensions to 
specify disk volumes or remote volumes.  Say,  a prefix to pathname 
designates a volume, like, perhaps, "<letter>:". My search path may be, for 
example, "C:/mksnt/mks".  My current working directory may be "A:/".  I 
should be allowed to do "rm /" and have the expected result.

The same argument applies if I want to have network extensions to the path, 
such as "//<remote_machine_name>".

                Cheers,
                Larry

At 10:14 AM 3/11/2003, yyyyyyyyy@xxxxxxx wrote:
>         Defect report from : John Beck , Sun Microsystems
>
> (Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
>
> @ page 820 line 31681-31683 section rm comment {JTB-1}
>
> Problem:
>
> Defect code :  3. Clarification required
>
> An occasional user mistake, with devastating consequences, is to
> write a shell script with a line such as:
>         rm -rf $VARIABLE1/$VARIABLE2
> or
>         rm -rf /$VARIABLE1
> without verifying that either variable is set, which can lead to
>         rm -rf /
> being the resulting command.  Since there is no plausible
> circumstance under which this is the desired behavior, it seems
> reasonable to disallow this.  Such a safeguard would, however,
> violate the current specification.
>
> Action:
>
> Either extend the exceptions for . and .. on the noted lines
> to list / as well, or specify that the behavior of rm if an
> operand resolves to / is undefined.