Re: Why 'script' utility require SHELL (and work fine under Linux)?
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-li...@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)?
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
Re: Why 'script' utility require SHELL (and work fine under Linux)?
Greetings, Cyrille Lefevre! Would defining $SHELL at a system level solve your issue? -- WBR, Andrey Repin (anrdae...@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)?
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
Re: Why 'script' utility require SHELL (and work fine under Linux)?
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 signature.asc Description: Digital signature
Re: Why 'script' utility require SHELL (and work fine under Linux)?
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-li...@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)?
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 (anrdae...@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)?
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
Why 'script' utility require SHELL (and work fine under Linux)?
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)?
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
