Re: Defect in XCU rm

[Jim Zepeda <yyyyyyyyyy@xxxxxxxxxxxxxxxxx>]

I have sat and read all of the discussion on this.

While it would be nice to have the operating system check for 
programming errors,
that would be totally impractical.

I would suggest that the way to deal with this defect report would be, 
at most, to
simply document that the script programmer should test for null 
variables at critical
points in their script.

Changing the current specified behavior to unspecified or implementation 
specific
would not be good. There are valid reasons for leaving portions of the 
standard
as unspecified or implementation specific. In most cases the application 
developer
hates this since it hinders their ability to write portable code. With 
the current state
of the standard there is a clear behavior and way to test if either 
/$VARIABLE1
or $VARIABLE1/$VARIABLE2 evaluates to "/" before the command is executed.

I will also point out that an operating system vendor could add a flag 
to the command
to implement the behavior requested here. As long as the flag is not 
documented
in the standard there is no conflict with conformance. If such a flag 
becomes popular
and is implemented in most implementations, the flag would probably find 
its way
into the standard.

Jim Zepeda

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.
>
>