X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=LGTQQQNzBpYUx9o7
	zz4/RrhHN3/1ECFq1BOb3yCg4Qo/KHhp4cj7liuttWIYf0wAZdryZ/5r7YBS5y/I
	Z37fLjXL8eUxPJYX8U/Kgj6jFeL9gIJByCFRunlksFpv74y02dS6k7Oxl+qxAzLX
	kV+JzLpcfv/Jfm/3RUtfZvArI08=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=CTc2FykGYyQ4IMY+3cwBnt
	YGXZw=; b=FG0MlICSAcZ0H2D9v/tTQsoeQqY7DDuOQjGx0vm3uvLsS+fXGy5JKc
	XC67VtaG96+8S/ng1JoL3eqX1ucgMDt6a4a+AdBvPncKSQRNPL1HXCyWi5ctoZwX
	hcq23lELTP1QexUwcUjnO1ro0YsUa+F/GWRidc1e1x7A+kxTo0g3w=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.7 required=5.0 tests=BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:iso-8859-15, aix, AIX, UD:arcor.de
X-HELO:	mail-in-06.arcor-online.net
X-DKIM:	Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3qdCz95v84z7m43
Subject:	Re: How to install a custom permanent postinstall handler?
To:	cygwin AT cygwin DOT com
References:	<838469265 DOT 20160401235308 AT yandex DOT ru> <87a8lcicxg DOT fsf AT Rainer DOT invalid> <5700975A DOT 3070002 AT cygwin DOT com> <87y48vqkfx DOT fsf AT Rainer DOT invalid>
From:	Dirk Fassbender <dirk DOT fassbender AT arcor DOT de>
Message-ID:	<570102D3.6000502@arcor.de>
Date:	Sun, 3 Apr 2016 13:47:31 +0200
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version:	1.0
In-Reply-To:	<87y48vqkfx.fsf@Rainer.invalid>

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

- Raw text -