Bug#471422: [Pkg-lirc-maint] Bug#471422: Bug#471422: lirc: bashism in /bin/sh script

2008-03-18 Thread Stephen Gran
This one time, at band camp, Raphael Geissert said:
 On 18/03/2008, Stephen Gran [EMAIL PROTECTED] wrote:
  This one time, at band camp, Raphael Geissert said:
Hello maintainer,
   
While performing an archive wide checkbashisms (from the 'devscripts' 
  package)
check I've found your package containing a /bin/sh script making
use of a bashism.
   
checkbashisms' output:
 possible bashism in ./etc/init.d/lirc line 15 (local foo=bar):
 local MODULES_MISSING=false
 possible bashism in ./etc/init.d/lirc line 45 (local foo=bar):
 local ARGS=$*
 
   Please don't mass bugfile without reading what you're reporting.  The
   use of local is non-POSIX, but supported by dash.  Policy 10.4 allows
   the ability to use local in the ways that the init script uses it.
 
 Policy requires the shell interpreter to support 'local foo', which is
 different from 'local foo=bar' and not required by policy, hence
 reopening the bug report (but lowering the severity and removing it
 from the dash as /bin/sh RG).

No, this is what policy says:

  *  local to create a scoped variable must be supported; however,
 local may or may not preserve the variable value from an outer
 scope and may or may not support arguments more complex than simple
 variables.

This does not say you must predeclare the variable, and only later do an
assignment (why would we make such a rule?  Does any shell behave like
that?)  It says that you can't assume complex data types like arrays,
and you may not assume it will preserve the value from an outer scope.
Declaration vs. initialization is not addressed.  I see the code snippet,
but I draw different conclusions from you when the code snippet is
compared to the paragraph above it - I take it to mean that you can't
do more interesting things with local.

Finally, 10.4 also says:

You may wish to restrict your script to SUSv3 features plus the above
set when possible so that it may use /bin/sh as its interpreter. If your
script works with dash (originally called ash), it probably complies
with the above requirements, but if you are in doubt, use /bin/bash.

so:

[EMAIL PROTECTED]:~$ cat t.sh
#!/bin/sh

foo () {
  local a=bar
  echo $a
}

b=$(foo)
echo $b

[EMAIL PROTECTED]:~$ dash -x t.sh 
+ foo
+ local a=bar
+ echo bar
+ b=bar
+ echo bar
bar

Seems like dash supports it to me, which lends pretty strong evidence to
my argument, doesn't it?  On the other hand, I'd be willing to be proven
wrong.  If you can go back to the discussion about allowing local in the
list of exceptions and find the normative email that says you can use
local, but not do an assignment at the time of declaration, I'll happily
admit you're right.

Deal?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Bug#471422: [Pkg-lirc-maint] Bug#471422: Bug#471422: lirc: bashism in /bin/sh script

2008-03-18 Thread Stefan Lippers-Hollmann
tags 471422 + pending
thanks

On Dienstag, 18. März 2008, Raphael Geissert wrote: 
[...]
 Policy requires the shell interpreter to support 'local foo', which is
 different from 'local foo=bar' and not required by policy, hence
 reopening the bug report (but lowering the severity and removing it
 from the dash as /bin/sh RG).

Agreed, the current use of local in lirc's initscript is neither covered by
SUSv3, the exceptions from SUSv3 described in Debian policy 10.4, nor 
actually providing any vital functionality in said initscript, therefore it 
has been fixed in svn:

http://lists.alioth.debian.org/pipermail/pkg-lirc-changes/2008-March/000392.html

Given that dash, as the proposed successor of bash as /bin/sh, does support
'local foo=bar' constructs (just like busybox, ksh, pdksh and ksh - posh 
fails, as expected), it doesn't seem to justify immediate action and will 
be fixed by the next regular upload.

Regards
Stefan Lippers-Hollmann


signature.asc
Description: This is a digitally signed message part.