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

[Stephen Gran]

This one time, at band camp, Raphael Geissert said:
> On 18/03/2008, Stephen Gran <sgran at debian.org> 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:

steve at hadrian:~$ cat t.sh
#!/bin/sh

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

b=$(foo)
echo $b

steve at hadrian:~$ 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 |
|  : :' :                                        sgran at debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20080318/6c6d7e0a/attachment.pgp