How to install a custom permanent postinstall handler?

How to install a custom permanent postinstall handler?

[Andrey Repin]

Greetings, All!

Couple of my scripts rely on ASH/DASH functionality that is not present in
BASH. (Namely "local -".)
To amend that, I make a symlink /bin/sh = /bin/dash .
But every time bash update, it overwrite the link.
So… How would I go about creating a handler that would restore the parity?
Will making a script /etc/postinstall be enough, or some additional magic is
necessary?


-- 
With best regards,
Andrey Repin
Friday, April 1, 2016 23:48:54

Sorry for my terrible english...

Re: How to install a custom permanent postinstall handler?

[Achim Gratz]

Andrey Repin writes:
> Couple of my scripts rely on ASH/DASH functionality that is not present in
> BASH. (Namely "local -".)
> To amend that, I make a symlink /bin/sh = /bin/dash .
> But every time bash update, it overwrite the link.

I think the correct course of action would be to put /bin/sh under
control of the alternatives system.

> So… How would I go about creating a handler that would restore the parity?
> Will making a script /etc/postinstall be enough, or some additional magic is
> necessary?

There is.  You will want to run this script in postinstall stratum z as
a perpetual one, so the name of the script needs to start with "zp_"
(preferrably with a .dash suffix, too).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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

Re: How to install a custom permanent postinstall handler?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On 04/02/2016 03:21 AM, Achim Gratz wrote:
> Andrey Repin writes:
>> Couple of my scripts rely on ASH/DASH functionality that is not present in
>> BASH. (Namely "local -".)
>> To amend that, I make a symlink /bin/sh = /bin/dash .
>> But every time bash update, it overwrite the link.
> 
> I think the correct course of action would be to put /bin/sh under
> control of the alternatives system.

Since I maintain both dash and bash, I'm game for setting up /bin/sh as
an alternative. However, I've never targeted the alternatives system
before as a package maintainer; any advice on docs or an example that I
could copy from?  I would probably make the defaults give bash higher
priority over dash, but with the alternatives in place, it would be easy
for a local user to swap the priorities on their system; I'd probably
also want to provide a convenience script to make swapping default sh an
easier task than users having to actually call directly into the
alternatives system.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: How to install a custom permanent postinstall handler?

[Achim Gratz]

Eric Blake writes:
> Since I maintain both dash and bash, I'm game for setting up /bin/sh as
> an alternative. However, I've never targeted the alternatives system
> before as a package maintainer; any advice on docs or an example that I
> could copy from?  I would probably make the defaults give bash higher
> priority over dash, but with the alternatives in place, it would be easy
> for a local user to swap the priorities on their system; I'd probably
> also want to provide a convenience script to make swapping default sh an
> easier task than users having to actually call directly into the
> alternatives system.

You could look at Emacs.  It has all the components you ask about for
making either emacs-nox, emacs-w32 or emacs-x11 the default (only the
latter two have helper scripts).

man alternatives

The alternatives package is currently orphaned and should probably get
an update to use hardlinks or copies for DLL, then it would become
usable for switching between BLAS/LAPACK implementations.  I have that
on my list of things to update for some time now, but if somebody beats
me to it I would not complain (it's in the utils directory for Debian
dpkg if you're wondering).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
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

Re: How to install a custom permanent postinstall handler?

[Yaakov Selkowitz]

On 2016-04-02 04:21, Achim Gratz wrote:
> Andrey Repin writes:
>> Couple of my scripts rely on ASH/DASH functionality that is not present in
>> BASH. (Namely "local -".)
>> To amend that, I make a symlink /bin/sh = /bin/dash .
>> But every time bash update, it overwrite the link.
>
> I think the correct course of action would be to put /bin/sh under
> control of the alternatives system.

I am not in favour of /bin/sh being alternatives-able.  The *proper* 
course of action is to use the shebang for the script interpreter you 
require, i.e. /bin/dash.

-- 
Yaakov

--
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

Re: How to install a custom permanent postinstall handler?

[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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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

Re: How to install a custom permanent postinstall handler?

[Dirk Fassbender]

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

Re: How to install a custom permanent postinstall handler?

[Achim Gratz]

Dirk Fassbender writes:
> 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.

Whatever is under /bin/sh is supposed to be POSIX compliant.  If you
make use of your knowledge of what shell this actually is (dash, posh,
bash, busybox, etc.), then you're by definition not interested in having
a portable script and could just as easily use a different shebang line.

> 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.

You're specifying a shell type and only have to deal with portability
among the versions of that shell.  But you're explicitly saying your
script (possibly) isn't POSIX compatible.

> 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 ?

The shebang line isn't even looked at for the postinstall scripts.  The
suffix is what determines which shell gets to run the scripts.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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

Re: How to install a custom permanent postinstall handler?

[Yaakov Selkowitz]

On 2016-04-03 01:24, Achim Gratz wrote:
> 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.

Unfortunately the reality is that not all #!/bin/sh scripts are 100% 
POSIX compliant, nor am I convinced that all the possible shells are 
interchangeable either.  Ultimately this would lead to unpredictable 
(and difficult to support) behaviour for scripts.

>> 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.

True, but the OP said "my scripts rely on ASH/DASH functionality that is 
not present in BASH".  If you use functionality specific to a given 
shell, then you have to shebang that shell!

-- 
Yaakov

--
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

Re: How to install a custom permanent postinstall handler?

[Andrey Repin]

Greetings, Yaakov Selkowitz!

> On 2016-04-03 01:24, Achim Gratz wrote:
>> 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.

> Unfortunately the reality is that not all #!/bin/sh scripts are 100% 
> POSIX compliant, nor am I convinced that all the possible shells are 
> interchangeable either.  Ultimately this would lead to unpredictable 
> (and difficult to support) behaviour for scripts.

>>> 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.

> True, but the OP said "my scripts rely on ASH/DASH functionality that is 
> not present in BASH".  If you use functionality specific to a given 
> shell, then you have to shebang that shell!

I agree, of course, but in this case, I have to ask one not strictly
Cygwin-related question:
Is 'local -' a POSIX construct and/or is there a way to achieve the same
effect without using it? (Localize any shell option changes within a
function.)
Because, within my reach, Cygwin is the only system that not using DASH as
/bin/sh. Though, I may try rolling some busybox…


-- 
With best regards,
Andrey Repin
Monday, April 4, 2016 01:56:44

Sorry for my terrible english...

Re: How to install a custom permanent postinstall handler?

[Yaakov Selkowitz]

On 2016-04-03 18:05, Andrey Repin wrote:
> Because, within my reach, Cygwin is the only system that not using DASH as
> /bin/sh. Though, I may try rolling some busyboxÂ…

There *is* a world outside of Debian/Ubuntu; Fedora, RHEL/CentOS, and 
Arch Linux all use bash for /bin/sh.  However, a simple test in the form 
of building GCC with dash as /bin/sh, while noticeably faster, showed 
that Debian/Ubuntu have yet to fully upstream their work 
("gcc/genmultilib: 261: shift: can't shift that many").

As much as the speed difference is promising (and frankly tempting), I'm 
afraid we simply don't have the resources to fix everything to work with 
dash as /bin/sh.

-- 
Yaakov

--
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

Re: How to install a custom permanent postinstall handler?

[Andrey Repin]

Greetings, Yaakov Selkowitz!

> On 2016-04-03 18:05, Andrey Repin wrote:
>> Because, within my reach, Cygwin is the only system that not using DASH as
>> /bin/sh. Though, I may try rolling some busybox…

> There *is* a world outside of Debian/Ubuntu;

I have no doubt in that.

> Fedora, RHEL/CentOS, and Arch Linux all use bash for /bin/sh.

I tested on CentOS and FreeBSD, CentOS failed for the aforementiond
reason(bash!), FreeBSD test succeed, but I were unable to obtain exact version
info about used shell. For some reason, /bin/sh doesn't like -V or --version.
But it wasn't dash (not present).

(The simple test was "/bin/sh -c '_test(){ local -; echo 1;}; _test'.")

> However, a simple test in the form of building GCC with dash as /bin/sh, while
> noticeably faster, showed that Debian/Ubuntu have yet to fully upstream
> their work ("gcc/genmultilib: 261: shift: can't shift that many").

Well, what did you expect shifting nonexistent parameters?
POSIX explicitly required[1] that n must not be greater than $#.

> As much as the speed difference is promising (and frankly tempting), I'm 
> afraid we simply don't have the resources to fix everything to work with 
> dash as /bin/sh.

If you want to blame anything, blame your GCC build script.

P.S.
The same place[2] answered my original question. It doesn't look like "local"
is at all defined by POSIX, so using it with /bin/sh scripts is always a risk.

[1] http://pubs.opengroup.org/onlinepubs/009696699/utilities/shift.html
[2] http://pubs.opengroup.org/onlinepubs/009696699/idx/sbi.html

-- 
With best regards,
Andrey Repin
Monday, April 4, 2016 13:29:38

Sorry for my terrible english...

Re: How to install a custom permanent postinstall handler?

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

On 04/04/2016 12:09 AM, Yaakov Selkowitz wrote:
> On 2016-04-03 18:05, Andrey Repin wrote:
>> Because, within my reach, Cygwin is the only system that not using
>> DASH as
>> /bin/sh. Though, I may try rolling some busybox…
> 
> There *is* a world outside of Debian/Ubuntu; Fedora, RHEL/CentOS, and
> Arch Linux all use bash for /bin/sh.  However, a simple test in the form
> of building GCC with dash as /bin/sh, while noticeably faster, showed
> that Debian/Ubuntu have yet to fully upstream their work
> ("gcc/genmultilib: 261: shift: can't shift that many").

And non-Linux systems use a completely different shell for /bin/sh
(neither dash nor bash; BSD systems tend to use mksh).

> 
> As much as the speed difference is promising (and frankly tempting), I'm
> afraid we simply don't have the resources to fix everything to work with
> dash as /bin/sh.

That's why the alternatives would default to cygwin using bash as
/bin/sh, and anyone flipping the alternative to dash is on their own if
things break (or better, can help submit patches upstream to the
multiple places that are broken by using non-POSIX constructs in scripts
run by /bin/sh).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: How to install a custom permanent postinstall handler?

[Helmut Karlowski]

---------------------------------------------------
> On 04/04/2016 12:09 AM, Yaakov Selkowitz wrote:
> > On 2016-04-03 18:05, Andrey Repin wrote:
> >> Because, within my reach, Cygwin is the only system that not using
> >> DASH as
> >> /bin/sh. Though, I may try rolling some busybox…
> > 
> > There *is* a world outside of Debian/Ubuntu; Fedora, RHEL/CentOS, and
> > Arch Linux all use bash for /bin/sh.  However, a simple test in the form
> > of building GCC with dash as /bin/sh, while noticeably faster, showed
> > that Debian/Ubuntu have yet to fully upstream their work
> > ("gcc/genmultilib: 261: shift: can't shift that many").
> 
> And non-Linux systems use a completely different shell for /bin/sh
> (neither dash nor bash; BSD systems tend to use mksh).

OpenBSD uses the old pdksh with patches for /bin/sh and /bin/ksh.

-Helmut



--
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

Re: How to install a custom permanent postinstall handler?

[Achim Gratz]

Andrey Repin writes:
> I agree, of course, but in this case, I have to ask one not strictly
> Cygwin-related question:
> Is 'local -' a POSIX construct and/or is there a way to achieve the same
> effect without using it? (Localize any shell option changes within a
> function.)

No.  See my reply elsewhere in this thread that provides a link to
Stackoverflow with several options for workarounds.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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