dunno if that is still the case for newer versions, but I just stumbled upon strange messages like
host.domain:/opt/omni/lbin/.util: 388: [: unexpected operator named "host.domain [/opt/omni/lbin/.util: 388: [: unexpected operator]".
Backup mode is changed to full.
in a 6.11 installation. Turns out .util is using == instead of = in test(1) invocations (through '['), which is a bashism that neither works in POSIX test(1) nor in the dash builtin. If you happen to run into the same thing (most likely after upgrading some Debian DA client to a newer version of the distribution, allowing /bin/sh to be symlinked to dash instead of bash in the process), the easiest way to fix it is to change the interpreter header of .util into #!/bin/bash explicitely. Works here. Of course fixing all the == might also help, but I've not checked they are the only bashisms in that script.
yes, it is true. But after this change the update or check of this client no work. Reason is that response from client's bash sending no correct value for type of components. The same situation is on DP 7.01 with actual patches.
It is possible change to /bin/sh for update and after it change back to /bin/bash for backup.
I've found in my system that /bin/sh was a symbolic link to /bin/dash. I changed that symbolic link to /bin/bash and in this manner I didn't get /opt/omni/lbin/.util "unexpected ..." error AND agent installation and installation check worked fine. In .util file I left #!/bin/sh "declaration" .
of course you can "fix" this issue by going back to the state that brought us these bashisms in the first place. The correct way to do this, in Debian and derivates, is
so the system actually knows and stores your preference for future updates/upgrades.
There are situations where it makes sense to do this (specifically development machines with vast build environments like OpenEmbedded where trying to fix every bashism is akin to fighting windmills), but on servers where everything works according to plan except for a single script in the backup agent, I prefer to fix the latter (and even more, have it fixed by HP for the future). ISTR that 8.x now claims "official Debian 7.x DA support", which (given the DA worked correctly apart from some cosmetics like said bashism and complaints that Kernel 3.x could not possibly be Linux) may mean just that - being able to deal properly with any SysV/POSIX compatible Bourne shell playing the system shell role.