NOTICE for all package maintainers with faulty post-install scripts

Matthias Andree matthias.andree@gmx.de
Thu Aug 12 14:50:00 GMT 2010


Am 12.08.2010 16:35, schrieb Andrew Schulman:
>> On Thu, Aug 12, 2010 at 09:56:49AM -0400, Andrew Schulman wrote:
>> >> Thanks to Jon Turney's recent patch we've discovered that many
>> >> post-install packages were previously failing silently. 
>> >
>> >Failing silently... so what is the preferred protocol in case a
>> >post-install script fails?  Emit a message to stderr, which will be caught
>> >and shown to the user?
>> 
>> There is apparently a disconnect here.  setup.exe now lets you know if a
>> script fails.  Scripts are not supposed to fail.  Some scripts are
>> routinely failing and should be fixed.
>> 
>> If your script fails for a valid reason then of course exiting with a
>> non-zero status is the way to go.  That is what the new dialog box was
>> intended to catch.
>> 
>> If one of your scripts does fail then you should work out why with the
>> affected user and take steps to make sure that it doesn't fail.
> 
> Let me be sure first that I understand the new functionality.  By "fail" we
> mean exiting with a non-zero status, correct?

Either that, or (hopefully) exit with a signal.

> So when a postinstall or
> preremove script exits non-zero, the user will be alerted of that fact?

There's an error popup, but I don't know which details it reports other than
pointing to setup.log.full or thereabouts.

> And maybe output to stderr and/or stdout provided, in the hope that it will
> help to diagnose the problem?
> 
> I may just be confused by your phrase "failing silently".  I'm just trying

"failing silently" means that it was logged to some file but not alerted through
the GUI, so that many users were unaware that the postinstall script had failed
somehow.

> to figure out how if at all I need to adjust my postinstall/preremove
> scripts to check for non-zero exit statuses and try to provide useful
> output about them.  Most of those scripts are short, but some contain
> multiple commands, any of which could fail for any number of reasons that
> are hard to predict.  Once a problem is well-known I can add code to check
> for it and provide a useful message, but until then, either silence or a
> possibly not very enlightening error message is going to be the usual mode
> of failure.

My primary concern is that packagers don't just write ":", "true", or "exit 0"
at the end of their postinstall scripts to mask/hide the failure.

My secondary concern is general quality of shell scripts (this is not relating
to Cygwin postinstall scripts, which I've never looked at).

Few people seem to be capable of writing solid shell scripts, because many
people often just copy & paste snippets from Google without understanding the
details.  Shell scripts are a nuisance to some, and proper training material is
hard to find on the web (there's a truckload of mediocre and incomplete stuff
though), and so I often see unquoted variable expansions (that break on blanks
in filenames already or empty variables), people treating

	(a) "foo && bar" and

	(b) "if foo ; then bar ; fi"

as synonymous (abusively!) to accomodate their convenience, when in fact the
exit semantics are different; "if" eats failures of its immediate condition
command, whereas "foo && " will emit the failure status.

Note that some older shell implementations (including older Almqvist and BSD
shells) got some of these semantics wrong (meaning violating POSIX).

-- 
Matthias Andree



More information about the Cygwin-apps mailing list