solaris fixes #164

wants to merge 4 commits into


None yet
3 participants

Gibheer commented Nov 23, 2011

I made some fixes so that gitflow can be used on solaris too. I tested it on openindiana.


nvie commented Nov 23, 2011

I'm not too keen of changing sh to bash for all environments. At the same time, I'm not too big of a fan of making more OS-specific hacks. What exactly are you running into when using sh instead of bash?

Futhermore, I'd like to avoid the solaris Makefile target, for the same reason. Instead, we could change the Makefile to support overrides of the INSTALL variable, so you could use the following to install on platforms where install is not available:

$ make INSTALL=ginstall install

Gibheer commented Nov 23, 2011

I tried git flow and i got many error messages like
/usr/local/bin/git-flow[70]: local: not found [No such file or directory]
When I tried to figure out, what local was, I could only find hints on bash so I changed it to bash and it worked.

I tried it in a small script after your message and it does not work on openindiana. But i was surprised, when it worked on freebsd, so i think, the shell on solaris is just too old (even the $() syntax does not work there).

I did the change on the makefile because I thought, it was the normal way. So I will change it to what you said works better.

Thank you for your help. And thank you for building this project :D


nvie commented Nov 23, 2011

I'm not inclined to take into account shells that are that old, really. gitflow already runs on many platforms and we feel the pain of that "platform-independence" every day in this shell script. For example, we cannot depend on bash being available on the target platform, just as much as we cannot depend on a version of sh that knows of the local keyword.

Gibheer commented Nov 23, 2011

Yeah, now I understand be reason behind using sh.

Would it be an option to ask /usr/bin/env for a shell? This is avaiable on every system and can look through the path for a fitting sh. On my system, there is even a link on sh to bash, so that would work for me too.

waddles commented Sep 3, 2012

+1 to using /usr/bin/env to find bash, it is definitely the preferred way. If you write something with functionality that is only found in bash and not an original bourne shell, you really need to specify that it runs under bash and not sh.

As an aside, I found I had to put /usr/xpg4/bin earlier in my $PATH so it uses the POSIX compatible version of egrep, not the Solaris default egrep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment