[PATCH] Fix typos and shell for MacOSX packaging scripts

[Dirk Hohndel]

Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> writes:
>> I thought, for example, that the whole
>>
>> > -if test "x$GTK_DEBUG_LAUNCHER" != x; then
>>
>> thing was indeed because some shells don't deal with empty strings
>> when doing comparisons.
>
> Alright.  I think I see what you mean.  Though, who in his right mind
> would attempt to build subsurface using a stoneage non-posix shell?

Ok, we are NOT targeting stone age non-posix shells.

> In that particular case, these forms (all posix) are equivalent:
>
> 	if test -n "$GTK_DEBUG_LAUNCHER"; then
> 	if test "$GTK_DEBUG_LAUNCHER"; then
> 	if [ "$GTK_DEBUG_LAUNCHER" ]; then
>
> The later is the one I would use throughout. 

Cool

>> But let's face it - we don't want to go totally overboard with this.
>> What I'm aiming for is a well documented, easily readable shell script
>> that is reasonably POSIX compliant and will survive if a different POSIX
>> shell ends up being used.
>
> By saying "reasonably POSIX", do you mean more or less posix? 

Sorry, bad phrasing on my part. I meant to say "reasonable shell that is
POSIX compliant".

> Because,
> the way I think of it, it can be either posix-complient or non-posix.
> AFAIK, bsd uses ash and they work really hard to enforce posix.  Why on
> earth would Apple find it appropriate to try to do something different?

Who knows what Apple will do, but we'll cross that bridge if we ever get
there.

>> I'm inclined to take your commits as they are after I had a chance to
>> test them on my Mac (only have access to my Linux system right this
>> minute).
>
> Good.  Than I can go on, I presume ;)

Yes, please.

> This bashism:
>
> 	${L:0:2}
>
> has always bothered me, so I'll try to get that out of the way, next.
> Debian has a useful utility: checkbashisms.  Perl script.  No
> odd dependencies.  Very useful.  I use it alot.
>
> What do:
>
> 	APPLECOLLATION
> 	APPLELOCALE
>
> show ona a MacOSX, anyway?  Worst case ;)  The standard replacement is an
> 'expr' fork, but I'd very much like to avoid that.  When possible, to use
> shell builtin parameter expansion instead.

They don't show up in my environment at all.

APPLELOCALE appears to be a typical local string if set (something like
"en_US")

I cannot find a reference of what APPLECOLLATION might hold - this is
copied straight from the gtk-mac-bundler example :-(

/D