strange shell output using tcsh under Cygwin

strange shell output using tcsh under Cygwin

[Will Parsons]

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

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

For comparison, I tried running the same script under FreeBSD (where tcsh is
also my normal interactive shell).  Since paths with spaces are quite rare
under Unix-type systems, I added a dummy 'x x' (imaginary directory) to the
path.  The result was as follows:

   % ./path
   /sbin
   /bin
   /usr/sbin
   /usr/bin
   /home/william/bin
   /home/william/.gem/ruby/2.3/bin
   /usr/local/sbin
   /usr/local/bin
   x x

So, I am quite puzzled.

-- 
Will


--
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: strange shell output using tcsh under Cygwin

[Andrey Repin]

Greetings, Will Parsons!

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

Try

  echo "$PATH"

next time.

Never trust random variables to be acceptable for command parameters.


-- 
With best regards,
Andrey Repin
Monday, November 6, 2017 05:41:26

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: strange shell output using tcsh under Cygwin

[Will Parsons]

Andrey Repin wrote:
> Greetings, Will Parsons!
>
>> 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'
>
> Try
>
>   echo "$PATH"
>
> next time.
>
> Never trust random variables to be acceptable for command parameters.

Nice thought, and indeed I had thought of it.  It makes no difference,
though.

-- 
Will


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

tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]

[Will Parsons]

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.

-- 
Will


--
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: tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]

[Will Parsons]

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

-- 
Will


--
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: tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]

[Brian Inglis]

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

RE: tcsh path conversion messed up? [was: strange shell output using tcsh under Cygwin]

[Lemke, Michael ST/HZA-ZIC2]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2258 bytes --]

On Tuesday, November 07, 2017 7:12 AM Brian Inglis wrote:
>On 2017-11-06 14:59, Will Parsons wrote:
>> Will Parsons wrote:
>>> I asked about what I thought was a shell scripting problem:
>>>    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.

How are you setting path? Do you have anything in your .cshrc/.login file? Most
likely, you are doing it wrong. 

>> 
>> Another bit of info - I just noticed that the value of the (t)csh shell
>> variable 'path' is:
>> 
>
>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

And that is also key for setting path:

set path = ( ... $path:q )

I had this bug ($path instead of $path:q) for 20 years in my init files.


\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

[SOLVED] Re: tcsh path conversion messed up?

[Will Parsons]

Lemke, Michael  ST/HZA-ZIC2 wrote:
> On Tuesday, November 07, 2017 7:12 AM Brian Inglis wrote:
>>On 2017-11-06 14:59, Will Parsons wrote:
>>> Will Parsons wrote:
>>>> I asked about what I thought was a shell scripting problem:
>>>>    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.
>
> How are you setting path? Do you have anything in your .cshrc/.login file? Most
> likely, you are doing it wrong. 
>
>>> Another bit of info - I just noticed that the value of the (t)csh shell
>>> variable 'path' is:
>>
>>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
>
> And that is also key for setting path:
>
> set path = ( ... $path:q )
>
> I had this bug ($path instead of $path:q) for 20 years in my init files.

Bingo!  I had this line in my ~/.cshrc:

  set path = ( /usr/local/bin /usr/bin /bin /usr/sbin $path )

Changing $path to $path.q solved the problem.

(I am still somewhat puzzled, though - the original PATH that I quoted in my
original query did have spaces, so what changed?)

At any rate, the problem seems to be solved, so thank you very much.

-- 
Will


--
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: [SOLVED] Re: tcsh path conversion messed up?

[Lemke, Michael ST/HZA-ZIC2]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4162 bytes --]

On November 07, 2017 11:08 PM Will Parsons wrote:
>Lemke, Michael  ST/HZA-ZIC2 wrote:
>> On Tuesday, November 07, 2017 7:12 AM Brian Inglis wrote:
>>>On 2017-11-06 14:59, Will Parsons wrote:
>>>> Will Parsons wrote:
>>>>> I asked about what I thought was a shell scripting problem:
>>>>>    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.
>>
>> How are you setting path? Do you have anything in your .cshrc/.login file? Most
>> likely, you are doing it wrong. 
>>
>>>> Another bit of info - I just noticed that the value of the (t)csh shell
>>>> variable 'path' is:
>>>
>>>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
>>
>> And that is also key for setting path:
>>
>> set path = ( ... $path:q )
>>
>> I had this bug ($path instead of $path:q) for 20 years in my init files.
>
>Bingo!  I had this line in my ~/.cshrc:
>
>  set path = ( /usr/local/bin /usr/bin /bin /usr/sbin $path )
>
>Changing $path to $path.q solved the problem.

For the record, it is $path:q not $path.q

>
>(I am still somewhat puzzled, though - the original PATH that I quoted in my
>original query did have spaces, so what changed?)

Nothing. csh treats PATH differently. I am not sure about all the details and
how/if PATH and path are synchronized but in csh you define the path with "path",
which is an array. "PATH" is only a string that gets parsed into individual
elements by using : as the separator. Not so "path". You set its elements as

set path = ( path1 path2 ... )

where the space is the separator. So how to add an element with a space? You 
add quotes:

set path = ( "/cygdrive/c/program files" /usr/bin )

But that won't work in a simple replacement. In

  set path = ( /usr/local/bin $path )

$path expands into the space separated words producing what you saw. Think of
it like you typed it yourself (note that path does not contain any quotes). 
So you'd think to do this:

  set path = ( /usr/local/bin "$path" )

Won't work either. It creates 2 entries with the last one being everything
in path as a single entry. So you need to quote it differently or write a loop.
Use the :q modifier to make $path expand as array elements. This is what :q is for.
In Unix you most likely don't notice the difference as Unix directories usually
have no spaces. But it is exactly the same.

>
>At any rate, the problem seems to be solved, so thank you very much.

You might even find that more windows commands are now available (e.g. java), which
got installed into Program Files and added to PATH.


\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ