How to install a custom permanent postinstall handler?

Dirk Fassbender dirk.fassbender@arcor.de
Sun Apr 3 11:47:00 GMT 2016


Am 03.04.2016 um 08:24 schrieb Achim Gratz:
> Yaakov Selkowitz writes:
>> I am not in favour of /bin/sh being alternatives-able.
> I'd posit that it should not be bash then and somwone else might
> reasonably want a different /bin/sh, perhaps even bash.  Which is
> exactly why the alternatives system exists.
>
>> The *proper* course of action is to use the shebang for the script
>> interpreter you require, i.e. /bin/dash.
> It's perfectly OK to use /bin/sh (I'd even recommend it) if all you want
> is a POSIX shell.  You shouldn't be trying to use local then, but that's
> another story (*).
>
> (*) http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script
>
>
> Regards,
> Achim.
Hello,

please have in mind that the /bin/sh shell is the system default shell.
On Unix systems many initialisation scripts are executed during start up 
with the /bin/sh in a way that a shebang line is not used. So these 
scripts are executed with the standard /bin/sh every time.
Because AIX and HP-UX are using a KSH (version 88), SOLARIS is using a 
Bourne shell version and Linux systems can use different shell types ( 
mostly DASH, BASH to my knowledge) it is difficult to write scripts to 
use during system initialization in a portable way.

This comes from the way how the different shells behave then invoked as 
/bin/sh. See the following section from the bash man page.

    If*bash*is invoked with the name*sh*, it tries to mimic the startup 
behavior of historical versions
    of*sh*as closely as possible, while conforming to the POSIX standard 
as well. When invoked as
    an interactive login shell, or a non-interactive shell with 
the*--login*option, it first attempts to read
    and execute commands from//etc/profile/ 
<file://etc/profile>and/~/.profile/ <file://%7E/.profile>, in that 
order. The*--noprofile*option may
    be used to inhibit this behavior. When invoked as an interactive 
shell with the name*sh*,*bash*looks
    for the variable*ENV*,expands its value if it is defined, and uses 
the expanded value as the name of
    a file to read and execute. Since a shell invoked as*sh*does not 
attempt to read and execute commands
    from any other startup files, the*--rcfile*option has no effect. A 
non-interactive shell invoked with the
    name*sh*does not attempt to read any other startup files. When 
invoked as*sh*,*bash*enters/posix/mode
    after the startup files are read.

KSH behave in a similar way.

So it is not easy to write portable scripts for the standard shell 
/bin/sh between different systems and the exchange of the standard shell 
needs a check for all scripts, that uses a shebang line /bin/sh or are 
use during system initialisation.

I personally prefer to use a shebang line set to the shell type used 
(ksh, bash, dash). This is more portable for different system types.

For putting the /bin/sh under alternatives control on cygwin there must 
be some preparations.
There are several postinstall and preremove scripts without a shebang 
line or with  a shebang line /bin/sh or /usr/bin/sh. Are all of these 
scripts written to run correctly with a bash and dash invoked ?

Regards
Dirk Fassbender

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list