On 09/14/2016 05:35 AM, Thomas Huth wrote: > Erik, It's Eric, but don't sweat it (you're not the first, and probably not the last, to typo names)
>>>> +while [ $# -ge 1 ]; do >>>> + case "$1" in >>>> + -s) START="$2" ; shift ;; >>> >>> POSIX recommends that short options with arguments be parseable both as >>> '-s foo' and '-sfoo'. I don't care that you aren't POSIX compliant, but >>> using getopt(1) or getopts(1) may make it easier to comply. > > OK. After googling a little bit, it sounds like getopts is the way to > go, e.g. http://mywiki.wooledge.org/BashFAQ/035#getopts says that getopt > should not be used. getopts(1) is POSIX, but not universally present. I _think_ your script was portable to /bin/sh, but it may be easier to write by relying on bashisms and changing line one to /bin/bash, at which point we know getopts is present. > > [...] >>>> +if [ "x$BROWSER" != "x" ]; then >>>> + BUGBROWSER = "$BROWSER" >>>> +elif which xdg-open > /dev/null; then >>> >>> 'which' is not portable; it may not exist. It looks like you are trying >>> to redirect to /dev/null to avoid shell messages when it does not exist, >>> but to properly do that, you'd need: > > I rather wanted to simply suppress the output of which. > > Is there a POSIX compliant way to check whether a program is available > in $PATH ? 'type' and 'command' are both supposed to be able to do it according to PSOIX, although there are probably portability pitfalls with both of them; again, using /bin/bash can avoid some of the concerns about portabilities. Sadly, both of those names are hard to grep for, so I can't quickly determine if we have existing shell scripts in qemu.git that have an example to copy from. > >> Your various comments above are a great example of why IMHO any script that >> is longer than 1 line shouldn't be written in shell. Instead pick python >> or any other scripting language which isn't rammed full of portability >> problems and shockingly awful error handling facilities as shell is. > > I fully agree with you that writing portable shell-scripts is a pain, > but unfortunately my python-fu is even worse than my shell-script-fu ... > well, maybe it's now time to improve it ;-) > > Thomas > > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
