[PATCH] Fix typos and shell for MacOSX packaging scripts

Cristian Ionescu-Idbohrn cristian.ionescu-idbohrn at axis.com
Wed Oct 3 12:12:58 PDT 2012


On Tue, 2 Oct 2012, Dirk Hohndel wrote:
> Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> writes:
> >
> > Here's an incipient cleanup attempt, maybe controversial.  Should I
> > continue?
>
> In general I like where you are taking this. I /think/ you did the right
> thing (haven't looked at every single line, yet) and did the formatting
> change in its own commit that changed NOTHING ELSE but just the
> formatting.

Good, as that was my intention.

> On the other changes you have some of them where I'm not sure if your
> replacement code is actually the more portable one, but then I am
> definitely not shell scripting expert.
>
> 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?

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.  Forget autoconf & Co ;)
Don't copy/paste that.  They seem to have another agenda, not that I know
what agenda that might be ;)

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

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

> Thanks for working on this, Cristian!

No problem.  Anytime.  I like this stuff.  It's fun.  More to come...

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.


Cheers,

-- 
Cristian


More information about the subsurface mailing list