This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: SSH Path Bug
- From: Larry Hall <lh-no-personal-replies-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 01 May 2005 16:58:29 -0400
- Subject: Re: SSH Path Bug
- References: <AAE27702C6ACD84FA3BB03D6C04C2B67B5F6@swebtec-exchang.Swebtec.com> <4272E677.CB0D7E3A@dessent.net> <6.2.1.2.0.20050430144713.089d60f8@pop.prospeed.net> <20050501095519.GA25694@calimero.vinschen.de>
- Reply-to: Cygwin List <cygwin at cygwin dot com>
At 05:55 AM 5/1/2005, you wrote:
>On Apr 30 14:53, Larry Hall wrote:
>> At 09:59 PM 4/29/2005, you wrote:
>> >Dominic Chambers wrote:
>> >
>> >> Running commands via SSH causes windows executables to be given path
>> >> priority, so that they run ahead of identically named UNIX executables. I
>> >> found this while trying to use the find command as part of an SSH call.
>> >> For example, assuming you have an SSH server set up:
>> >
>> >I would think this has more to do with how you set your path than
>> >anything else. [...]
>>
>> No, it's not that. I was able to reproduce the described behavior even
>> when my system path has Cygwin's bin path before Windows.
>
>Sounds more like a cockpit error. I just tried it and I can't reproduce it.
Yeah, it looks like I must have been caught by Windows' insufferable need
to be rebooted after almost any change. Why am I surprised? ;-)
>> Running 'sshd'
>> in debug mode showed the imported path that was not an exact match to any
>> path I'd set anywhere. So far, I haven't been able to get far enough
>> that I know why this happens. But I can say that it happens for me
>> and on more than 1 system and O/S.
I should have said "Windows O/S" here. Specifically, I tried it on W2K and
XP.
>It's not a bug, it's a feature :-)
>
>What happens is a combination of what's done in cygrunsrv and sshd.
>
>First, cygrunsrv adds the path to /bin to the environment before starting
>a child process. But it *appends* /bin to the path, so that the order
>of path evaluation isn't changed. So that can be taken out of the equation.
>
>And what does sshd? Sshd is equivalent to a login process, so on non-Cygwin
>systems, it has to set the PATH variable to the default path value for the
>system. Usually something like PATH="/usr/bin:/bin".
>
>On Windows it's a bit different because the PATH variable given to service
>process (== the system environment) already contains paths, which are
>required to run any process on Windows. So the PATH variable must not be
>replaced by default paths as on other systems. Consequentially, Cygwin-sshd
>does not change $PATH at all, but uses the default PATH as it is set in the
>Windows system environment. This is, IMHO, the equivalent to the default
>PATH on other systems.
>
>What you can do:
>
>- Prepend Cygwin paths to your system environment and restart(!) the PC.
As I said above, UGH! ;-)
>- Set the default PATH only for your sshd service, for instance
>
> cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D \
> -e "PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem"
>
> assuming your Windows is installed in C:\Windows
Yeah, this is probably the nicest from the user point of view.
>- Even better: Always use absolute paths when running remote applications.
Yep. That certainly works and is the most portable. :-)
Thanks.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/