On 19/02/2014 19:32, Larry Hall (Cygwin) wrote: > On 2/19/2014 2:10 PM, Andrey Repin wrote: >> Greetings, Larry Hall (Cygwin)! >> >>> From the Windows "Run..." or "Search programs and files" edit box, >>> type "cmd.exe". From the console window that opens as a result, type >>> the following. >> >>> echo %PATH% >>> c:\cygwin64\bin\bash --norc --noprofile -lix >>> echo $PATH >> >> Larry, we walked through exactly this process, but he denied any >> investigation >> by cutting the output of the first echo command. > > You're right Andrey. You were covering much the same ground with Robert. > It's strange that he cut off the part of the results that was the key. > My original inclination was to not step into this thread in the first > round. I don't know why I changed my mind for the second. ;-) > > I think the point of Robert's original inquiry was to find out where/how > the "." could get added if it was happening in Cygwin. Given the ground > covered (at least once) in this thread, I think we've provided all the > information that should be needed to track this down. If not, the > remainder of the "where?" and "how?" questions really aren't Cygwin- > specific so I think this thread is really off-topic.
Perhaps I shouldn't wade in here, but I think the discussion so far has not focussed on exactly what the OP said. I also don't understand why he chose to cut his interesting output to 80 chars, but if you can believe what he says, which I'll repeat here, there is something odd happening: He appears to have generated a log file almost as asked - first echoing %PATH% in a cmd shell, and then appending an invokation of bash with args --login -x -i His result (cut) was: > $ head -10 log | cut -c 1-80 > PATH=C:\PROGRAM FILES (X86)\NVIDIA CORPORATION\PHYSX\COMMON;C:\PROGRAM FILES > (X8 > bash: cannot set terminal process group (-1): Inappropriate ioctl for device > bash: no job control in this shell > + PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA > CORPORATI > + MANPATH=/usr/local/man:/usr/share/man:/usr/man: > + INFOPATH=/usr/local/info:/usr/share/info:/usr/info: > ++ id -un > + USER=rklemme > + ORIGINAL_TMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp > + ORIGINAL_TEMP=/cygdrive/c/Users/rklemme/AppData/Local/Temp OK - so useless for us - but he goes on to say... > The first line does not contain the dot. The fourth line contains the > dot at the end: > > $ sed -nre '4s#^(.{20}).*(.{80})$#\1...\2#p' log > + > PATH='/usr/local/b...Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.' So there is no dot at the end of PATH as seen in cmd - and (I assume, since this was also discussed) no duplicated semicolons or trailing semicolon at the end of the cmd PATH. But the very first PATH printed by bash does contain a trailing dot. I assume this is before bash has sourced any startup scripts - so where does it come from? Could a trailing unprintable (eg CR) in the path somehow cause Cygwin dll or bash to add the dot? I'd suggest if Robert does want to pursue this he (a) reads http://cygwin.com/problems.html, and submits his cygcheck output (I may have missed it but I don't recall seeing it), and (b) repeats his diagnostic attempts without cutting, and showing us the full results (not cut or elided). -- Cliff -- 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