Re: $PATH contains dot but unclear where it comes from

[Robert Klemme]

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
> missing entry is translated to ".", right? E.g.
> "/usr/bin:$foo:/usr/local/bin" will include a dot if foo is undefined.
> Here's the relevant section from the man page:
>
> "A zero-length (null) directory name in the value of PATH indicates
> the current directory. A null directory name may appear as two
> adjacent colons, or as an initial or trailing colon."

I was not aware of this.  Thank you!

> I'd be surprised if this isn't at the root of the issue.

Let's see: on Windows command prompt

path >path.txt

Now let's look at the contents.  No additional leading or trailing
semi colon.  But:

$ egrep -o ';{2,}' path.txt
;;
;;

Aha!  If we look at the positions

$ egrep -o '.{15};{2,}.{15}' path.txt
OWERSHELL\V1.0\;;C:\PROGRAM FILE
ftware\syswow64;;C:\Program File

we find they do not match the position and mount of dots in the Cygwin
$PATH: it's only present at the end:

mon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.

OK, now: I removed empty path entries from Windows PATH (system and
user), rebooted and they are gone.

But, the Cygwin shell's $PATH still has the dot at the same position
(i.e. at the end).

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 always also looks in the
current directory?

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
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: Testers needed: New passwd/group handling in Cygwin

[Frank Fesevur]

2014-02-15 13:52 GMT+01:00 Corinna Vinschen:
>> Just tested and copied .bashrc to .profile and that solved the problem.
>
> Good, so it was really just a shell thingy.
>
>> I vote[1] for /bin/bash being the default shell.
>
> Done in CVS.

Just downloaded the 2014-02-18 snapshot, deleted that .profile and
things works as expected!

Regards,
Frank

--
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: Testers needed: New passwd/group handling in Cygwin

[Corinna Vinschen]

On Feb 18 21:02, J.H. vd Water wrote:
> Hi Corinna,
> 
> >The crash looks weird.  It looks like your machine doesn't return
> >the machine sid when it's requested.  Can you please run the following
> >test application as non-admin and as admin and paster the output for
> >both cases into your reply?  Hmm, maybe that's a windows XP thingy?
> >I didn't test this stuff on anything prior to Vista.
> 
> Both cases show the same output:
> 
> $ ./lsa
> pdom name:  dnsname: <(null)>, sid: 0x0
> adom name:  sid: 0x246058

Huh.  This looks entirely normal and expected.  Which makes the
SEGV even more weird.  I'm apparently missing something here.

> Perhaps, it is best to stop here for the moment ... There must be more 
> pressing
> things on your list.

No, there aren't.  This testing is very important.  I'd like to
have such crashes like yours fixed before this new code gets
released.

> Moreover, I already decided to use 'db_enum: files' in /etc/nssswitch.conf 
> (and
> XP is a thing of the past, is it not?).

I'm going to make some tests on XP, but if I can't track this down,
would you mind if I send you a test Cygwin DLL with extended debug
output to help tracking it down?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgplxDpjrEw4C.pgp
Description: PGP signature

Re: Testers needed: New passwd/group handling in Cygwin

[J.H. vd Water]

Hi Corinna,

(Sorry, have't found time to properly subscribe to the list, yet)

>> Both cases show the same output:
>>
>> $ ./lsa
>> pdom name:  dnsname: <(null)>, sid: 0x0
>> adom name:  sid: 0x246058

I "lied" here :-) The non-admin case showed: ... sid: 0x246060
(So, almost the same)

>Huh.  This looks entirely normal and expected.  Which makes the
>SEGV even more weird.  I'm apparently missing something here.
>
>> Perhaps, it is best to stop here for the moment ... There must be more 
>> pressing
>> things on your list.
>
>No, there aren't.  This testing is very important.  I'd like to
>have such crashes like yours fixed before this new code gets
>released.

>> Moreover, I already decided to use 'db_enum: files' in /etc/nssswitch.conf 
>> (and
>> XP is a thing of the past, is it not?).

But who will still be using XP within a company after after april 2014?'. So, 
does
have XP priority? Your decision, of course ...

>I'm going to make some tests on XP, but if I can't track this down,
>would you mind if I send you a test Cygwin DLL with extended debug
>output to help tracking it down?

The best thing to do, I believe, if you want to fix 'XP' (my machine may turn 
out
to be a "misfit").

However, I have started afresh with the 18/2 snapshot ...

Same result: getpwent crashed (db_enum: local) ... getgrent is ok.

Send me a cygwin1.dll? Ok, if you tell me how to handle the thing (i.e. include
some pointers to documents that I must read in order to be able to get results).

Henri


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

xargs: Broken in version 1.7.28; works in legacy version 1.7.7-1

[Kai Tischler]

My OS: Win XP Pro SP3
My XEmacs: 21.4.19

My original problem:
- I had upgraded to the latest CygWin version 1.7.28
- XEmacs hangs at startup; because an xargs process hangs
- Furthermore, xargs does not seem to work properly in the shell

At first I thought that XEmacs shouldn't invoke an xargs process at all at 
startup; but investigation showed: An xargs process IS invoked at XEmacs 
startup for ages ... So something had to be probably "im Argen (wrong)" with 
the latest xargs version.

I then went back in time using the CygWin Time Machine; and installed the 
legacy version 1.7.7-1; and voila: Everything xargs-related seems to run like a 
charm again.

My conclusion is: Somewhere between the legacy version 1.7.7-1 and the latest 
version 1.7.28, the behaviour of xargs has changed for the worse.

Some further remark: I have gone back to the legacy version 1.7.7-1 by chance; 
of course I cannot try out each and every legacy version before the latest.


--
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: Need general snapshot testers

[Bengt Larsson]

Christopher Faylor wrote:
>We are contemplating releasing an interim 1.7.29 which does
>not incorporate Corinna's revamping of Cygwin's uid/gid handling.
>
>So, please check out snapshots, paying particular attention to the
>non-passwd/group parts of this file:
>
>http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.29?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src
>
>We'd like to release a 1.7.29 in the next couple of days so testing
>feedback is appreciated.

Tested the 64 bit DLL only:

) - Allow quoting of arguments to the CYGWIN environment variable, i.e.,
)   set CYGWIN=error_start="c:\bin\someprogram -T"

I tested it with what I use as 'CYGWIN="glob:ignorecase"' and that
works.

) - Try harder to do the right thing in the presence of console screen
buffers,
)   i.e., never clear the screen buffer unless the user asked for it.
Also
)   fix screen escape sequences which attempted to scroll the screen.
)   Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00274

I start a console window, set the buffer to 1100 lines, display a lot in
it. Start bash, type ^L: the console window resizes to be only one line.
Same result if bash was started first, then display data, then ^L.

) 
) - Make "ps -W" report different WINPIDs for processes that have been
execed
)   from, e.g., cmd.
)   Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00382

I have not found any duplicate processes. That thread reference isn't
particularly useful: I had to search the archives.

) - Avoid error messages from the signal handler if we're exiting.
)   Addresses: A random irc #cygwin complaint.

Not tested.

I'm always wary about testing more than the DLL because I'm not
absolutely sure how to back out of it.

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

Fwd: Bug with dlopen() and fork()

[Jaime Fabregas Fernandez]

Library references loaded by a process using dlopen() and dlsym() are
no more valid in child processes after running a fork(). Calls from
child process will never return.

I've searched for a similar problem in the mailing lists and found
this unanswered thread from 2001:

http://cygwin.com/ml/cygwin/2001-02/msg01225.html


I'm running cygwin64. This behaviour can be checked with the following
test program:


#include 
#include 

int (*myopen)(const char *);

main(){
void *handle;
int ret;
handle = dlopen("my_lib.dll", RTLD_LAZY);
myopen = dlsym(handle, "mylib_open");

if( ! fork() ){
ret = myopen("");
printf("This printf never shows, call to myopen will
block for ever\n");
}
else{
ret = myopen("");
printf("%i\n", ret);
sleep(1);
}
}


Same program runs correctly (showing the two printf's) in a Linux environment.

Thanks

--
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: Need general snapshot testers

[Christopher Faylor]

On Wed, Feb 19, 2014 at 12:52:58PM +0100, Bengt Larsson wrote:
>Christopher Faylor wrote:
>>We are contemplating releasing an interim 1.7.29 which does
>>not incorporate Corinna's revamping of Cygwin's uid/gid handling.
>>
>>So, please check out snapshots, paying particular attention to the
>>non-passwd/group parts of this file:
>>
>>http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.29?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src
>>
>>We'd like to release a 1.7.29 in the next couple of days so testing
>>feedback is appreciated.
>
>Tested the 64 bit DLL only:
>
>) - Allow quoting of arguments to the CYGWIN environment variable, i.e.,
>)   set CYGWIN=error_start="c:\bin\someprogram -T"
>
>I tested it with what I use as 'CYGWIN="glob:ignorecase"' and that
>works.
>
>) - Try harder to do the right thing in the presence of console screen
>buffers,
>)   i.e., never clear the screen buffer unless the user asked for it.
>Also
>)   fix screen escape sequences which attempted to scroll the screen.
>)   Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00274
>
>I start a console window, set the buffer to 1100 lines, display a lot in
>it. Start bash, type ^L: the console window resizes to be only one line.
>Same result if bash was started first, then display data, then ^L.

Huh.  That's a bad bug.  Thanks for reporting.  That's not something we'd
want to see in a release.

What Windows version are you running?

>) 
>) - Make "ps -W" report different WINPIDs for processes that have been
>execed
>)   from, e.g., cmd.
>)   Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00382
>
>I have not found any duplicate processes. That thread reference isn't
>particularly useful: I had to search the archives.

If you do:

bash -c "exec sleep 3600"

You'd see two processes in "ps -W" but only one in "ps -ef".

>) - Avoid error messages from the signal handler if we're exiting.
>)   Addresses: A random irc #cygwin complaint.
>
>Not tested.

There is no easy way to test this so that's fine.

>I'm always wary about testing more than the DLL because I'm not
>absolutely sure how to back out of it.

I should have made it clear that just the dll needs to be tested
although, if you were so inclined, you could also test the new
minidump process that Jon Turney just introduced.  That needs
to be added to the release notes so there is no way that most
people would know about it.

cgf

--
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: $PATH contains dot but unclear where it comes from

[Larry Hall (Cygwin)]

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 always also looks in the
current directory?


I don't have a . in my path and I didn't do anything special to
remove it.  If you want to track down where it comes from, run
cmd.exe and type in "c:\cygwin\bin\bash.exe -lix" (assuming you're
seeing this with bash and that your Cygwin installation is in
C:\cygwin) and look for places where PATH is set.  Oh and don't
forget to increase the number of lines in the window's scrollback
buffer to several thousand at least so you'll be able to scroll
back through all the output.  See the "Layout" tab under "Properties"
in the system menu for the window to change this setting.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Need general snapshot testers

[Bengt Larsson]

Christopher Faylor wrote:
>On Wed, Feb 19, 2014 at 12:52:58PM +0100, Bengt Larsson wrote:
>>I start a console window, set the buffer to 1100 lines, display a lot in
>>it. Start bash, type ^L: the console window resizes to be only one line.
>>Same result if bash was started first, then display data, then ^L.
>
>Huh.  That's a bad bug.  Thanks for reporting.  That's not something we'd
>want to see in a release.
>
>What Windows version are you running?

Windows 7.

>>) 
>>) - Make "ps -W" report different WINPIDs for processes that have been
>>execed
>>)   from, e.g., cmd.
>>)   Addresses: http://cygwin.com/ml/cygwin/2014-02/threads.html#00382
>>
>>I have not found any duplicate processes. That thread reference isn't
>>particularly useful: I had to search the archives.
>
>If you do:
>
>bash -c "exec sleep 3600"
>
>You'd see two processes in "ps -W" but only one in "ps -ef".

That seems so. ps -W:

 4504   14504   4504  cons0   1001 15:46:40
/usr/bin/sleep
 4504   14504   2312  cons0   1001 15:46:40
/usr/bin/sleep

ps -ef:

   Bengt4504   1 cons015:46:40 /usr/bin/sleep

--
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: Testers needed: New passwd/group handling in Cygwin

[Andrey Repin]

Greetings, Corinna Vinschen!

>> this week I applied the first incarnation of the new passwd/group
>> handling code to the Cygwin repository and after fixing a crash which
>> manifested in Denis Excoffier's network, I think we're at a point
>> which allows to push this forward.
>> [...]

> Ok guys, I just applied a patch implementing getpwent and getgrent,
> and the way to configure the output is probably more detailed than
> you ever wanted:

>   db_enum: source...

Setting

db_enum: local

seems to be really destructive.
I'm not good at reading straces, so... Can I make a useful trace for your
inspection?
So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
if db_enum set to local. Even uname -a crashes.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <18:42>

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: Testers needed: New passwd/group handling in Cygwin

[Andrey Repin]

Greetings, J.H. vd Water!

>>> Both cases show the same output:
>>>
>>> $ ./lsa
>>> pdom name:  dnsname: <(null)>, sid: 0x0
>>> adom name:  sid: 0x246058

> I "lied" here :-) The non-admin case showed: ... sid: 0x246060
> (So, almost the same)

Yeah, I understand, they supposed to be different.
Mine's also different, but results show data similar to yours.

> But who will still be using XP within a company after after april 2014?'. So, 
> does
> have XP priority? Your decision, of course ...

We will. Because we're not going to go over a headache of reinstalling
everything just because some jerk out in the world decided we should.
It's just not worth the money spent. Even if you ignore the cost of new OS
itself.

>>I'm going to make some tests on XP, but if I can't track this down,
>>would you mind if I send you a test Cygwin DLL with extended debug
>>output to help tracking it down?

> The best thing to do, I believe, if you want to fix 'XP' (my machine may turn 
> out
> to be a "misfit").

> However, I have started afresh with the 18/2 snapshot ...

> Same result: getpwent crashed (db_enum: local) ... getgrent is ok.

> Send me a cygwin1.dll? Ok, if you tell me how to handle the thing (i.e. 
> include
> some pointers to documents that I must read in order to be able to get 
> results).

I'm volunteering as well. And I'm a bit more sure of my system conditions >.>


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <18:58>

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: Testers needed: New passwd/group handling in Cygwin

[J.H. vd Water]

Hi Andrey,

>>>I'm going to make some tests on XP, but if I can't track this down,
>>>would you mind if I send you a test Cygwin DLL with extended debug
>>>output to help tracking it down?
>
>> The best thing to do, I believe, if you want to fix 'XP' (my machine may 
>> turn out
>> to be a "misfit").
>
>> However, I have started afresh with the 18/2 snapshot ...
>
>> Same result: getpwent crashed (db_enum: local) ... getgrent is ok.
>
>> Send me a cygwin1.dll? Ok, if you tell me how to handle the thing (i.e. 
>> include
>> some pointers to documents that I must read in order to be able to get 
>> results).
>
> I'm volunteering as well. And I'm a bit more sure of my system conditions >.>

:-)) ... to tell you the truth: a few months ago I completely reinstalled XP 
from
scratch ... all went well, according to "Redmond".

However I do not have the same expert knowledge of Windows as Corinna or you 
have;
as result of that, I do not see "the signs on the wall" if something is 
'obviously'
wrong.

So, my machine might not turn out to be a misfit, meaning: others, who are 
still in
favour of using XP, are strongly advised to test Corinna's work as well.

Henri


--
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: $PATH contains dot but unclear where it comes from

[Eliot Moss]

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

Regards -- Eliot Moss

--
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: $PATH contains dot but unclear where it comes from

[Robert Klemme]

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 described, really is a straightforward
> way to track this down ...

You are right - that's why I did that already.  You would have found
out by reading earlier emails. But to no avail.  As I have written
already the very first line of the log looks like this

+ PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM
FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES/COMMON
FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES
(X86)/COMMON FILES/MICROSOFT SHARED/WINDOWS
LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPOWERSHELL/V1.0:/cygdrive/c/PROGRAM
FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCED/WAVE/GEMALTO/ACCESS
CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTEMS/NTRU TCG
SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS
LIVE/SHARED:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT
ENGINE COMPONENTS/IPT:/cygdrive/c/PROGRAM FILES (X86)/INTEL/INTEL(R)
MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES
(X86)/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/IPT:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x86:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management
Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program Files
(x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program
Files/Intel/WiFi/bin:/cygdrive/c/Program Files/Common
Files/Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.'

It's from /etc/profile and the line looks like this

PATH="/usr/local/bin:/usr/bin:${PATH}"

The dot is already in the variable before bash even modifies it.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

--
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: $PATH contains dot but unclear where it comes from

[Larry Hall (Cygwin)]

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 tracing
enabled, as previously described, really is a straightforward
way to track this down ...


You are right - that's why I did that already.  You would have found
out by reading earlier emails. But to no avail.  As I have written
already the very first line of the log looks like this

+ PATH='/usr/local/bin:/usr/bin:/cygdrive/c/PROGRAM FILES (X86)/NVIDIA
CORPORATION/PHYSX/COMMON:/cygdrive/c/PROGRAM FILES (X86)/INTEL/ICLS
CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM
FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES/COMMON
FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES
(X86)/COMMON FILES/MICROSOFT SHARED/WINDOWS
LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPOWERSHELL/V1.0:/cygdrive/c/PROGRAM
FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCED/WAVE/GEMALTO/ACCESS
CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTEMS/NTRU TCG
SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU
TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS
LIVE/SHARED:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT
ENGINE COMPONENTS/IPT:/cygdrive/c/PROGRAM FILES (X86)/INTEL/INTEL(R)
MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROGRAM FILES
(X86)/INTEL/INTEL(R) MANAGEMENT ENGINE
COMPONENTS/IPT:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth
Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x86:/cygdrive/c/Program Files (x86)/Intel/OpenCL
SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management
Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program Files
(x86)/Intel/Intel(R) Management Engine
Components/DAL:/cygdrive/c/Program Files (x86)/Intel/Intel(R)
Management Engine Components/IPT:/cygdrive/c/Program
Files/Intel/WiFi/bin:/cygdrive/c/Program Files/Common
Files/Intel/WirelessCommon:/cygdrive/c/Users/rklemme/Applications/SysinternalsSuite:.'

It's from /etc/profile and the line looks like this

PATH="/usr/local/bin:/usr/bin:${PATH}"

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.  Don't discount any start-up batch files
(i.e. cygwin.bat), etc., that you may be using to kick-start bash
either.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: $PATH contains dot but unclear where it comes from

[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 this comes from.

I did look in windows environment as well (again, see earlier emails).

>  Don't discount any start-up batch files
> (i.e. cygwin.bat), etc., that you may be using to kick-start bash
> either.

I am using the regular mintty start that cygwin establishes.  This is
the command line
C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -

I can't see in documentation that mintty manipulates the environment
in some way.

More ideas?

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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

[ANNOUNCEMENT] Updated: vim-7.4.182-1

[Yaakov (Cygwin/X)]

The following packages have been updated in the Cygwin distribution:

*** vim-7.4.182-1
*** vim-common-7.4.182-1
*** vim-minimal-7.4.182-1
*** xxd-7.4.182-1
*** gvim-7.4.182-1

Vim is an advanced text editor that seeks to provide the power of the
de-facto Unix editor 'Vi', with a more complete feature set and a choice
of terminal and GTK+ interfaces.

This is an update to the most recent upstream patchset.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

[ANNOUNCEMENT] Updated: bind-9.9.5-1

[Yaakov (Cygwin/X)]

The following package has been updated in the Cygwin distribution:

*** bind-9.9.5-1
*** bind-utils-9.9.5-1

ISC BIND is a suite of Domain Name Service (DNS) utilities.

This is an update to the latest upstream release.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

[ANNOUNCEMENT] Updated: dialog-1.2-20140112-1

[Yaakov (Cygwin/X)]

The following packages have been added to the Cygwin distribution:

*** dialog-1.2-20140112-1
*** libdialog11-1.2-20140112-1
*** libdialog-devel-1.2-20140112-1

Dialog is a script-interpreter which provides a set of widgets for 
in-terminal dialogs.  Widgets are objects whose appearance and behavior 
can be customized.


This is an update to the latest upstream release.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

[ANNOUNCEMENT] Updated: python-numpy/python3-numpy 1.7.2-1

[Yaakov (Cygwin/X)]

The following package has been updated for the Cygwin distribution:

*** python-numpy-1.7.2-1
*** python3-numpy-1.7.2-1

The NumPy module contains a powerful N-dimensional array object,
sophisticated (broadcasting) functions, tools for integrating C/C++ and
Fortran code, and useful linear algebra, Fourier transform, and random
number capabilities.  It derives from the old Numeric code base and can
be used as a replacement for Numeric.  It also adds the features
introduced by numarray and can be used to replace numarray.

This is an update to the latest upstream release.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
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: xargs: Broken in version 1.7.28; works in legacy version 1.7.7-1

[Larry Hall (Cygwin)]

On 2/19/2014 6:48 AM, Kai Tischler wrote:

My OS: Win XP Pro SP3
My XEmacs: 21.4.19

My original problem:
- I had upgraded to the latest CygWin version 1.7.28
- XEmacs hangs at startup; because an xargs process hangs
- Furthermore, xargs does not seem to work properly in the shell

At first I thought that XEmacs shouldn't invoke an xargs process at all
at  startup; but investigation showed: An xargs process IS invoked at XEmacs
startup for ages ... So something had to be probably "im Argen (wrong)" with
the latest xargs version.

I then went back in time using the CygWin Time Machine; and installed
the  legacy version 1.7.7-1; and voila: Everything xargs-related seems to run
like a charm again.

My conclusion is: Somewhere between the legacy version 1.7.7-1 and the
latest version 1.7.28, the behaviour of xargs has changed for the worse.

Some further remark: I have gone back to the legacy version 1.7.7-1 by
chance; of course I cannot try out each and every legacy version before the
latest.


Does the following work (i.e. not hang) for you with 1.7.28?

find /bin -type f | xargs ls -l

This works fine for me with the cygwin package versions 1.7.25, 1.7.27, and
1.7.28.  If that works for you too in 1.7.28 but you still see a problem
with xargs and XEmacs, then I would say there's an interaction issue there
somewhere.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: $PATH contains dot but unclear where it comes from

[Andrey Repin]

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 this comes from.

> I did look in windows environment as well (again, see earlier emails).

>>  Don't discount any start-up batch files
>> (i.e. cygwin.bat), etc., that you may be using to kick-start bash
>> either.

> I am using the regular mintty start that cygwin establishes.  This is
> the command line
> C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -

> I can't see in documentation that mintty manipulates the environment
> in some way.

> More ideas?

The problem really was there:

$ head -10 log | cut -c 1-80
PATH=C:\PROGRAM FILES (X86)\NVIDIA CORPORATION\PHYSX\COMMON;C:\PROGRAM FILES (X8

You cut the output, denying any further investigation.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <22:27>

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: $PATH contains dot but unclear where it comes from

[Larry Hall (Cygwin)]

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
where this comes from.


I did look in windows environment as well (again, see earlier emails).


Well, let's consider that you resurrected this thread 12 days after it
fell dormant with no context in that email message for anyone to go on.
If you don't want to have to repeat yourself on individual points as they
are brought up again, you could consider, in the future, summarizing the
current state and things tried when you bring a topic out of hibernation.


  Don't discount any start-up batch files
(i.e. cygwin.bat), etc., that you may be using to kick-start bash
either.


I am using the regular mintty start that cygwin establishes.  This is
the command line
C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -

I can't see in documentation that mintty manipulates the environment
in some way.

More ideas?


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

Any "." resulting from the second echo?  Anything in the first that
would lead to one?  If it's very obvious that the Windows path isn't
the problem, then exit bash and run it again omitting either --norc
or --noprofile until you zero in on the file in your environment
that's adding the unwanted ".".  Keep in mind that scripts you
have in '/etc/profile.d' are sourced too.  If you've added things
there, this could be the culprit.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Bug with dlopen() and fork()

[Corinna Vinschen]

On Feb 19 14:38, Jaime Fabregas Fernandez wrote:
> Library references loaded by a process using dlopen() and dlsym() are
> no more valid in child processes after running a fork(). Calls from
> child process will never return.
> 
> I've searched for a similar problem in the mailing lists and found
> this unanswered thread from 2001:
> 
> http://cygwin.com/ml/cygwin/2001-02/msg01225.html
> 
> 
> I'm running cygwin64. This behaviour can be checked with the following
> test program:
> 
> 
> #include 
> #include 
> 
> int (*myopen)(const char *);
> 
> main(){
> void *handle;
> int ret;
> handle = dlopen("my_lib.dll", RTLD_LAZY);
> myopen = dlsym(handle, "mylib_open");
> 
> if( ! fork() ){
> ret = myopen("");
> printf("This printf never shows, call to myopen will
> block for ever\n");
> }
> else{
> ret = myopen("");
> printf("%i\n", ret);
> sleep(1);
> }
> }
> 
> 
> Same program runs correctly (showing the two printf's) in a Linux environment.

Works for me with 64 bit Cygwin.  I used this as DLL:

  $ cat > my_lib.c <

pgpE4jjgmhJB7.pgp
Description: PGP signature

Re: Testers needed: New passwd/group handling in Cygwin

[Corinna Vinschen]

On Feb 19 18:56, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> this week I applied the first incarnation of the new passwd/group
> >> handling code to the Cygwin repository and after fixing a crash which
> >> manifested in Denis Excoffier's network, I think we're at a point
> >> which allows to push this forward.
> >> [...]
> 
> > Ok guys, I just applied a patch implementing getpwent and getgrent,
> > and the way to configure the output is probably more detailed than
> > you ever wanted:
> 
> >   db_enum: source...
> 
> Setting
> 
> db_enum: local
> 
> seems to be really destructive.
> I'm not good at reading straces, so... Can I make a useful trace for your
> inspection?
> So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
> if db_enum set to local. Even uname -a crashes.

The last one is weird since uname doesn't call getpwent.

Anyway, with more help from Denis Excoffier I think I got it.  I'm
just building a new snapshot which should be up in half an hour or so.
Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpeyfhfnuuBj.pgp
Description: PGP signature

Re: Testers needed: New passwd/group handling in Cygwin

[Corinna Vinschen]

On Feb 19 12:01, J.H. vd Water wrote:
> Hi Corinna,
> 
> (Sorry, have't found time to properly subscribe to the list, yet)
> 
> >> Both cases show the same output:
> >>
> >> $ ./lsa
> >> pdom name:  dnsname: <(null)>, sid: 0x0
> >> adom name:  sid: 0x246058
> 
> I "lied" here :-) The non-admin case showed: ... sid: 0x246060
> (So, almost the same)
> 
> >Huh.  This looks entirely normal and expected.  Which makes the
> >SEGV even more weird.  I'm apparently missing something here.
> >
> >> Perhaps, it is best to stop here for the moment ... There must be more 
> >> pressing
> >> things on your list.
> >
> >No, there aren't.  This testing is very important.  I'd like to
> >have such crashes like yours fixed before this new code gets
> >released.
> 
> >> Moreover, I already decided to use 'db_enum: files' in /etc/nssswitch.conf 
> >> (and
> >> XP is a thing of the past, is it not?).
> 
> But who will still be using XP within a company after after april 2014?'. So, 
> does
> have XP priority? Your decision, of course ...
> 
> >I'm going to make some tests on XP, but if I can't track this down,
> >would you mind if I send you a test Cygwin DLL with extended debug
> >output to help tracking it down?
> 
> The best thing to do, I believe, if you want to fix 'XP' (my machine may turn 
> out
> to be a "misfit").
> 
> However, I have started afresh with the 18/2 snapshot ...
> 
> Same result: getpwent crashed (db_enum: local) ... getgrent is ok.
> 
> Send me a cygwin1.dll? Ok, if you tell me how to handle the thing (i.e. 
> include
> some pointers to documents that I must read in order to be able to get 
> results).

Can you please just test the today's snapshot which should show up
soon on the http://cygwin.com/snapshots/ page.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp9lO250lIs2.pgp
Description: PGP signature

Re: Testers needed: New passwd/group handling in Cygwin

[Andrey Repin]

Greetings, Corinna Vinschen!

>> Setting
>> 
>> db_enum: local
>> 
>> seems to be really destructive.
>> I'm not good at reading straces, so... Can I make a useful trace for your
>> inspection?
>> So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
>> if db_enum set to local. Even uname -a crashes.

> The last one is weird since uname doesn't call getpwent.

That's what was my thought, too. Because (un)setting it back cures the crash.

> Anyway, with more help from Denis Excoffier I think I got it.  I'm
> just building a new snapshot which should be up in half an hour or so.
> Please give it a try.

Looking into it now.
Doesn't crash or anything so far. (With `db_enum: local' set.)
Tried a few utilities, as well as your example get*ent code.
BTW, can we have it as one "getent"[1] tool for the next release?

Going to play with different settings, I will post if I find anything
unexpected.

[1] http://linux.die.net/man/1/getent


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <23:11>

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: $PATH contains dot but unclear where it comes from

[Andrey Repin]

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.

> Any "." resulting from the second echo?  Anything in the first that
> would lead to one?  If it's very obvious that the Windows path isn't
> the problem, then exit bash and run it again omitting either --norc
> or --noprofile until you zero in on the file in your environment
> that's adding the unwanted ".".  Keep in mind that scripts you
> have in '/etc/profile.d' are sourced too.  If you've added things
> there, this could be the culprit.



--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <23:10>

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: $PATH contains dot but unclear where it comes from

[Larry Hall (Cygwin)]

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.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Testers needed: New passwd/group handling in Cygwin

[Corinna Vinschen]

On Feb 19 23:19, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> Setting
> >> 
> >> db_enum: local
> >> 
> >> seems to be really destructive.
> >> I'm not good at reading straces, so... Can I make a useful trace for your
> >> inspection?
> >> So far, I'm unable to start anything with freshly rebuilt Cygwin1.dll
> >> if db_enum set to local. Even uname -a crashes.
> 
> > The last one is weird since uname doesn't call getpwent.
> 
> That's what was my thought, too. Because (un)setting it back cures the crash.
> 
> > Anyway, with more help from Denis Excoffier I think I got it.  I'm
> > just building a new snapshot which should be up in half an hour or so.
> > Please give it a try.
> 
> Looking into it now.
> Doesn't crash or anything so far. (With `db_enum: local' set.)
> Tried a few utilities, as well as your example get*ent code.
> BTW, can we have it as one "getent"[1] tool for the next release?
> 
> Going to play with different settings, I will post if I find anything
> unexpected.
> 
> [1] http://linux.die.net/man/1/getent

That sounds pretty much like the tool we need to be able to get rid of
the `grep /etc/passwd' stuff we have in some of the service configuration
helper scripts.  Unfortunately it's a glibc tool so we probably have to
create our own.  For a start it would suffice to support only passwd
and group databases.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpBWq0Ua9UXQ.pgp
Description: PGP signature

Re: $PATH contains dot but unclear where it comes from

[Cliff Hones]

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

Re: Testers needed: New passwd/group handling in Cygwin

[Andrey Repin]

Greetings, Corinna Vinschen!

>> [1] http://linux.die.net/man/1/getent

> That sounds pretty much like the tool we need to be able to get rid of
> the `grep /etc/passwd' stuff we have in some of the service configuration
> helper scripts.  Unfortunately it's a glibc tool so we probably have to
> create our own.

> For a start it would suffice to support only passwd and group databases.

Yup, was exactly what I thought.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 19.02.2014, <23:56>

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: $PATH contains dot but unclear where it comes from

[Achim Gratz]

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 bash has
> sourced any startup scripts - so where does it come from?

This is actually from the first non-empty, non-comment line in
/etc/profile, where the (converted) windows path is prepended with
"/usr/local/bin:/usr/bin:".  This suggests that the PATH as seen by bash
starts life with that dot appended, but of course it would be more
conclusive if the OP had shown the complete output (and maybe truncated
the windows PATH variable for the experiment).  Looking at the visible
PATH it is quite likely that this variable is rather long and the rest
of the environment may be quite large also.  There are interesting
problems when one or both of these get over a certain size – like for
example Git, which is using environment variables quite extensively,
stopping to work correctly without giving any useful error messages.  It
probably isn't the problem in this case, but the spaces and parens in
the windows path also can become a problem when scripts aren't super
careful with their quoting.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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: Need general snapshot testers

[Thomas Wolff]

Am 18.02.2014 20:08, schrieb Christopher Faylor:

We are contemplating releasing an interim 1.7.29 which does
not incorporate Corinna's revamping of Cygwin's uid/gid handling.

So, please check out snapshots, paying particular attention to the
non-passwd/group parts of this file:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.29?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src

We'd like to release a 1.7.29 in the next couple of days so testing
feedback is appreciated.

Not specific to this snapshot but it happens when trying to test it:
If a cygwin console is started from a cygwin terminal (e.g. in mintty: 
cygstart /Cygwin.bat), the TERM variable is set incorrectly.

Suggested fix: add either set TERM=cygwin or unset TERM to Cygwin.bat.
--
Thomas

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com


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

cygwin make reporting "multiple target patterns" issue

[Eddie Wang]

Hi Team,

I can build project OK with "make" command but failed on second build without 
running "make clean". Checked with web and noticed that removing previously 
create obj directory will resolve the issue. However, this is not the solution 
for make command. If only one file is changed, second build should carry on to 
recompile this changed file only. This will save a lot of time for not rebuild 
everything from scratch.

Does anyone know any solution to it or if I need to download some particular 
patch or version of Cygwin?

Here is my current build environment and Cygwin info:
Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1
Running under WOW64 on AMD64
SysDir: C:\Windows\system32
WinDir: C:\Windows

Cygwin installations found in the registry:
  System: Key: c5e39b7a9d22bafb Path: C:\cygwin

c:  hd  NTFS238370Mb  91% CP CS UN PA FC 
d:  cd N/AN/A
e:  cd  UDF   4427Mb 100% CP CS UN   ANNE_NTSC_1_A_SCN

Cygwin DLL version info:
DLL version: 1.7.25
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 270
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Program options name: Program Options
Installations name: Installations
Cygdrive default prefix: 
Build date: 
Shared id: cygwin1S5

Thanks!

Eddie

--
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: Testers needed: New passwd/group handling in Cygwin

[J.H. vd Water]

Hi Corinna,

>Can you please just test the today's snapshot which should show up
>soon on the http://cygwin.com/snapshots/ page.

Like Andrey I tested the 19/2 snapshot of today (x86).

For good measure, I again started afresh ...

getpwent (db_enum: local) no longer crashes. Splendid!

Henri



--
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: $PATH contains dot but unclear where it comes from

[Larry Hall (Cygwin)]

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 trailing dot.  I assume this is before bash has
sourced any startup scripts - so where does it come from?


This is actually from the first non-empty, non-comment line in
/etc/profile, where the (converted) windows path is prepended with
"/usr/local/bin:/usr/bin:".  This suggests that the PATH as seen by bash
starts life with that dot appended, but of course it would be more
conclusive if the OP had shown the complete output (and maybe truncated
the windows PATH variable for the experiment).  Looking at the visible
PATH it is quite likely that this variable is rather long and the rest
of the environment may be quite large also.  There are interesting
problems when one or both of these get over a certain size – like for
example Git, which is using environment variables quite extensively,
stopping to work correctly without giving any useful error messages.  It
probably isn't the problem in this case, but the spaces and parens in
the windows path also can become a problem when scripts aren't super
careful with their quoting.


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.  But if there is a problem like this in Cygwin, we certainly need the
specifics to show us all the problem.  That's not to say that if this issue
tickles someone enough, they shouldn't investigate it more in an attempt
to get to the bottom of it.  But absent that, I think it makes sense to let
Robert show us that this is definitely some Cygwin-specific problem which
could bite anyone with the same conditions.  At that point, it's definitely
something worth talking about more.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: cygwin make reporting "multiple target patterns" issue

[Larry Hall (Cygwin)]

On 2/19/2014 3:41 PM, Eddie Wang wrote:

Hi Team,

I can build project OK with "make" command but failed on second build
without running "make clean". Checked with web and noticed that removing
previously create obj directory will resolve the issue. However, this is not
the solution for make command. If only one file is changed, second build
should carry on to recompile this changed file only. This will save a lot of
time for not rebuild everything from scratch.

Does anyone know any solution to it or if I need to download some
particular patch or version of Cygwin?


Upgrading Cygwin to the current version is always recommended.  It may
or may not help in any particular situation but it makes sure that your
working off the current stuff that can more easily be debugged.

The problem you describe isn't something that's been reported to this
list.  Given that the symptoms you report would indicate a very broken
make, it's unlikely that we wouldn't have heard about it before now.
So I think the best way for us to help you understand how to get your
environment working properly is for you to send to the list a small
example of a case that doesn't work for you and a description of how
to reproduce it.  Then, others here can try to reproduce your problem
and can see exactly what you're doing.  cygcheck output will be helpful
too.  See the link below for more details on providing cygcheck output
and what a good problem report includes.


Problem reports:   http://cygwin.com/problems.html




--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: $PATH contains dot but unclear where it comes from

[Andrey Repin]

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 mean, in code, but comes from brain pathology of the
person introduced this problem into settings).
Windows PATH variable is constructed from two parts upon loading of user
profile.
First part is a system PATH in 
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session\ 
Manager/Environment/PATH
The other part is a user's PATH in 
/proc/registry/HKEY_CURRENT_USER/Environment/PATH
Both parts are, by no surprise, concatenated by semicolon.
Now, if some brain-dead programmer set an installation routine to append
"some\path;" to the end of either variable, you will get an empty element in
the path. Either "..;;..." or "...;".

> But if there is a problem like this in Cygwin, we certainly need the
> specifics to show us all the problem.  That's not to say that if this issue
> tickles someone enough, they shouldn't investigate it more in an attempt
> to get to the bottom of it.  But absent that, I think it makes sense to let
> Robert show us that this is definitely some Cygwin-specific problem which
> could bite anyone with the same conditions.  At that point, it's definitely
> something worth talking about more.
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.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <02:14>

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: Need general snapshot testers

[Andrey Repin]

Greetings, Thomas Wolff!

> Not specific to this snapshot but it happens when trying to test it:
> If a cygwin console is started from a cygwin terminal (e.g. in mintty: 
> cygstart /Cygwin.bat), the TERM variable is set incorrectly.
> Suggested fix: ... unset TERM to Cygwin.bat.

unset would be better (more neutral) choice in a long-term, IMO.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <02:24>

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: Need general snapshot testers

[Thomas Wolff]

Am 19.02.2014 23:24, schrieb Andrey Repin:

Greetings, Thomas Wolff!


Not specific to this snapshot but it happens when trying to test it:
If a cygwin console is started from a cygwin terminal (e.g. in mintty:
cygstart /Cygwin.bat), the TERM variable is set incorrectly.
Suggested fix: ... unset TERM to Cygwin.bat.

unset would be better (more neutral) choice in a long-term, IMO.

Actually, unset doesn't exist in cmd (blush).
It should be "set TERM=" then.

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com


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

Weird launch Cygwin terminal bash shell error

[Gerry Reno]

Running latest cygwin.

Does anyone recognize this error?

/etc/profile: fork: retry: Resource temporarily unavailable 0 [main] bash 2520 
child_info_fork::abort
C:\cygwin\bin\cygiconv-2.dll: loaded to different address: (parent 0x49) != 
child(0x5A)

Every once in a while I am getting this error when launching a Cygwin terminal.



--
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: Weird launch Cygwin terminal bash shell error

[Larry Hall (Cygwin)]

On 2/19/2014 5:55 PM, Gerry Reno wrote:

Running latest cygwin.

Does anyone recognize this error?

/etc/profile: fork: retry: Resource temporarily unavailable 0 [main] bash 2520 
child_info_fork::abort
C:\cygwin\bin\cygiconv-2.dll: loaded to different address: (parent 0x49) != 
child(0x5A)

Every once in a while I am getting this error when launching a Cygwin terminal.





--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Weird launch Cygwin terminal bash shell error

[Gerry Reno]

On 02/19/2014 06:10 PM, Larry Hall (Cygwin) wrote:
> On 2/19/2014 5:55 PM, Gerry Reno wrote:
>> Running latest cygwin.
>>
>> Does anyone recognize this error?
>>
>> /etc/profile: fork: retry: Resource temporarily unavailable 0 [main] bash 
>> 2520 child_info_fork::abort
>> C:\cygwin\bin\cygiconv-2.dll: loaded to different address: (parent 0x49) 
>> != child(0x5A)
>>
>> Every once in a while I am getting this error when launching a Cygwin 
>> terminal.
>
> 
>
>

So why did this just start happening after I ran Setup again a couple days ago?

Never had this problem prior to that.

Windows would be no more or less hostile to fork before or after Setup.



--
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: Weird launch Cygwin terminal bash shell error

[Larry Hall (Cygwin)]

On 2/19/2014 6:16 PM, Gerry Reno wrote:

On 02/19/2014 06:10 PM, Larry Hall (Cygwin) wrote:

On 2/19/2014 5:55 PM, Gerry Reno wrote:

Running latest cygwin.

Does anyone recognize this error?

/etc/profile: fork: retry: Resource temporarily unavailable 0 [main] bash 2520 
child_info_fork::abort
C:\cygwin\bin\cygiconv-2.dll: loaded to different address: (parent 0x49) != 
child(0x5A)

Every once in a while I am getting this error when launching a Cygwin terminal.







So why did this just start happening after I ran Setup again a couple days ago?


There can be many reasons.

setup*.exe now does a rebase with each install but things like adding
packages in subsequent runs can still cause conflicts.  The simplest
thing to do when you see a fork-related complaint is to try rebasing.  If
you still see the problem after a simple rebaseall, delete the database at
/etc/rebase.db* and try rebaseall again.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Patch for run-1.3.0-1 core dump

[Max Polk]

On 2/18/2014 4:16 AM, Corinna Vinschen wrote:

On Feb 17 17:25, Jon TURNEY wrote:

...
I went to all the trouble of investigating this, discovering that
run2_freeargv() is double-freeing the last element in newargv because the NULL
terminator isn't moved when the arguments are shifted down over newargv[0],
and writing a patch, before I noticed that we already had one :-(

--- origsrc/run-1.3.0/src/run.c 2013-07-24 16:26:39.0 +0100
+++ src/run-1.3.0/src/run.c 2014-02-17 17:08:49.12500 +
@@ -254,6 +254,7 @@ realMain(int argc, char* argv[])
free (newargv[0]);
for (newargc = 1; newargc < argc; newargc++)
   newargv[newargc-1] = newargv[newargc];
+  newargv[argc-1] = 0;
newargc = argc - 1;

/* update execname */

There's still something wrong.  I build run with this patch locally,
and it seems to fix the issue at first sight.  However, after the
child process of run exits, run throws an exception in free(), and
the stack looks broken (on 64 bit).  It seems there is a double free
or a free of an entirely unrelated address.

Scratch that.  I managed to fat-finger a one-line patch.  Sorry.

Corinna


Did my earlier patch get included?  I haven't seen a "run" new version yet.

http://www.cygwin.com/ml/cygwin/2013-12/msg6.html

My patch was the one that properly quote arguments.  Maybe let's start 
with that before putting new stuff underneath it.  From Chuck: "I'll 
roll a new update fairly soon."


http://www.cygwin.com/ml/cygwin/2013-12/msg00045.html


--
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: OpenSSH port forwarding bug

[Karl M]

> Subject: RE: OpenSSH port forwarding bug
> Date: Fri, 14 Feb 2014 22:11:03 -0800
>
>> Subject: RE: OpenSSH port forwarding bug
>> Date: Fri, 14 Feb 2014 12:48:53 -0800
>>
>> Hi Andrew...
>>
>> This is what I usually use in a proxycommand. So the example localized
>> it to just one layer. You can see that it connects to an ssh server and
>> then drops when I fail to complete the handshake. That is expected.
>>
>> The example shows that ssd -W gives an error, but doing the same thing
>> with ssh nc works fine.
>>
>> Thanks,
>>
>> ...Karl
>>
>>> Subject: Re: OpenSSH port forwarding bug
>>> Date: Wed, 12 Feb 2014 22:44:54 -0500
>>>
 Hi All...
 The following example shows the port forwarding problem.


 ~

 $ ssh raven -W coyote:22
 getsockname failed: Bad file descriptor
 SSH-2.0-OpenSSH_6.5
 Protocol mismatch.
 ~

 $ ssh raven nc coyote 22
 SSH-2.0-OpenSSH_6.5
 Protocol mismatch.
>>>
>>> What are you trying to do?
>>>
>>>
>>> --
> --
Hi All...

So I solved my real problem. It was a typo in my .ssh/config file that 
prevented me from being able to use the proxy command in ssh. I've used it for 
years.

But there is still a minor bug in ssh, When I use a proxycommand with ssh with 
the -W option, to avoid using an external program such as netcat (nc) the error 
message "getsockname failed: Bad file descriptor" is displayed. The 
proxycommand works, but displays this error message. Using netcat does not 
display this error message.

The example above is a STC showing the error in a more easily visible way. The 
names raven and coyote are local names on my network at home.

I am wishing the error message into the cornfield.

Thanks,

...Karl   
--
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: Need general snapshot testers

[Andrey Repin]

Greetings, Thomas Wolff!

>>> Not specific to this snapshot but it happens when trying to test it:
>>> If a cygwin console is started from a cygwin terminal (e.g. in mintty:
>>> cygstart /Cygwin.bat), the TERM variable is set incorrectly.
>>> Suggested fix: ... unset TERM to Cygwin.bat.
>> unset would be better (more neutral) choice in a long-term, IMO.
> Actually, unset doesn't exist in cmd (blush).
> It should be "set TERM=" then.

However you spell it :)
Using same assignment in shell would have nearly equal results.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <05:25>

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

Console buffer jumble

[Steven Penny]

I found a problem with the new snapshots. If you

1. start Cygwin with "Cygwin.bat"
2. enter "man bash"
3. enter down arrow then up arrow, or Page Down then Page Up

Normally this would just scroll through the man page. However with these new
snapshots it is creating a jumble in the console, notice the username mixed in
with the output of "man"

BASH(1) General Commands ManualBASH(1)

Steven@Steven-PC ~
$ man bash
BASH(1) General Commands ManualBASH(1)

NAME
   bash - GNU Bourne-Again SHell

SYNOPSIS
   bash [options] [file]

These are the versions affected

20140219  BAD
20140218  BAD
20140217  BAD
20140216  BAD
20140213  GOOD

This issue is mirrored with the MSYS2 project
http://sourceforge.net/p/msys2/tickets/23

--
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: Console buffer jumble

[Andrey Repin]

Greetings, Steven Penny!

> I found a problem with the new snapshots. If you

> 1. start Cygwin with "Cygwin.bat"
> 2. enter "man bash"
> 3. enter down arrow then up arrow, or Page Down then Page Up

> Normally this would just scroll through the man page. However with these new
> snapshots it is creating a jumble in the console, notice the username mixed in
> with the output of "man"

Gotta confirm this.
Only reproducible in native NT console, though.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <06:02>

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