This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]
- From: Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>
- To: cygwin at cygwin dot com
- Date: Mon, 6 Nov 2017 23:12:17 -0700
- Subject: Re: tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]
- Authentication-results: sourceware.org; auth=none
- References: <oto9is$k56$1@blaine.gmane.org> <otqlbj$91n$1@blaine.gmane.org> <otqlvg$bcf$1@blaine.gmane.org>
- Reply-to: Brian dot Inglis at SystematicSw dot ab dot ca
On 2017-11-06 14:59, Will Parsons wrote:
> Will Parsons wrote:
>> I asked about what I thought was a shell scripting problem:
>>
>> Will Parsons wrote:
>>> Under Unix-type platforms, checking on what the PATH variable is set to is
>>> pretty easy - I typically use "env" and the displayed value of PATH is easily
>>> parsed by eye. Under Cygwin/Windows, one can do the same, but the value of
>>> PATH is more likely to be considerably more complicated and harder for a
>>> human to parse. For example, this is what I see on my local machine under
>>> Cygwin:
>>>
>>> PATH=/usr/local/bin:/usr/bin:/c/Windows/system32:/c/Windows:/c/Windows/system32/wbem:/c/ProgramData/Oracle/Java/javapath:/c/Program Files/Common Files/Microsoft Shared/Windows Live:/c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live:/c/Program Files/Dell/DW WLAN Card:/c/Program Files (x86)/Intel/iCLS Client:/c/Program Files/Intel/iCLS Client:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program Files/WIDCOMM/Bluetooth Software:/c/Program Files/WIDCOMM/Bluetooth Software/syswow64:/c/Program Files (x86)/Windows Live/Shared:/c/Program Files (x86)/Bazaar:/c/Program Files (x86)/QuickTime/QTSystem:/c/cygwin/home/william/bin:/c/ezwinports/bin:/c/Program Files (x86)/PuTTY:/usr/lib/lapack:/usr/sbin:/c/msys/1.0/local/bin
>>
>> This was a cut/paste, so I would be sure of not making a mistake. The PATH
>> looks completely reasonable to me, but...
>>
>>> I thought it would be nice to write a simple script to make this more
>>> comprehensible by breaking the path into separate lines, and so wrote the
>>> following trivial script:
>>>
>>> #!/bin/sh
>>> echo $PATH | tr ':' '\n'
>>>
>>> Oddly though, it does not give the expected results under Cygwin. Running
>>> this script under Cygwin under my normal interactive script (tcsh) yields the
>>> following:
>>>
>>> % ./path
>>> /usr/local/bin
>>> /usr/bin
>>> /bin
>>> /usr/sbin
>>> /c/Windows/system32
>>> /c/Windows
>>> /c/Windows/system32/wbem
>>> /c/ProgramData/Oracle/Java/javapath
>>> /c/Program
>>> Files/Common
>>> Files/Microsoft
>>> Shared/Windows
>>> Live
>>> /c/Program
>>> Files
>>> (x86)/Common
>>> Files/Microsoft
>>> Shared/Windows
>>> Live
>>> /c/Program
>>> Files/Dell/DW
>>> WLAN
>>> Card
>>> /c/Program
>>> Files
>>> (x86)/Intel/iCLS
>>> Client
>>> /c/Program
>>> Files/Intel/iCLS
>>> Client
>>> /c/Windows/System32/WindowsPowerShell/v1.0
>>> /c/Program
>>> Files/WIDCOMM/Bluetooth
>>> Software
>>> /c/Program
>>> Files/WIDCOMM/Bluetooth
>>> Software/syswow64
>>> /c/Program
>>> Files
>>> (x86)/Windows
>>> Live/Shared
>>> /c/Program
>>> Files
>>> (x86)/Bazaar
>>> /c/Program
>>> Files
>>> (x86)/QuickTime/QTSystem
>>> /c/cygwin/home/william/bin
>>> /c/ezwinports/bin
>>> /c/Program
>>> Files
>>> (x86)/PuTTY
>>> /usr/lib/lapack
>>>
>>> Clearly the path is being broken using spaces as well as colons.
>>>
>>> Even thoush the shell script itself explicitly specifies "/bin/sh", the
>>> result seems to depend on the shell being used to invoke it. Using Cugwin
>>> bash, the same script results in the following:
>>>
>>> sothis$ ./path
>>> /usr/local/bin
>>> /usr/bin
>>> /c/Windows/system32
>>> /c/Windows
>>> /c/Windows/system32/wbem
>>> /c/ProgramData/Oracle/Java/javapath
>>> /c/Program Files/Common Files/Microsoft Shared/Windows Live
>>> /c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live
>>> /c/Program Files/Dell/DW WLAN Card
>>> /c/Program Files (x86)/Intel/iCLS Client
>>> /c/Program Files/Intel/iCLS Client
>>> /c/Windows/System32/WindowsPowerShell/v1.0
>>> /c/Program Files/WIDCOMM/Bluetooth Software
>>> /c/Program Files/WIDCOMM/Bluetooth Software/syswow64
>>> /c/Program Files (x86)/Windows Live/Shared
>>> /c/Program Files (x86)/Bazaar
>>> /c/Program Files (x86)/QuickTime/QTSystem
>>> /c/cygwin/home/william/bin
>>> /c/ezwinports/bin
>>> /c/Program Files (x86)/PuTTY
>>> /usr/lib/lapack
>>> /usr/sbin
>>> /c/msys/1.0/local/bin
>>
>> I have just rebooted my Windows machine and see that in constrast to what I
>> wrote above, the value of PATH under tcsh shows up as:
>>
>> PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/c/Windows/system32:/c/Windows:/c/Windows/system32/wbem:/c/ProgramData/Oracle/Java/javapath:/c/Program:Files/Common:Files/Microsoft:Shared/Windows:Live:/c/Program:Files:(x86)/Common:Files/Microsoft:Shared/Windows:Live:/c/Program:Files/Dell/DW:WLAN:Card:/c/Program:Files:(x86)/Intel/iCLS:Client:/c/Program:Files/Intel/iCLS:Client:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program:Files/WIDCOMM/Bluetooth:Software:/c/Program:Files/WIDCOMM/Bluetooth:Software/syswow64:/c/Program:Files:(x86)/Windows:Live/Shared:/c/Program:Files:(x86)/Bazaar:/c/Program:Files:(x86)/QuickTime/QTSystem:/c/cygwin/home/william/bin:/c/ezwinports/bin:/c/Program:Files:(x86)/PuTTY:/usr/lib/lapack
>>
>> This doesn't look right, and would explain the strange shell output I
>> reported. (The value of PATH under bash looks normal.) Did the installation
>> of tcsh somehow get corrupted? I don't remember a particularly recent update
>> to tcsh.
>
> Another bit of info - I just noticed that the value of the (t)csh shell
> variable 'path' is:
>
> (/usr/local/bin /usr/bin /bin /usr/sbin /c/Windows/system32 /c/Windows /c/Windows/system32/wbem /c/ProgramData/Oracle/Java/javapath /c/Program Files/Common Files/Microsoft Shared/Windows Live /c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live /c/Program Files/Dell/DW WLAN Card /c/Program Files (x86)/Intel/iCLS Client /c/Program Files/Intel/iCLS Client /c/Windows/System32/WindowsPowerShell/v1.0 /c/Program Files/WIDCOMM/Bluetooth Software /c/Program Files/WIDCOMM/Bluetooth Software/syswow64 /c/Program Files (x86)/Windows Live/Shared /c/Program Files (x86)/Bazaar /c/Program Files (x86)/QuickTime/QTSystem /c/cygwin/home/william/bin /c/ezwinports/bin /c/Program Files (x86)/PuTTY /usr/lib/lapack)
>
> I can see that if one simply translates spaces to colons to derive $PATH from
> $path, there might be problems...
Regardless of from which shell and how I execute your path script - as "./path",
"source path", or ". path", the result is the same as expected, as it is a
simple Unix pipeline with two commands and an environment variable, and no shell
dependencies.
[Sorry if I'm unclear below, but it's been years since I last used csh under
Solaris, and it wasn't available on most systems until ported to Linux.]
In csh, "PATH" is a standard Unix environment variable whose value is a colon
separated directory list, and "path" is a shell wordlist kept synchonized with
"PATH".
To list the wordlist entries with embedded spaces in csh, quote the variable
name with the :q modifier in a foreach loop wordlist, and you get the desired
result as easily as in your sh script [trimmed and ...s redacted]:
.......% foreach p ( $path:q )
foreach? echo $p
foreach? end
/mnt/c/.../bin
/usr/local/bin
/usr/local/sbin
/usr/bin
/usr/sbin
/sbin
/usr/lib/lapack
/mnt/c/.../AppData/Local/Microsoft/WindowsApps
/mnt/c/Program Files (x86)/Microsoft SDKs/TypeScript/1.0
/mnt/c/Program Files/Microsoft SQL Server/120/Tools/Binn
/mnt/c/Program Files/Microsoft SQL Server/110/Tools/Binn
/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0
/mnt/c/WINDOWS/System32/Wbem
/mnt/c/WINDOWS/system32
/mnt/c/WINDOWS
Is your Cygwin install (partially?) outdated?
Download and run setup-x86{_64} to update everything and retry your tests.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
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