[EMAIL PROTECTED] on 2000.07.27 19:39:41
>> Note that I have considered the alternatives of:
>> CLEARTOOL:="//c/Program Files/Rational/ClearCase/bin/cleartool"
>>
>> and:
>> CLEARTOOL:=//c/Program\ Files/Rational/ClearCase/bin/cleartool
>>
>> The former has a problem when using $(CLEARTOOL) within another set of double
>> quotes. The latter has a problem when passing $(CLEARTOOL) to another
script.
>> However, wrapping the call in double quotes makes the makefile less legible.
>
>Well you can bow out of the problem with the second approach and simply
>claim it's up to any script to deal properly with its arguments. That
>is in fact the only 100% successful way to avoid outlawing such
>filenames. Dealing with arbitrary arguments in a POSIX shell script is
>difficult sometimes, but far from impossible, and it's good programming
>practice regardless of what environment the script might run in.
After I posted, I realised that both of the above definitions have both of the
above problems.
In the end, I think you're right. I'm proposing to outlaw such pathnames (at
least for the tools that matter) mostly due to the crappage that can occur when
using makefile functions (thanks to Wolfgang Laun for pointing that out).
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
