Re: [Qemu-devel] [PATCH v2] scripts: Add a script to check for bug URLs in the git log

[Eric Blake]

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