delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2011/11/07/18:24:03

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RP_MATCHES_RCVD,SARE_FREE_WEBM_LAPOSTE,TW_PD
X-Spam-Check-By: sourceware.org
Message-ID: <4EB868E9.3070601@laposte.net>
Date: Tue, 08 Nov 2011 00:25:29 +0100
From: Cyrille Lefevre <cyrille DOT lefevre-lists AT laposte DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Why 'script' utility require SHELL (and work fine under Linux)?
References: <j7908e$hjt$1 AT dough DOT gmane DOT org> <4EB372A3 DOT 6020806 AT laposte DOT net> <20111104202213 DOT GA10510 AT jethro DOT local DOT lan>
In-Reply-To: <20111104202213.GA10510@jethro.local.lan>
X-IsSubscribed: yes
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
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id pA7NNxEA014837

Le 04/11/2011 21:22, David Sastre a écrit :
> On Fri, Nov 04, 2011 at 06:05:39AM +0100, Cyrille Lefevre wrote:
>> the base-file maintainer has been BCC'ed to add the export SHELL to
>> the /etc/profile.
>
> GNU/Linux login sets SHELL to bash, mksh, ... whilst ssh sets SHELL to
> /bin/bash, /bin/posh, /bin/mksh ...
> Given that there is no real login into cygwin (yet?), SHELL should be
> set to the expected login value.
>
> Assuming SHELL would be set and exported for login shells, i.e.,
> further (nested) callings to interactive, non-login shells would
> inherit the original (login) SHELL value (as in GNU/Linux):
>
> $ echo $SHELL
> bash
> $ mksh
> $ echo $SHELL
> bash
>
> It could be fixed for bash, zsh, and mksh. Even for nested
> calls to login shells (which GNU/Linux doesn't honor) by setting SHELL
> for every ifdef in /etc/profile. Collateral damage:
>
> -posh works OK if set as login shell in /etc/passwd, but it is broken
> when called from command line as login shell (i.e. it ignores both
> /etc/profile and ~/.profile)
> -sh thinks she's bash:
>
<snip>
>
> In short: it's not clear to me how to add this functionality
> consistently.
Hi,

well, you didn't understand what I mean, so,
let's try w/ export | grep SHELL

$ bash -l
$ echo $SHELL
/bin/bash
=> defaulted internally ?
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC="C:\\Windows\\system32\\cmd.exe"
=> no env SHELL
$ perl -MEnv -e 'print $SHELL.":".$COMSPEC'
:C:\Windows\system32\cmd.exe
$ awk 'BEGIN{print ENVIRON["SHELL"]":"ENVIRON["COMSPEC"]}'
:C:\Windows\system32\cmd.exe

ditto w/ sh (almost same as bash :-), however,
defaulted to /bin/bash instead of /bin/sh !

== posh ==

$ posh -l
$ echo $SHELL
=> no default !
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC=C:\Windows\system32\cmd.exe
export SHELL
=> empty !
$ env | grep SHELL
=> nothing

$ SHELL=/bin/bash posh -l
$ echo $SHELL
/bin/bash
=> ok
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC=C:\Windows\system32\cmd.exe
export SHELL=/bin/bash

PS : you're right, posh is broken regarding /etc/profile, etc. w/ -l !

== mksh ==

$ mksh -l
$ echo $SHELL
=> no default !
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC='C:\Windows\system32\cmd.exe'
export SHELL
=> empty !
$ env | grep SHELL
=> nothing

$ SHELL=/bin/bash mksh -l
$ echo $SHELL
/bin/bash
=> ok
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC='C:\Windows\system32\cmd.exe'
export SHELL=/bin/bash

== dash ==

same as mksh

== zsh ==

$ zsh -l
$ echo $SHELL
/bin/zsh
=> defaulted to /bin/zsh through /etc/profile.d/zshell.zsh
$ export | egrep 'SHELL|COMSPEC'
COMSPEC='C:\Windows\system32\cmd.exe'
SHELL=/bin/zsh

$ SHELL=/bin/bash zsh -l
$ echo $SHELL
/bin/bash
=> ok
$ export | egrep 'SHELL|COMSPEC'
COMSPEC='C:\Windows\system32\cmd.exe'
SHELL=/bin/bash

== ksh93 ==

$ ksh93 -l
$ echo $SHELL
/bin/sh
=> defaulted to /bin/sh instead of /path/to/ksh93 !
$ export | egrep 'SHELL|COMSPEC'
COMSPEC='C:\Windows\system32\cmd.exe'
=> no env SHELL

$ SHELL=/bin/bash ksh93 -l
$ echo $SHELL
/bin/bash
=> ok
$ export -p | egrep 'SHELL|COMSPEC'
export COMSPEC='C:\Windows\system32\cmd.exe'
export SHELL=/bin/bash

== csh/tcsh ==

$ csh -l
$ echo $SHELL
/bin/tcsh
=> defaulted to /bin/tcsh instead of /bin/csh through /etc/csh.login
$ printenv | egrep 'SHELL|COMSPEC'
COMSPEC=C:\Windows\system32\cmd.exe
SHELL=/bin/tcsh

$ SHELL=/bin/bash csh -l
$ echo $SHELL
/bin/tcsh
=> ko, $SHELL shouldn't be set irreparably in /etc/csh.login
if ( ! ${?SHELL} ) then
   setenv SHELL $shell
endif

so, export SHELL could be added to /etc/profile, isn't it ?

also, about mksh vs pdksh :
case $KSH_VERSION in *MIR*) SHELL=/bin/mksh ;; *) SHELL=/bin/ksh ;; esac

PS : mail from 31/03/2011, but it may not rich you ?

profile_d shouldn't set LC_COLLATE irreparably and should unset file :

would it be possible to change :

profile_d ()
{
   saved_LC_COLLATE=${LC_COLLATE}
   LC_COLLATE=C
   for file in /etc/profile.d/*.$1; do
     [ -e "${file}" ] && . "${file}"
   done
   LC_COLLATE=${saved_LC_COLLATE}
   unset saved_LC_COLLATE
}

to :

profile_d ()
{
   for file in $(export LC_COLLATE=C; echo /etc/profile.d/*.$1); do
     [ -e "${file}" ] && . "${file}"
   done
   unset file
}

PS1 *must not* be exported.

historically, it is not exported to know if it is a shell is interactive 
or not since only interactive shells set it.

i.e., the following both solutions are equivalent.

case $- in *i*) interactive ;; esac
[ -n $PS1 ] && interactive

if PS1 is exported, it is always set for subshells and this may cause 
trouble in some script.

also, from man bash :

An  interactive  shell  is one started without non-option arguments and
without the -c option whose standard input and error are both connected
to  terminals  (as determined by isatty(3)), or one started with the -i
option.  PS1 is set and $- includes i if bash is interactive,  allowing
a shell script or a startup file to test this state.

well, you answer me about that :

 >> What the man page doesn't tell you is that bash actually unsets PS1 
if the
 >> shell isn't interactive, so for bash at least, exporting PS1 can't 
cause a
 >> problem.

then, I reply :

 > thanks for the tip, however, this is not an expected behaviour...

also, what about other shells ? exporting PS1 broke this behavious.

PS again : english  isn't my natural language, so, forgive me if I'm too 
rough :-)

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille DOT Lefevre-lists AT laposte DOT net


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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019