[PATCH] Fix typos and shell for MacOSX packaging scripts
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
> 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
> Good. Than I can go on, I presume ;)
> This bashism:
> 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