Re: GNUstep make Solaris 2.8 glitch

[Richard Frith-Macdonald]

On Tuesday, June 25, 2002, at 04:49 AM, Adam Fedor wrote:

> Nicola Pero wrote:
> > > Hi Nicola,
> > >
> > > hope you're fine. I just got my hands on a (slow) Solaris 2.8 box. 
> > > First thing I did was install a fresh-from-cvs GNUstep on that box. 
> > > Then I compiled the ED* frameworks and noticed a build failure that I 
> > > didn't expect. It turns out that in target build-framework-dirs of 
> > > Instance/framework.make all [ ! -L foo ] tests fail due to Solaris' 
> > > /bin/sh not offering the -L test (failure is: "test: expected 
> > > argument missing"). Instead, I had to rewrite all occurences with  
> > > /bin/test ! -L foo (which works). Not sure how one could rewrite that 
> > > easily and still remain portable, probably by introducing something 
> > > like platform.make in the NeXT makefile packages?
> > Hi - I'm still not sure how to fix this problem - we do have platform
> > specific configurations, but I'm not sure it would help with this.
> > Maybe someone else has a good suggestion.
>
> I think 'test' is generally more portable than '[ ... ]' (In fact it's 
> already used in one place in framework.make.) Is there any reason why 
> it should not be used?

I always thought that 'test' and '[' were *defined* to be two names for 
the same program in posix.
I guess solaris must break that.

The -k, -L, -nt, -ot, -ef, -a and -o operators, plus the use of 
parentheses to group operators together, are all extensions to the POSIX 
standard.

The -k, -L, -nt, -ot, and -ef operators are extensions to the X/OPEN 
standard.

So, while parenthesses and  -a and -o extensions are probably universal, 
it looks like the others are not.

It may be that the only portable way to test for symbolic links would be 
to process the output
of 'ls -l' ... something like "ls -l $1 | grep -q '^l'"