Closed mmairle closed 6 years ago
Thanks for the issue.
Could you give me more information on the system you're using the script on? I think it's a difference in how which
reports failures.
For example, on my old Citrix Xen server, it would report no storcli64
, which would mean your fix wouldn't work. However, Ubuntu 16 (and probably lots more modern OS's) would simply return a null string. My guess is that's what you're running into.
Perhaps I could check the return code as well...
Oh, and I should at this piece of code was really a last resort. May I ask, what directory is your binary in?
We're using the script on a 64 bit Proxmox VE 5.0 system (which is based upon Debian), so we're having exactly the null string issue you know from Ubuntu. I actually didn't know that there were some OS out there which report something like "no foo".
Our storcli64 is installed in /usr/sbin. Anyway, thanks for the script!
Ya, that makes sense then.
I can put together a more robust solution. You could also have symlinked /usr/sbin/storcli64
to /usr/local/bin/storcli64
. I'll see what I can come up with. Probably a combination of return code, string parsing, and adding more folders to the search algorithm.
Thanks again!
I decided to just change the way I look for the binary instead of worrying about difference in the which
return. BTW, the latest Citrix XenServer still returns no ....found
instead of an empty string.
I'm simply splitting up $PATH
and adding them to the list of places to search for. This is the same thing that which
does, except I don't have to scrape the output or return code.
If you still have issues, add the directory you have storcli
in to the $PATH
. E.g., you can set that separately in /etc/crontab
.
Thanks again for the issue!
I changed line 110 with the condition to the following in order to make it work for us: