On 14.09.2016 16:44, Eric Blake wrote: > 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)
Oops, big sorry! I must have been confused by the German spelling of that name :-( >>>>> +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. Well, /bin/bash is also not really portable ... I've seen systems in the past where bash was installed in another directory or not at all... Anyway, FYI, I've found two more nice ways to check for POSIX compliance: - There is a program called checkbashisms which reports bash related style - "posh" is a very minimalistic POSIX compliant shell which hardly supports any of the bash extras And indeed, both pointed me to another bashism in my script: The "function" keyword is not portable and should be avoided... oh well. Not sure whether I really should do a v3 of my patch, convert it to python or just give up the idea of releasing such a script to the public... Thomas
signature.asc
Description: OpenPGP digital signature
