Why 'script' utility require SHELL (and work fine under Linux)?

Why 'script' utility require SHELL (and work fine under Linux)?

[Oleksandr Gavenko]

Look to my session:

  gavenko+bash# echo $SHELL
   /bin/bash
   gavenko+bash# script
   Скрипт запущен, файл - typescript
                                    sh-4.1$ ^C
   sh-4.1$ exit
   Скрипт выполнен, файл - typescript


   gavenko+bash# SHELL=/bin/bash script
   Скрипт запущен, файл - typescript
                                    gavenko+bash# ^C
   gavenko+bash# exit
   Скрипт выполнен, файл - typescript


   gavenko+bash# export SHELL
   gavenko+bash# script
   Скрипт запущен, файл - typescript
                                    gavenko+bash# ^C
   gavenko+bash# exit

As you can see first time script does not use SHELL, second time use it
and third tie use it.

So SHELL env var does not exported by bash...

Why?

Is this right add

   export SHELL

to '~/.bashrc'?


--
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: Why 'script' utility require SHELL (and work fine under Linux)?

[Cyrille Lefevre]

Le 14/10/2011 11:43, Oleksandr Gavenko a écrit :
> Look to my session:

well, you session isn't very clear, however...

> As you can see first time script does not use SHELL, second time use it
> and third tie use it.
>
> So SHELL env var does not exported by bash...

well, shells doesn't export anything except variables already
exported at shell invocation or using the export builtin.

 > Why?

so, under unix like, $SHELL is positionned by login or whatever
process (sshd, telnetd, X gui, etc.) which launch the interactive
shell.
under cygwqin, $SHELL is well positionned when connected through the 
network (sshd) but not when launched by cygwin.bat.

> Is this right add
>
> export SHELL
>
> to '~/.bashrc'?

.bash_profile is more appropriate.

the base-file maintainer has been BCC'ed to add the export SHELL to the 
/etc/profile.

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists@laposte.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

Re: Why 'script' utility require SHELL (and work fine under Linux)?

[David Sastre]

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

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:
 
$ bash -l
$ echo $SHELL
bash
$ mksh -l
$ echo $SHELL
mksh
$ sh -l
$ echo $SHELL
bash
$ posh -l
$ echo $SHELL
bash

In short: it's not clear to me how to add this functionality
consistently.

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Why 'script' utility require SHELL (and work fine under Linux)?

[Cyrille Lefevre]

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.Lefevre-lists@laposte.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

Re: Why 'script' utility require SHELL (and work fine under Linux)?

[Andrey Repin]

Greetings, Cyrille Lefevre!

Would defining $SHELL at a system level solve your issue?


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 10.11.2011, <05:04>

Sorry for my terrible english...


--
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: Why 'script' utility require SHELL (and work fine under Linux)?

[Cyrille Lefevre]

Le 10/11/2011 02:05, Andrey Repin a écrit :
> Greetings, Cyrille Lefevre!
>
> Would defining $SHELL at a system level solve your issue?

well, I'm not the one who is having the problem,
I'm the one who is trying to help to solve the issue... :-)

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists@laposte.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

Re: Why 'script' utility require SHELL (and work fine under Linux)?

[Cyrille Lefevre]

Le 08/11/2011 00:25, Cyrille Lefevre a écrit :

Hi,

are you working on these issues ?

thanks in advance.

> 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.Lefevre-lists@laposte.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

Re: Why 'script' utility require SHELL (and work fine under Linux)?

[Andrey Repin]

Greetings, Oleksandr Gavenko!

>    # Where live all profiles...
>    HOME=e:\home
HOME is a path to YOUR PERSONAL profile. Not "all profiles".
You can translate it from %HOMEDRIVE%%HOMEPATH% or %USERPROFILE%, as you
prefer.


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.10.2011, <18:24>

Sorry for my terrible english...


--
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: Why 'script' utility require SHELL (and work fine under Linux)?

[Oleksandr Gavenko]

15.10.2011 0:47, Kaz Kylheku пишет:
>
>> So SHELL env var does not exported by bash...
>> Why?
>
> This is a bug in bash which hides broken behavior
> in the OS.
>
> Bash expects this to be an existing environment variable,
> and it usually is in normal Unix like operating systems.
>
> However, bash internally sets the variable if it is
> missing (without exporting it):
>
>  From "info bash".
>
>
> `SHELL'
> The full pathname to the shell is kept in this environment
> variable. If it is not set when the shell starts, Bash assigns to
> it the full pathname of the current user's login shell.
>
> It is correct not to export the variable. Bash might not be
> the user's shell, so it has no right to introduce itself as
> the SHELL to child processes.
>
> But, in fact, the shell does not own that variable at all
> and so it should not be setting it up even as an internal
> variable. The variable should stay unset to indicate
> that "there does not exist a configuration for the user's
> shell in this system".
> [...]
> Where does it come from on Linux? On the distro I have here,
> it is not exported by anything in /etc or my /home directory.
>
> Of course not. It comes from the "login" process which
> authenticates you and fetches your shell from the password
> file.
>
> Linux man page for "login":
>
> The value for $HOME, $SHELL, $PATH, $LOGNAME, and
> $MAIL are set according to the appropriate fields in
> the password entry.
>
> Cygwin sets HOME, and PATH, but not SHELL and LOGNAME.
>
Thanks for explanation. I set SHELL to /bin/bash under
control panel.

Also I set some another env var (place for info purpose):

   SHELL=/bin/bash
   # Emacs parser of external program output
   # does not expect warnings from Cygwin...
   CYGWIN=nodosfilewarning
   # To allow start X program anywhere when X started,
   # for example by Win+R
   DISPLAY=:0
   # Where live all profiles...
   HOME=e:\home
   # This allow access to info files from Cygwin and native Emacs...
   # Take special attention to final colon.
 
INFOPATH='c:/opt/cygwin/usr/share/info;e:/home/usr/share/info;e:/bin/gnuwin32/info;e:/bin/gnuwin32/share/info:'
   # This allow access to man files from Cygwin and native Emacs
   # (with cygwin-mount.el enabled)...
   # Take special attention to leading colon.
 
MANPATH=:/cygdrive/e/home/usr/share/man:/usr/share/man:/usr/local/share/man

Also 2 year ago I write personal note about why set SHELL to /bin/bash:
if do not do so rxvt use sh as shell and ~/.bashrc was not read
and I lose my personal settings.

But when I switch to mintty I forget about this as mintty start bash by 
default...


--
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: Why 'script' utility require SHELL (and work fine under Linux)?

[Kaz Kylheku]

> So SHELL env var does not exported by bash...
> Why?

This is a bug in bash which hides broken behavior
in the OS.

Bash expects this to be an existing environment variable,
and it usually is in normal Unix like operating systems.

However, bash internally sets the variable if it is
missing (without exporting it):

From "info bash".


`SHELL'
     The full pathname to the shell is kept in this environment
     variable.  If it is not set when the shell starts, Bash assigns 
to
     it the full pathname of the current user's login shell.

It is correct not to export the variable. Bash might not be
the user's shell, so it has no right to introduce itself as
the SHELL to child processes.

But, in fact, the shell does not own that variable at all
and so it should not be setting it up even as an internal
variable.  The variable should stay unset to indicate
that "there does not exist a configuration for the user's
shell in this system".


Let's confirm your finding:

linux $ env | grep SHELL
SHELL=/bin/bash

cygwin $ env | grep SHELL
cygwin $ # nothing


Where does it come from on Linux? On the distro I have here,
it is not exported by anything in /etc or my /home directory.

Of course not. It comes from the "login" process which
authenticates you and fetches your shell from the password
file.

Linux man page for "login":

   The value for $HOME, $SHELL, $PATH, $LOGNAME, and
   $MAIL are  set  according to the appropriate fields in
   the password entry.

Cygwin sets HOME, and PATH, but not SHELL and LOGNAME.


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