Re: [gentoo-dev] [RFC] QA bashism check on portage
On Wednesday 25 February 2009 23:45:41 Mike Frysinger wrote: cut i recall it being incorrect in some cases (it checked for what dash supports, not what POSIX supports), but that was a while ago, so maybe my experience is dated at this point. otherwise, integrating it sounds sane to me, and if we can push fixes back to debian, even better. It does not fail, the problem is that some construct works only on some shells or systems (for example type and kill -HUP warnings). Maybe we should add a getopt flag (-q for example) to mask that types of warnings, or maybe we should (for Gentoo/Alt) adapt files to be (almost) POSIX compliant (so command -v instead of type, kill -s HUP instead of kill -HUP, and go on) a repoman check on files in files/ would be useful as well i'd think Yes, as supplementary check -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] QA bashism check on portage
On Thursday 26 February 2009 04:27:44 Timothy Redaelli wrote: On Wednesday 25 February 2009 23:45:41 Mike Frysinger wrote: i recall it being incorrect in some cases (it checked for what dash supports, not what POSIX supports), but that was a while ago, so maybe my experience is dated at this point. otherwise, integrating it sounds sane to me, and if we can push fixes back to debian, even better. It does not fail, the problem is that some construct works only on some shells or systems (for example type and kill -HUP warnings). Maybe we should add a getopt flag (-q for example) to mask that types of warnings, or maybe we should (for Gentoo/Alt) adapt files to be (almost) POSIX compliant (so command -v instead of type, kill -s HUP instead of kill -HUP, and go on) i'm totally not following. we were talking about POSIX shell syntax, but now you're talking about utilities as well ? -mike
Re: [gentoo-dev] [RFC] QA bashism check on portage
On Thursday 26 February 2009 06:33:17 Timothy Redaelli wrote: On Thursday 26 February 2009 10:32:52 you wrote: i'm totally not following. we were talking about POSIX shell syntax, but now you're talking about utilities as well ? I'm talking about checkbashism.pl checks and btw type is a builtin and kill can also be a builtin it doesnt matter if they're builtins, they still need to follow POSIX kill -HUP `cat /var/run/mDNSResponderPosix.pid` /dev/null possible bashism in /etc/init.d/mDNSResponderPosix line 35 (kill -[0-9] or -[A-Z]): kill -HUP POSIX states that `kill [-signal_name]` is valid syntax. if the shell doesnt support it, then it isnt POSIX complaint and therefore it sucks and is not worth consideration. -mike
[gentoo-dev] [RFC] QA bashism check on portage
Hi, what do you think about checking for bashism on install_qa_check? Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first line. I think checkbashisms.pl [1] could be a good start point. [1] http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] QA bashism check on portage
On Wednesday 25 February 2009 11:10:01 Timothy Redaelli wrote: what do you think about checking for bashism on install_qa_check? Obviously only for scripts with #!/bin/sh and #!/sbin/runscript as first line. I think checkbashisms.pl [1] could be a good start point. [1] http://svn.debian.org/viewsvn/devscripts/trunk/scripts/checkbashisms.pl i recall it being incorrect in some cases (it checked for what dash supports, not what POSIX supports), but that was a while ago, so maybe my experience is dated at this point. otherwise, integrating it sounds sane to me, and if we can push fixes back to debian, even better. a repoman check on files in files/ would be useful as well i'd think -mike
