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