Backup: mysqldump path (osX)

You should edit the $PATH in your ~/.bash_profile

Moya:hosting adrian$ cat ~/.bash_profile
export PATH=/Applications/MAMP/bin/php5/bin:/Applications/MAMP/bin/apache2/bin:/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH

Indeed, we assume that the binaries are in the PATH, otherwise fix the PATH on your machine.

IIRC, /usr/local/bin does not exist on Mac OS X by default (hence it is not part of $PATH), but the MySQL installer (et al) will create the directory if absent.

A generalized (OS agnostic) solution to this problem would simply be to let the backup script check $PATH for /usr/local/bin, and if absent, add it:

  if `echo $PATH | grep -vqE "(^|:)/usr/local/bin(:|$)"`; then export PATH="/usr/local/bin:${PATH}"; fi

sudo ln -s /usr/local/bin/mysqldump /usr/bin/
:-)

but yeah, adding /usr/local/bin to $PATH is nicer. Note, as webserver should run as a daemon (not you) it should be done system-wide, /etc/bashrc not just ~/.bash_profile
Not sure if that affects MAMP, but it's better anyway.

That's just silly: if proper tools are not available to aegir, it will *not* work. The environment needs to be properly configured. We can't have exceptions for every platform out there, that's what $PATH is for: it points to where your stuff is. If it's not configured properly, it's not up to aegir to fix that, it's up to the operating system and its maintainer.

Adding /usr/local/bin to the PATH is not "platform agnostic": it assumes /usr/local exists and has some meaning. In Debian, it's useless and can even be harmful, for example.

@anarcat: On the contrary, there is a good argument to be made that scripts should never rely on $PATH being set to anything useful. My previously suggested check is a concession to those who would like to rely on $PATH anyhow; it will make the Aegir script more robust, and prevent this question from arising again. Your concern about the existence of the directory is valid, so here is an updated version which doesn’t touch $PATH unless the directory actually exists:

  if [ -d /usr/local/bin/ ] && `echo $PATH | grep -vqE "(^|:)/usr/local/bin(:|$)"`; then export PATH="/usr/local/bin:${PATH}"; fi

What *is* that argument that scripts should not rely on $PATH?

Arguably, we sometimes do use explicit paths but only because the actual apachectl binary varies in *name* (apachectl vs apache2ctl), not in path. Furthermore, the problem is solved differently: the path is autodetected on install and editable by the adminsitrator.

Hacking around the $PATH is not the right way. If we want to give power to the user, we should let complete control over the complete binary path.

$PATH is too volatile and unreliable. Seasoned UNIX scripters eschew it; trusting it can really wreck havoc (scripts failing under various conditions, or unpredictably in the future). Relying on $PATH does not make for robust code.

But this may be a situation where you have to choose one devil or another, and really don’t have a good alternative. Guess POSIX still has a ways to go.

So far this is the only argument i've seen against $PATH: it's too brittle (ie. not robust). On the contrary, in my opinion, hardcoding the path to the binary makes code unnecessary complicated and is *also* brittle, as the path may change between platforms. It *forces* porters to actually patch the code to make it work, instead of just setting up a proper environment.

The only reason I would see why we would want to change that path is because the actual binary name changes, like apache requires it, because it's sometimes apachectl, apache2ctl or whatever. We *need* to let the user choose the binary because it *might* be ambiguous. We don't do that because we can't find apachectl, we can figure that out ourselves if necessary.

I do not think that mysqldump would change name. I have never seen such an instance.

I do respect your position however and if you feel we absolutely need to bypass the PATH, it should be done in the server verification step, and this issue should be reopened (otherwise it's being ignored right now).

Well i really don’t like hacking away at $PATH any more than you do. But relying on $PATH makes for fragile code. I concur that the mysqldump name is likely to be pretty static. So it would seem the best approach would be to determine mysqldump’s location in the server verification step, as you suggest. My recommendation would be to reopen the issue. YMMV.