Use of SHELL env var by login

Use of SHELL env var by login

[Ernie Rael]

I just moved the cygwin installation. The "last" peculiarity I ran into 
was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
-i /Cygwin-Terminal.ico -", a ps showed

     /cygdrive/c/cygwin64/bin/bash

instead of /usr/bin/bash

I tracked this down the the windows setting for SHELL, the one you get 
to from windows' SystemProperties dialog, which was 
C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.

Is this expected behavior? (Though I can see why SHELL is there and I'd 
need to change it)


--
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: Use of SHELL env var by login

[Linda Walsh]

Ernie Rael wrote:
> I just moved the cygwin installation. The "last" peculiarity I ran into 
> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
> -i /Cygwin-Terminal.ico -", a ps showed
> 
>     /cygdrive/c/cygwin64/bin/bash
> 
> instead of /usr/bin/bash
> 
> I tracked this down the the windows setting for SHELL, the one you get 
> to from windows' SystemProperties dialog, which was 
> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
----
	I don't think cygwin sets the Windows SHELL variable in the
registry.  My SHELL value in the System section is 'C:/Bin/Bash.exe', 
which isn't a cygwin-looking path (looks like something I set). Are you
sure you didn't set it in the past sometime?



--
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: Use of SHELL env var by login

[Ernie Rael]

On 9/26/2016 7:18 PM, Linda Walsh wrote:
> Ernie Rael wrote:
>> I just moved the cygwin installation. The "last" peculiarity I ran 
>> into was that the login shell, with the shortcut 
>> "F:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -", a ps showed
>>
>>     /cygdrive/c/cygwin64/bin/bash
>>
>> instead of /usr/bin/bash
>>
>> I tracked this down the the windows setting for SHELL, the one you 
>> get to from windows' SystemProperties dialog, which was 
>> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
> ----
>     I don't think cygwin sets the Windows SHELL variable in the
> registry.  My SHELL value in the System section is 'C:/Bin/Bash.exe', 
> which isn't a cygwin-looking path (looks like something I set). Are you
> sure you didn't set it in the past sometime?

I suppose I might have set it way back when, but I do wonder why I would 
have. It's interesting that you also have it set; there must be 
something somewhere that prompted its setting. I can't find anything 
online that suggests that cygwin would have set it.

In any event, I still wonder why mintty/login use that rather than 
/etc/passwd.

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


--
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: Use of SHELL env var by login

[Andrew Schulman]

> I just moved the cygwin installation. The "last" peculiarity I ran into 
> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
> -i /Cygwin-Terminal.ico -", a ps showed
> 
>      /cygdrive/c/cygwin64/bin/bash
> 
> instead of /usr/bin/bash
> 
> I tracked this down the the windows setting for SHELL, the one you get 
> to from windows' SystemProperties dialog, which was 
> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
> 
> Is this expected behavior? (Though I can see why SHELL is there and I'd 
> need to change it)

/etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
getting information about users directly from the operating system instead.
Unless you have a special need for it, you should remove it. Same for
/etc/group.

In the absence of /etc/passwd, setting SHELL is the right way to set your login
shell.

Andrew


--
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: Use of SHELL env var by login

[Andrey Repin]

Greetings, Andrew Schulman!

>> I just moved the cygwin installation. The "last" peculiarity I ran into 
>> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
>> -i /Cygwin-Terminal.ico -", a ps showed
>> 
>>      /cygdrive/c/cygwin64/bin/bash
>> 
>> instead of /usr/bin/bash
>> 
>> I tracked this down the the windows setting for SHELL, the one you get 
>> to from windows' SystemProperties dialog, which was 
>> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
>> 
>> Is this expected behavior? (Though I can see why SHELL is there and I'd 
>> need to change it)

> /etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
> getting information about users directly from the operating system instead.
> Unless you have a special need for it, you should remove it. Same for
> /etc/group.

> In the absence of /etc/passwd, setting SHELL is the right way to set your login
> shell.

One of the right ways, I'd say.
If your aim is the integration of both environments, you MAY set variables,
but if you then start a login shell, they may be voided by the startup scripts.
I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
comment field.


-- 
With best regards,
Andrey Repin
Tuesday, September 27, 2016 14:09:19

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: Use of SHELL env var by login

[Andrew Schulman]

> Greetings, Andrew Schulman!
> 
> >> I just moved the cygwin installation. The "last" peculiarity I ran into 
> >> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
> >> -i /Cygwin-Terminal.ico -", a ps showed
> >> 
> >>      /cygdrive/c/cygwin64/bin/bash
> >> 
> >> instead of /usr/bin/bash
> >> 
> >> I tracked this down the the windows setting for SHELL, the one you get 
> >> to from windows' SystemProperties dialog, which was 
> >> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
> >> 
> >> Is this expected behavior? (Though I can see why SHELL is there and I'd 
> >> need to change it)
> 
> > /etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
> > getting information about users directly from the operating system instead.
> > Unless you have a special need for it, you should remove it. Same for
> > /etc/group.
> 
> > In the absence of /etc/passwd, setting SHELL is the right way to set your login
> > shell.
> 
> One of the right ways, I'd say.
> If your aim is the integration of both environments, you MAY set variables,
> but if you then start a login shell, they may be voided by the startup scripts.
> I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
> comment field.

OK. First I've heard of that. Can you explain how Ernie would do it?


--
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: Use of SHELL env var by login

[Andrey Repin]

Greetings, Andrew Schulman!

>> Greetings, Andrew Schulman!
>> 
>> >> I just moved the cygwin installation. The "last" peculiarity I ran into 
>> >> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
>> >> -i /Cygwin-Terminal.ico -", a ps showed
>> >> 
>> >>      /cygdrive/c/cygwin64/bin/bash
>> >> 
>> >> instead of /usr/bin/bash
>> >> 
>> >> I tracked this down the the windows setting for SHELL, the one you get 
>> >> to from windows' SystemProperties dialog, which was 
>> >> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
>> >> 
>> >> Is this expected behavior? (Though I can see why SHELL is there and I'd 
>> >> need to change it)
>> 
>> > /etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
>> > getting information about users directly from the operating system instead.
>> > Unless you have a special need for it, you should remove it. Same for
>> > /etc/group.
>> 
>> > In the absence of /etc/passwd, setting SHELL is the right way to set your login
>> > shell.
>> 
>> One of the right ways, I'd say.
>> If your aim is the integration of both environments, you MAY set variables,
>> but if you then start a login shell, they may be voided by the startup scripts.
>> I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
>> comment field.

> OK. First I've heard of that. Can you explain how Ernie would do it?

It's in the user's guide, right where you'd expect it to be ;)
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch-desc


-- 
With best regards,
Andrey Repin
Tuesday, September 27, 2016 18:00:31

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: Use of SHELL env var by login

[Linda Walsh]

Andrey Repin wrote:
>> In the absence of /etc/passwd, setting SHELL is the right way to set your login
>> shell.
> 
> One of the right ways, I'd say.
> If your aim is the integration of both environments, you MAY set variables,
> but if you then start a login shell, they may be voided by the startup scripts.
> I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
> comment field.
---
	Windows *doesn't* use "SHELL" to set your command line, it uses
COMSPEC.  So setting SHELL won't do MS programs any good.  I set mine for
the benefit of some non-MS programs that ran windows natively so I could
have an easier time in some of my own scripting.  The form C:/bin/bash.exe
was *NOT* set by cygwin prompting me to set it -- since it cygwin wanted a
windows path it would only have accepted C:\bin\bash.exe.  If it wanted a
non-windows, pure-posix-like path, it would have complained about referring
to /c as "C:".  

It's the unsupported "middle-ground" path that works in 
win32 and cygwin -- but my cygwin is install @ '/' not /c/ (though they
end up at the same point)  -- I mention the C: drive primarily for windows
programs (if they are on another drive, the path /bin/bash.exe is processed
as being on the "current drive", so in program like the _windows_ 
_versions_ of 'vim/gvim', that "cd" to the same directory as the file you are
editing, also end up changing drive letters (a network drive in my setup)
where /bin/bash doesn't work (as /bin/bash would only work when drive 'C' is
current).  You *can* set COMSPEC to something other than "cmd.exe", but I 
would not -- since some windows program depend on COMSPEC to be cmd.exe ( :-( ).

Setting SHELL will have no effect on Microsoft windows program -- it may
on some non-MS programs running on windows, but i've not found it provided
sufficient benefit for the troubles.  





--
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: Use of SHELL env var by login

[Andrey Repin]

Greetings, Linda Walsh!

> Andrey Repin wrote:
>>> In the absence of /etc/passwd, setting SHELL is the right way to set your login
>>> shell.
>> 
>> One of the right ways, I'd say.
>> If your aim is the integration of both environments, you MAY set variables,
>> but if you then start a login shell, they may be voided by the startup scripts.
>> I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB
>> comment field.
> ---
>         Windows *doesn't* use "SHELL" to set your command line, it uses
> COMSPEC.

Do note I didn't mention any specific variable names.
And I've explicitly outlined exactly the case you are describing in your post
- integration.
If you indeed have "more other" applications (native ports of certain tools,
which still use environment as a go-to reference sources), then by all means,
do what you find best for you.
I do that all the time, too, but I also have Cygwin itself configured to match
the environment I expect to have. Just to avoid issues.

> So setting SHELL won't do MS programs any good.  I set mine for
> the benefit of some non-MS programs that ran windows natively so I could
> have an easier time in some of my own scripting.  The form C:/bin/bash.exe
> was *NOT* set by cygwin prompting me to set it -- since it cygwin wanted a
> windows path it would only have accepted C:\bin\bash.exe.  If it wanted a
> non-windows, pure-posix-like path, it would have complained about referring
> to /c as "C:".  

> It's the unsupported "middle-ground" path that works in 
> win32 and cygwin -- but my cygwin is install @ '/' not /c/ (though they
> end up at the same point)  -- I mention the C: drive primarily for windows
> programs (if they are on another drive, the path /bin/bash.exe is processed
> as being on the "current drive", so in program like the _windows_ 
> _versions_ of 'vim/gvim', that "cd" to the same directory as the file you are
> editing, also end up changing drive letters (a network drive in my setup)
> where /bin/bash doesn't work (as /bin/bash would only work when drive 'C' is
> current).  You *can* set COMSPEC to something other than "cmd.exe", but I 
> would not -- since some windows program depend on COMSPEC to be cmd.exe ( :-( ).

> Setting SHELL will have no effect on Microsoft windows program -- it may
> on some non-MS programs running on windows, but i've not found it provided
> sufficient benefit for the troubles.  





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




-- 
With best regards,
Andrey Repin
Tuesday, September 27, 2016 19:39:05

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: Use of SHELL env var by login

[Achim Gratz]

Ernie Rael writes:
> I tracked this down the the windows setting for SHELL, the one you get
> to from windows' SystemProperties dialog, which was
> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.

This setting most likely was installed by yourself, the current Cygwin
doesn't install anything in system variables and it doesn't need SHELL
there.  Depending on why you put it into the system variables you might
need to keep it, but you could try to tremove it temporarily to find out
whether you truly need it.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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: Use of SHELL env var by login

[Linda Walsh]

Andrey Repin wrote:
> Greetings, Linda Walsh!

>>         Windows *doesn't* use "SHELL" to set your command line, it uses
>> COMSPEC.
> 
> Do note I didn't mention any specific variable names.
---
Indeed -- wanted to be explicit for those not know that the space
in-between the lines is important! ;-)

> And I've explicitly outlined exactly the case you are describing in your post
> - integration.
> If you indeed have "more other" applications (native ports of certain tools,
> which still use environment as a go-to reference sources), then by all means,
> do what you find best for you.
> I do that all the time, too, but I also have Cygwin itself configured to match
> the environment I expect to have. Just to avoid issues.
---
	Yup -- I use the same site-wide login scripts (for me & root and
multi-machine) on linux and cygwin and regularly make sure to copy and test
them on both -- not to mean I don't have cygwin specific sections that
key off OS:
  if ! type -f cygwin 2>/dev/null ; then 
    read SYSTEM_KERNEL HOSTNAME OSTYPE <<<"$($_prg_uname -sno)"
    if [[ $OSTYPE =~ Cygwin ]]; then sub cygwin () { return 0; }
    else sub cygwin () { return 1; }
    fi
    export -f cygwin
  fi
# and some cygwin-only defs in /etc/local/cygwin, like
alias gvim='setsid gvim'              # ensure win-native vim backgrounds properly

and a version of "mklink" that runs in bash and uses the
*nix syntax of "mklink <from> <to>" (and auto-handles directories)

--------------------------------------------

#!/bin/bash 
#set -x
shopt -s expand_aliases extglob sourcepath

##
## func to help determine if we were called as script or lib &
## not dirty env if called as lib
##
function conditional_setprog {
  local lprogpath="$0"
  [[ $lprogpath =~ .*bash.* ]]  && { lprogpath="$1"; shift; }
  local lprog="${lprogpath##*/}" lprogdir="${lprogpath%/*}"
  local lprogname="${lprog%.*}"
  if [[ $lprogname =~ errnos ]]; then
    declare -g prog="$lprog" progpath="$lprogpath" progname="$lprogname"
  fi
}
conditional_setprog "$@"

#include stdalias
#include errnos
# --  include needed bits for fewer includes
alias intConst=declare\ -ir sub=function my=declare int=declare\ -i
intConst ENOENT=2 EEXIST=17 ENOSYS=38 ENOMSG=42


sub mklink ()  {
  sub err_ex {
    my err="${!1}" msg="$2"
    echo "$msg" >&2
    return $err
  }
  if (($#!=2)) && [[ ! $0 =~ bash ]] ; then 
    echo "mklink <from> <to-path|.>   # (destination must not exist)" >&2
  fi
  local src=${1%/.} dst=${2%/.}; src=${src%/}
  [[ $dst == . ]] && dst="${src##*/}"
  [[ -e $dst ]] && {
    err_ex EEXIST "Destination, \"$dst\", already exists."
    return 
  }
  [[ -e $src ]] || { 
    err_ex ENOENT "Source, \"$src\", does not exist."
    return
  }
  local dest_type="unknown"
  if [[ -f $src ]]; then dest_type=""
  elif [[ -d $src ]]; then dest_type="/d"
  else
    err_ex ENOSYS "Cannot determine src, \"$src\" as file or dir"
    return
  fi
  local winsrc windst
  printf -v winsrc "%s" "$(cygpath -wl "$src")"
  printf -v windst "%s" "$(cygpath -wl "$dst")"
  # windows reverses everything *nix
  # just to be different from CP/M which modeled Unix
  printf -v cmd 'cmd /c mklink %s "%q" "%q"' "$dest_type" "$windst" "$winsrc"
  eval "$cmd"
  (($?)) && err_ex ENOMSG "Windows return unexpected status($status)"
}
export -f mklink

(($#==0)) ||  [[ $0 =~ bash ]] || mklink "$@"
# vim: ts=2 sw=2
--------------------------

-linda

--
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: Use of SHELL env var by login

[Ernie Rael]

On 9/27/2016 3:58 AM, Andrew Schulman wrote:
>> I just moved the cygwin installation. The "last" peculiarity I ran into
>> was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe
>> -i /Cygwin-Terminal.ico -", a ps showed
>>
>>       /cygdrive/c/cygwin64/bin/bash
>>
>> instead of /usr/bin/bash
>>
>> I tracked this down the the windows setting for SHELL, the one you get
>> to from windows' SystemProperties dialog, which was
>> C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.
>>
>> Is this expected behavior? (Though I can see why SHELL is there and I'd
>> need to change it)
> /etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
> getting information about users directly from the operating system instead.

Not exactly. IIUC /etc/passwd is *not* deprecated. /etc/passwd is used 
if "passwd: files" is in /etc/nsswitch.conf. But I'll be studying about 
all this in detail very soon.

In any event, one of the reasons I'm moving the cygwin installation is 
so that I have a copy. I'm making sure I know how to switch between 
installations. I'm finally upgrading my installation from 1.7 (ancient, 
before SAM/AD and new permissions) and I want to be able to go back 
temporarily if things don't go smoothly.

The only reason I started this thread, is that it seems wrong that 
$SHELL is used to specify the login shell. AFAIK, it should come from 
passwd, or (according to my reading of cygwin docs) from one of the 
methods specified by /etc/nsswitch.conf in modern cygwin releases. When 
I upgrade, I guess I'll find out.

> Unless you have a special need for it, you should remove it. Same for
> /etc/group.
>
> In the absence of /etc/passwd, setting SHELL is the right way to set your login
> shell.
>
> Andrew
>
>
> --
> 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
>
>
>


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