On Sunday 29 August 2010 00:44:21 Ron Guerin wrote:
> Chris Knadle wrote:
> > Yeah another interesting thing I've been running into concerning bash
> > scripts are "Bash-isms"; because the default shell in Debian these days
> > for package installation and /bin/sh (used for Cronjobs) is Dash -- not
> > Bash.
> >
> > http://en.wikipedia.org/wiki/Debian_Almquist_shell
> >
> > There are some interesting differences, such as the lack of the "=="
> > test, lack of "for" loops, etc.
> >
> > http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf
>
> I can see the sense of a smaller default shell intended for use by the
> system at least, although I have to say from the back seat here, I find
> myself wondering what was saved at the cost of so many differences from
> Bash. Not everything in Bash is bloat, and I guess I fail to appreciate
> why enforcing POSIX compatibility in scripts to be run on a Debian
> system is raised to such a priority over the kind of compatibility I can
> appreciate. One thing I am good about though is I *always* put
> #!/bin/bash in when I write a Bash script. Probably some of the scripts
> I write are compatible with with the /bin/sh du jour, but I don't need
> to know, I write these for myself.
Unfortunately I recently found out the hard way that putting #!/bin/bash at
the top of a script *DOES NOT* mean that's the interpreter that will always
be used. When running a script either via cron or 'at', there's this
interesting warning you'll get about using '/bin/sh' as the interpreter. If
/bin/sh happens to be Dash, then /Dash/ is what's going to be used to run the
script, regardless of what the first line in the script says.
I found this out when running a "gpg-refresher" script I created:
gpg-refresher
-------------------------------------------
#!/bin/bash
# Check for internet connectivity, silently skip update if check fails
ping -c 3 www.yahoo.com > /dev/null
if [ "$?" -eq "0" ]; then
# Online, so do GPG key refresh
gpg --refresh-keys -o - 2>&1 | fgrep -v -e "requesting key" \
-e " not changed" -e "Total number processed: " -e " unchanged: " \
-e " keys processed so far" -e " next trustdb check due at" \
| egrep -v -e "refreshing .* keys from " \
| -e "key .* not found on keyserver" \
-e "^gpg: depth: .*" -e " trust model$"
fi
-------------------------------------------
If you change the line:
if [ "$?" -eq "0" ]; then
and make it:
if [ "$?" == "0" ]; then
then the script will work when called interactively, but will fail with an
error when called via 'at' or a cron job. Oops.
As for what this 'gpg-refresher' script does -- it emails the user locally
when there are updates on gpg keys in the users' keyring. It's meant to be
run from cron about once a day or so.
I've learned a lot more about GnuPG recently.
> > From the above document I just found out there's a program
> > 'checkbashisms' that helps with these things that's part of the
> > 'devscripts' package.
>
> I had at one point, read the New Maintainer's Guide and the Debian
> Policy Manual. Must have been seven years ago though. My recollection
> though is that while there was plenty of things one had to do in a text
> editor, there were a lot of tools that helped create everything from the
> directory structure and its contents, to the actual package itself.
The only talk at DebConf10 that touched on Debian packaging in a generic sense
concerned a discussion about changes in Debian Policy and the Policy Manual.
Apparently the New Maintainers Guide and the Debian Policy Manual *are* the
method that people are supposed to use to learn how to do Debian packaging.
These documents are very long, and they're getting longer. I've yet to fully
get through them both (at least I tried). But unfortunately there are a lot
of details within them concerning subtleties in packaging. The manuals are
hard to read because it's difficult to have any associated memory about the
contents without any experience context to go with it. In other words, you
can't remember the stuff because you haven't built Debian packages yet to
understand what the manuals are talking about.
Because of this most people making a package use the 'debhelper' scripts, and
then run the 'lintian' checker on the resulting package to see if there are
obvious errors with the package. This is not the intended use for 'lintian',
however. And a full lintian check on a Debian package apparently takes about
a half an hour to run. There was a lot of discussion during the Debian Policy
talk about how to get lintian to deal with packages containing Python or Java
programs, as these really require a separate subset of checks run on them that
I believe currently are not being done. There was some discussion about how
to handle adding these checks, and whether creating a modular design where the
package author could choose "lintian modules" to run would be helpful or
whether this would just get too complicated. No decision was made during the
talk, and they re-found that there was a Debian Policy mailing list where they
could discuss it further.
I didn't go to the "Java packaging nightmare" talk, but the name alone lets me
know that there are some interesting problems packaging Java apps, and there
were separate talks about Perl and Python too.
> Become a Debian Developer. You can sponsor my package! ;)
>
> - Ron
Okay, here I have good news. I probably won't become a Debian Developer
within the next year -- however I now have a long list of Debian Developers
that I personally spoke with, more than one of which stated that they'd be
willing to sponsor a package for me when I needed one. And as a whole I found
DD's to be surprisingly friendly.
There's also a "Debian Mentors" site meant to help with exactly this situation
-- where you're the developer and you'd like your package uploaded, but you're
not a Debian Developer and thus can't upload.
http://mentors.debian.net/
So there are resources available to get your package uploaded once it's ready.
As far as I'm concerned the "hard part" at this point is learning how to
package up the software to make it ready to be uploaded. This is also where
"Debian Mentors" can probably be helpful, as there's likely an IRC channel
where you can discuss packaging details.
And obviously I'm willing to help you in any way that I can. ;-)
-- Chris
--
Chris Knadle
[email protected]
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) MHVLS Auditorium
Sep 1 - BOINC
Oct 6 - Creating Firefox Extensions
Nov 3 - Bug Labs
