Greetings, Robert Klemme!
> C:\Users\rklemme>C:\cygwin64\bin\bash.exe -i -x -c exit >bash-log.txt 2>&1
> First line that contains PATH looks like this:
> ++ PATH='/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
> CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
> CLIENT:/cygdrive/c/PRO
On 3/6/2014 05:29, Robert Klemme wrote:
The phenomenon persists, for these executions:
c:\cygwin64\bin\bash.exe --norc --noprofile -i
c:\cygwin64\bin\bash.exe --norc --noprofile
c:\cygwin64\bin\bash.exe -i -l
Actually I could not find a commandline with bash that did not lead to
the dot appended
Hi,
Matthew Blakley pointed out to me that he noticed that under Windows 7
several processes have the dot added - not only Cygwin processes. I
checked with ProcessExplorer and indeed PATH of chrome.exe ends with
";.;". So it could be an OS "feature" but I could not find any
documentation about th
If it is of any use, the versions I have installed,
bash/sh 4.1.10(4), have the same length and differ
in two byte positions, by one bit in each case.
These differences may just reflect the different
name or a slightly different time at which the .exe
was constructed as part of a build process.
Folks,
sorry for the delay, I was sick in the meantime. Now, I try to
summarize all my finding in the hopes that bash package maintainer can
pick up from here.
When starting a terminal on my Windows 7 64 bit system $PATH contains
a dot at the end. The dot is not present in my Windows environment
On 2/20/2014 10:41 AM, Ken Brown wrote:
On 2/20/2014 9:12 AM, Robert Klemme wrote:
2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe
This fact should enable you to track down the problem. The bash manual
explains how it behaves
differently when invoked as sh.exe.
On 2/20/2014 9:12 AM, Robert Klemme wrote:
2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe
This fact should enable you to track down the problem. The bash manual
explains how it behaves differently when invoked as sh.exe. I don't
remember the details, but I thi
On Thu, Feb 20, 2014 at 03:12:47PM +0100, Robert Klemme wrote:
>Thanks to all who helped so far!
>
>On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
>
>> So far, I'm not convinced that issue is Cygwin-specific. The fact that it
>> doesn't manifest in Windows is actually because of it's (windo
On 2/20/2014 9:12 AM, Robert Klemme wrote:
Thanks to all who helped so far!
On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
So far, I'm not convinced that issue is Cygwin-specific. The fact that it
doesn't manifest in Windows is actually because of it's (windows) native
ignorance for th
Thanks to all who helped so far!
On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote:
> So far, I'm not convinced that issue is Cygwin-specific. The fact that it
> doesn't manifest in Windows is actually because of it's (windows) native
> ignorance for this matter.
I sent a lengthy email with
Greetings, Larry Hall (Cygwin)!
> It's certainly possible that there is a pathological case where the Windows
> path isn't handled properly because of size, content, or other unforeseen
> case.
I can offer one idea of where this problem could originate from, which is in
no way pathological (i mea
On 2/19/2014 3:27 PM, Achim Gratz wrote:
Cliff Hones writes:
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 tra
Cliff Hones writes:
> 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
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.
>>
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 $P
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 exactl
On 2/19/2014 12:51 PM, Robert Klemme wrote:
On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
wrote:
On 2/19/2014 12:16 PM, Robert Klemme wrote:
The dot is already in the variable before bash even modifies it.
So that means you need to look in your Windows environment to understand
whe
Greetings, Robert Klemme!
> On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
> wrote:
>> On 2/19/2014 12:16 PM, Robert Klemme wrote:
>>> The dot is already in the variable before bash even modifies it.
>>
>> So that means you need to look in your Windows environment to understand
>> where th
On Wed, Feb 19, 2014 at 6:23 PM, Larry Hall (Cygwin)
wrote:
> On 2/19/2014 12:16 PM, Robert Klemme wrote:
>> The dot is already in the variable before bash even modifies it.
>
> So that means you need to look in your Windows environment to understand
> where this comes from.
I did look in window
On 2/19/2014 12:16 PM, Robert Klemme wrote:
On Wed, Feb 19, 2014 at 5:06 PM, Eliot Moss wrote:
As others have said, cygwin does not add . to the path
itself. It must be something in your .bash_profile,
.bashrc, or other script sourced from them.
Going through the output of your login with tra
On Wed, Feb 19, 2014 at 5:06 PM, Eliot Moss wrote:
> As others have said, cygwin does not add . to the path
> itself. It must be something in your .bash_profile,
> .bashrc, or other script sourced from them.
>
> Going through the output of your login with tracing
> enabled, as previously describe
As others have said, cygwin does not add . to the path
itself. It must be something in your .bash_profile,
.bashrc, or other script sourced from them.
Going through the output of your login with tracing
enabled, as previously described, really is a straightforward
way to track this down ...
Reg
On 2/19/2014 3:37 AM, Robert Klemme wrote:
I assume there must be some internal mechanism in Cygwin which causes
this but at the moment I am out of ideas where to look further. Does
anybody else have an idea? Is there maybe some automatism which adds
the dot because on Windows systems the shell
On Tue, Feb 18, 2014 at 7:32 PM, David Boyce wrote:
>> On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
>> wrote:
>>
>>> Can anybody make sense of that? I can share the complete log with
>>> individuals if it helps.
>>
>> Nobody?
>
> I haven't read the whole backthread, but you do understand that a
On Thu, Feb 6, 2014 at 4:32 PM, Robert Klemme
wrote:
> Can anybody make sense of that? I can share the complete log with
> individuals if it helps.
Nobody?
Cheers
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
--
Problem reports: ht
On Thu, Feb 6, 2014 at 12:56 PM, Andrey Repin wrote:
> Greetings, Robert Klemme!
Hello Andrey!
>> I should have mentioned that I did just that - to no avail.
>
>> $ echo exit | bash --login -i -x 2>|log
>> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
>> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/b
Greetings, Robert Klemme!
> I should have mentioned that I did just that - to no avail.
> $ echo exit | bash --login -i -x 2>|log
> $ egrep -n 'PATH=(.:|.*:\.($|:))' log | head
> 1:+ PATH=/usr/local/bin:/usr/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
> 140:+++
> PATH=/usr/local/bin:/usr/bin
On Thu, Feb 6, 2014 at 10:14 AM, Csaba Raduly wrote:
> Hi Robert,
>
> On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme wrote:
>> Hi,
>>
>> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>>
>> $ echo "$PATH" | tr : \\n | egrep '^\.$'
>> .
>>
>> However, I was not able to detect where this came from
Hi Robert,
On Thu, Feb 6, 2014 at 10:01 AM, Robert Klemme wrote:
> Hi,
>
> in cygwin64 on Win 7 64 bit I find "." in $PATH:
>
> $ echo "$PATH" | tr : \\n | egrep '^\.$'
> .
>
> However, I was not able to detect where this came from. It's neither
> in the Windows system environment variables nor
Hi,
in cygwin64 on Win 7 64 bit I find "." in $PATH:
$ echo "$PATH" | tr : \\n | egrep '^\.$'
.
However, I was not able to detect where this came from. It's neither
in the Windows system environment variables nor in the user
environment variables - as you can also see on a cmd prompt:
C:\Users
30 matches
Mail list logo
