[PATCH] Fix typos and shell for MacOSX packaging scripts

Dirk Hohndel dirk at hohndel.org
Wed Oct 3 12:42:49 PDT 2012

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. 


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

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

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


More information about the subsurface mailing list