Re: cygwin-1.7.13-1: mknod console c 5 1 creates invalid device

[Ladislav Michl]

Dne 19.4.2012 19:21, Christopher Faylor napsal(a):

Funny you should pick up on that.  I actually had a sheet over my head
with two eyes cut out when I was writing the ChangeLog.

This should be fixed in the next snapshot.

Just checked cygwin1-20120419.dll.bz2 and it fixes this problem.

Thanks,
ladis

--
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: openssl-1.0.1a-1, openssl-devel-1.0.1-1, libopenssl100-1.0.1-1, libopenssl098-0.9.8v-1

[Corinna Vinschen]

I've updated the version of OpenSSL to 1.0.1a-1.  I also updated
the 0.9.8 libs to 0.9.8v-1.

This is an upstream security release.  The Cygwin release is build from
the vanilla sources.

Here's the official security advisory:


OpenSSL Security Advisory [19 Apr 2012]
===

ASN1 BIO vulnerability (CVE-2012-2110)
===

A potentially exploitable vulnerability has been discovered in the OpenSSL
function asn1_d2i_read_bio.

Any application which uses BIO or FILE based functions to read untrusted DER
format data is vulnerable. Affected functions are of the form d2i_*_bio or
d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.

Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc)
are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected.

Applications only using the PEM routines are not affected.

S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or
SMIME_read_CMS *are* affected.

The OpenSSL command line utility is also affected if used to process untrusted
data in DER format.

Note: although an application using the SSL/TLS portions of OpenSSL is not
automatically affected it might still call a function such as d2i_X509_bio on
untrusted data and be vulnerable.

Thanks to Tavis Ormandy, Google Security Team, for discovering this issue and
to Adam Langley  for fixing it.

Affected users should upgrade to OpenSSL 1.0.1a, 1.0.0i or 0.9.8v.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120419.txt



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, 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 the above URL.

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

--
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: 1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program

[cygwin]

>On 2012-04-19 16:14, Christopher Faylor wrote:
>> On Thu, Apr 19, 2012 at 12:56:33PM +0100, somebody wrote:
>>> Hi all,
>>>
>>> This started in 1.7.10 and I thought this may be fixed in 1.7.12 due
>>> to emails in the mailing list:
>>> http://sourceware.org/ml/cygwin/2012-03/msg00666.html
>>>
>>> But there still seems to be a problem piping from a .net console
>>> application to a visual c++ console application.
>>>
>>> Using the following simple C# program complied using "csc /optimize
>>> /target:exe /out:./consoleout.exe Program.cs"
>>>
>>> Begin Program.cs
>>> namespace consoleout
>>> {
>>>using System;
>>>
>>>internal static class Program
>>>{
>>>private static void Main(string[] args)
>>>{
>>>foreach (var arg in args) {
>>>Console.Out.WriteLine(arg);
>>>}
>>>}
>>>}
>>> }
>>>  End Program.cs
>>>
>>> I can use this to output to cygwin exes OK
>>> $ ./consoleout.exe Hello There | cat
>>> Hello
>>> There
>>> $ ./consoleout.exe Hello There | grep ll
>>> 1:Hello
>>> $
>>>
>>> I also created a visual c++ executable like the simple one below
>>> compiled with "cl /EHs readin.cxx /link"
>>>
>>> Begin readin.cxx
>>> #include 
>>> #include 
>>>
>>> int
>>> main(int argc, char** argv)
>>> {
>>>static_cast(argc);
>>>static_cast(argv);
>>>std::string buf;
>>>buf.reserve(1024);
>>>while (std::getline(std::cin, buf, '\n')) {
>>>std::cout << buf << '\n';
>>>}
>>>return EXIT_SUCCESS;
>>> }
>>>  End readin.cxx
>>>
>>> I can use this to output anything read in
>>> $ echo Hello | ./readin.exe
>>> Hello
>>> $ cat 'readin.cxx' | ./readin.exe
>>> #include 
>>> #include 
>>>
>>> int
>>> main(int argc, char** argv)
>>> {
>>>static_cast(argc);
>>>static_cast(argv);
>>>std::string buf;
>>>buf.reserve(1024);
>>>while (std::getline(std::cin, buf, '\n')) {
>>>std::cout << buf << '\n';
>>>}
>>>return EXIT_SUCCESS;
>>> }
>>> $
>>>
>>> But when combining the two, nothing happens.
>>> $ ./consoleout.exe Hello There | ./readin.exe
>>> $
>>>
>>> It "seems" as though the console out from the .net is not being
>>> correctly piped through to a vc++ program. I know that is a strange
>>> defect given all the other combinations work.
>>>
>>> The reverse works i.e. output from a visual c++ console application is
>>> piped correctly to a .net console application.
>>>
>>> This worked prior to 1.7.10 (1.7.9 and before).
>>>
>>> I am sorry that I cannot point to an area in the Cygwin code or
>>> suggest a fix, but I am hoping this is enough of a description to help
>>> someone find out what the issue is.
>>
>> Sorry but I'm not going to set up a .NET development environment to
>> figure out a problem.  If someone else wants to provide a clue as
>> to what's going on, I'd appreciate it.
>
> I'll bite, and it WJFFM...
>
> $ ./consoleout hello world | ./readin
> hello
> world
> $ uname -a
> CYGWIN_NT-6.1-WOW64 PEDA-PC 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin>
>
> To stress it a tiny bit more:
> $ ./consoleout hello world | ./readin | ./readin | ./readin | ./readin
> hello
> world
> $ ./consoleout hello world | ./readin | ./readin | grep rl | ./readin | 
> ./readin
> world
>
> Question for the OP: Does the pipe work from a cmd prompt?
>
> Cheers,
> Peter

Strange, I am using mintty and tcsh. It also fails for me in cmd/bash,
cmd/tcsh, mintty/bash.
It does work with straight forward cmd prompt, no cygwin shells. I am
using 32bit windows 7 though, not sure if that helps.
$ uname -a
CYGWIN_NT-6.1 F1N6LQ1 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin

Perhaps a little bit more about development environment?
Using VS2010 C# 4.0 (VS2008 fails to work as well using C# 3.0 and C# 2.0)

OK, while writing this I did test this on a 64bit windows and I get
the same result, no output from readin.

My original post has the cygcheck output, is there any major
difference between your configuration and mine there? I am more than
happy to try out various options that might fix or even help work out
what is going on.


Alan

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

Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are 
listed (Display all 262 possibilities? (y or n) y). I find that many of 
them are *.dll libraries under /usr/bin/. This is inconvenient to find 
the real executable applications (*.exe). Since *.dll files are only 
libraries, they are not necessary to have the attribute of "x". Thus, I 
run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is 
corrupted. I closed the terminal and failed to restart Cygwin. I started 
my  older version of Cygwin (I did not deleted it after installing a new 
version), and added "x" to the previous *.dll files. The dead Cygwin 
revived.


I am confused why /usr/bin/*.dll should be executable. I thought they 
were only library files. When I tried to run a dll file, bash says 
"cannot execute binary file". Are there some hidden stories?


The error messages are as follows:

Administrator@acer /usr/bin
$ chmod a-x *.dll

Administrator@acer /usr/bin
$ lh
 18 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
2020930 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
4039235 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
8057832 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
16074662 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: Resource temporarily unavailable


DJ

--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-20 21:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are 
listed (Display all 262 possibilities? (y or n) y). I find that many 
of them are *.dll libraries under /usr/bin/. This is inconvenient to 
find the real executable applications (*.exe). Since *.dll files are 
only libraries, they are not necessary to have the attribute of "x". 
Thus, I run the command "chmod a-x /usr/bin/*.dll". Unexpectedly, 
cygwin is corrupted. I closed the terminal and failed to restart 
Cygwin. I started my  older version of Cygwin (I did not deleted it 
after installing a new version), and added "x" to the previous *.dll 
files. The dead Cygwin revived.


I am confused why /usr/bin/*.dll should be executable. I thought they 
were only library files. When I tried to run a dll file, bash says 
"cannot execute binary file". Are there some hidden stories?


The error messages are as follows:

Administrator@acer /usr/bin
$ chmod a-x *.dll

Administrator@acer /usr/bin
$ lh
 18 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
2020930 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
4039235 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
8057832 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: retry: Resource temporarily unavailable
16074662 [main] -bash 4512 fork: child -1 - forked process died 
unexpectedly, retry 0, exit code -1073741790, errno 11

-bash: fork: Resource temporarily unavailable


DJ



lh is an alias to 'ls -lh'.

--
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: Why /usr/bin/*.dll must be executable?

[Václav Zeman]

On 20 April 2012 15:02, De-Jian Zhao wrote:
> Hi,
>
> When I type "cyg" and Tab, many executables starting with "cyg" are listed
> (Display all 262 possibilities? (y or n) y). I find that many of them are
> *.dll libraries under /usr/bin/. This is inconvenient to find the real
> executable applications (*.exe). Since *.dll files are only libraries, they
> are not necessary to have the attribute of "x". Thus, I run the command
> "chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the
> terminal and failed to restart Cygwin. I started my  older version of Cygwin
> (I did not deleted it after installing a new version), and added "x" to the
> previous *.dll files. The dead Cygwin revived.
>
> I am confused why /usr/bin/*.dll should be executable. I thought they were
> only library files. When I tried to run a dll file, bash says "cannot
> execute binary file". Are there some hidden stories?
DLLs are executables thus they need the +x bit. This is a Windows thing.

>[...]

-- 
VZ

--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are listed
(Display all 262 possibilities? (y or n) y). I find that many of them are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe). Since *.dll files are only libraries, they
are not necessary to have the attribute of "x". Thus, I run the command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the
terminal and failed to restart Cygwin. I started my  older version of Cygwin
(I did not deleted it after installing a new version), and added "x" to the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought they were
only library files. When I tried to run a dll file, bash says "cannot
execute binary file". Are there some hidden stories?

DLLs are executables thus they need the +x bit. This is a Windows thing.



If this is a windows thing, removing the x bit should not affect Cygwin. 
Instead, Cygwin is corrupted after removing the x bit.


--
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: 1.7.10->1.7.13 : output from .NET programs does not get through pipeline to a visual c++ program

[James Johnston]

I ran into similar issues, which seemed to be fixed in 1.7.12 - but if you
are still having issues even on the current Cygwin version of 1.7.13, I'd be
interested to know if they can be resolved.  If it's anything like the issue
I found, it has to do with erroneous pipe handling in Cygwin and nothing
directly to do with .NET.

Have you read this thread yet that I started last month?
http://sourceware.org/ml/cygwin/2012-03/msg00298.html

The technique I found useful was to use Reflector to decompile the .NET
Framework's Console class.  You could also refer to the framework's source
code, which Microsoft has made publicly available (believe it or not!).
(But for me, decompiled results from Reflector are often faster than trying
to obtain and then find the exact set of C# source files used to compile the
class in question.  Also, Reflector provides convenient hyperlinks to jump
from one related function to another.)

After decompiling, I traced the code so I knew exactly what Win32 API calls
were being made to read/write the console.  I was then able to isolate and
reproduce the issue in a straight Win32 app, taking .NET out of the equation
- which I then posted to the mailing list:

1.  I simplified C# code to smallest / simplest size possible that still
reproduces the issue.
2.  I decompiled each function call I made to the framework, and followed
the framework's code to see what API calls it made.  I took notes and made a
list of API calls that it made in chronological order.
3.  Using my notes, wrote a simple C++ program that reproduced the issue.
4.  Simplified the C++ program as much as possible while reproducing the
issue.

-Original Message-
Sent: Friday, April 20, 2012 10:27
Subject: Re: 1.7.10->1.7.13 : output from .NET programs does not get through
pipeline to a visual c++ program

Strange, I am using mintty and tcsh. It also fails for me in cmd/bash,
cmd/tcsh, mintty/bash.
It does work with straight forward cmd prompt, no cygwin shells. I am using
32bit windows 7 though, not sure if that helps.
$ uname -a
CYGWIN_NT-6.1 F1N6LQ1 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin

Perhaps a little bit more about development environment?
Using VS2010 C# 4.0 (VS2008 fails to work as well using C# 3.0 and C# 2.0)

OK, while writing this I did test this on a 64bit windows and I get the same
result, no output from readin.

My original post has the cygcheck output, is there any major difference
between your configuration and mine there? I am more than happy to try out
various options that might fix or even help work out what is going on.


Alan


--
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: Why /usr/bin/*.dll must be executable?

[Corinna Vinschen]

On Apr 21 00:17, De-Jian Zhao wrote:
> On 2012-4-20 21:07, Václav Zeman wrote:
> >On 20 April 2012 15:02, De-Jian Zhao wrote:
> >>Hi,
> >>
> >>When I type "cyg" and Tab, many executables starting with "cyg" are listed
> >>(Display all 262 possibilities? (y or n) y). I find that many of them are
> >>*.dll libraries under /usr/bin/. This is inconvenient to find the real
> >>executable applications (*.exe). Since *.dll files are only libraries, they
> >>are not necessary to have the attribute of "x". Thus, I run the command
> >>"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the
> >>terminal and failed to restart Cygwin. I started my  older version of Cygwin
> >>(I did not deleted it after installing a new version), and added "x" to the
> >>previous *.dll files. The dead Cygwin revived.
> >>
> >>I am confused why /usr/bin/*.dll should be executable. I thought they were
> >>only library files. When I tried to run a dll file, bash says "cannot
> >>execute binary file". Are there some hidden stories?
> >DLLs are executables thus they need the +x bit. This is a Windows thing.
> >
> 
> If this is a windows thing, removing the x bit should not affect
> Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process.  As Václav wrote, it's a Windows
thing.


Corinna

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

--
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: Why /usr/bin/*.dll must be executable?

[Nellis, Kenneth]

From: Corinna Vinschen
> Windows requires the x bit for DLLs to be loadable as executable code
> into the address space of a process.  As Václav wrote, it's a Windows
> thing.

So, I had to play with "chmod -x cyg*.dll" and, of course, it 
totally hosed Cygwin. I recovered by reinstalling from scratch 
only after realizing that ATTRIB did not have an option to re-
establish X--we're talking XP here.  So, as this is a Windows 
thing, wondering how, through Windows, I could restore execute 
access to the DLLs.

--Ken Nellis

Change dark blue terminal colour

[Dotan Cohen]

Hello all, I am a new Cygwin user. I have been looking online for a
way to change the default ANSI BLUE to CYAN, as it is very difficult
to see on the black terminal background. However, all I have been able
to find were suggestions to use Putty's terminal or Console 2 instead
of Cygwin's terminal. Is there no way to make this change in Cygwin's
terminal? A simple .bashrc .vimrc or .dir_colors change is not
appropriate as I often SSH into many other machines, not all of which
I can play with the bash or VIM colours.

Thank you.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.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: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 1:25 PM, Nellis, Kenneth wrote:

From: Corinna Vinschen

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process.  As Václav wrote, it's a Windows
thing.


So, I had to play with "chmod -x cyg*.dll" and, of course, it
totally hosed Cygwin. I recovered by reinstalling from scratch
only after realizing that ATTRIB did not have an option to re-
establish X--we're talking XP here.  So, as this is a Windows
thing, wondering how, through Windows, I could restore execute
access to the DLLs.


What's wrong with "chmod +x cyg*.dll"?


--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are listed
(Display all 262 possibilities? (y or n) y). I find that many of them are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe). Since *.dll files are only libraries, they
are not necessary to have the attribute of "x". Thus, I run the command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed the
terminal and failed to restart Cygwin. I started my  older version of Cygwin
(I did not deleted it after installing a new version), and added "x" to the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought they were
only library files. When I tried to run a dll file, bash says "cannot
execute binary file". Are there some hidden stories?

DLLs are executables thus they need the +x bit. This is a Windows thing.


If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process.  As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried 
removing the x bit of an executable file blastall.exe (chmod a-x 
blastall.exe); the file can not be executed under Cygwin, but still can 
be executed under cmd console of Windows. It seems that Windows does not 
honor the rwx bits assigned by Cygwin.


Is there a detailed description of the starting process of Cygwin 
system? Or, how does Cygwin interact with *.dll files?


After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and 
perl could not be started any more. This could be cured by ran "chmod 
a+x /usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary 
executables will communicate with their corresponding *.dll files when 
executed. The *.dll provide the required functions and subroutines and 
that's enough. There is no need to mark *.dll with an x bit.


I have no strong background of computer science. Maybe there is some 
basic knowledge beyond my imagination. Hope you can help disclose it to 
me. 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: Change dark blue terminal colour

[Larry Hall (Cygwin)]

On 4/20/2012 1:26 PM, Dotan Cohen wrote:

Hello all, I am a new Cygwin user. I have been looking online for a
way to change the default ANSI BLUE to CYAN, as it is very difficult
to see on the black terminal background. However, all I have been able
to find were suggestions to use Putty's terminal or Console 2 instead
of Cygwin's terminal. Is there no way to make this change in Cygwin's
terminal? A simple .bashrc .vimrc or .dir_colors change is not
appropriate as I often SSH into many other machines, not all of which
I can play with the bash or VIM colours.


If you're using mintty, edit ~/.minttyrc or change directly through the
"Options" dialog in the System menu.  If you're using cmd.exe (you should
update), change the colors through the "Properties" and "Default" dialogs
in the System menu.

--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-21 1:29, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:25 PM, Nellis, Kenneth wrote:

From: Corinna Vinschen

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process.  As Václav wrote, it's a Windows
thing.


So, I had to play with "chmod -x cyg*.dll" and, of course, it
totally hosed Cygwin. I recovered by reinstalling from scratch
only after realizing that ATTRIB did not have an option to re-
establish X--we're talking XP here.  So, as this is a Windows
thing, wondering how, through Windows, I could restore execute
access to the DLLs.


What's wrong with "chmod +x cyg*.dll"?



It doesn't work any more. You cannot restart a new terminal, either. You 
will be trapped here.



--
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: Why /usr/bin/*.dll must be executable?

[Nellis, Kenneth]

From: Larry Hall (Cygwin)
> What's wrong with "chmod +x cyg*.dll"?

As I said, Cygwin was hosed, so I couldn't enter
that command. 

--Ken Nellis

Re: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 1:32 PM, De-Jian Zhao wrote:

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are listed
(Display all 262 possibilities? (y or n) y). I find that many of them are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe). Since *.dll files are only libraries,
they
are not necessary to have the attribute of "x". Thus, I run the command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed
the
terminal and failed to restart Cygwin. I started my older version of
Cygwin
(I did not deleted it after installing a new version), and added "x" to
the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought they were
only library files. When I tried to run a dll file, bash says "cannot
execute binary file". Are there some hidden stories?

DLLs are executables thus they need the +x bit. This is a Windows thing.


If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried
removing the x bit of an executable file blastall.exe (chmod a-x
blastall.exe); the file can not be executed under Cygwin, but still can be
executed under cmd console of Windows. It seems that Windows does not honor
the rwx bits assigned by Cygwin.

Is there a detailed description of the starting process of Cygwin system?
Or, how does Cygwin interact with *.dll files?

After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl
could not be started any more. This could be cured by ran "chmod a+x
/usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary executables
will communicate with their corresponding *.dll files when executed. The
*.dll provide the required functions and subroutines and that's enough.
There is no need to mark *.dll with an x bit.

I have no strong background of computer science. Maybe there is some basic
knowledge beyond my imagination. Hope you can help disclose it to me. Thanks.


Cygwin DLLs are no different than native Windows DLLs when it comes to
loading them.  The Windows loader is responsible for loading them.  So
we're stuck with whatever restrictions the Windows loader imposes on
Windows apps.


--
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 1.7.13-1: can't execute shell scripts on samba share

[Len Giambrone]

-Len




On Apr 19, 2012, at 4:29 AM, Michel Bardiaux wrote:

> 2 suggestions:
> 
> 1. What happens if len.sh is in your Cygwin home, that is on the local
> drive?

lgiambro@lorien ~
$ ./len.sh
it works

> 
> 2. What happens with "sh -x ./len.sh" (on the network drive)?
> 

lgiambro@lorien //kitserver/kits
$ sh -x ./len.sh
+ echo it works
it works


> HaND,
> 
> -Original Message-
> 
> No.  That works.  presumably because it's executing "bash" and not the
> script itself.
> 
> -Len
> 
> 
> 
> 
> On Apr 18, 2012, at 1:49 PM, Earnie Boyd wrote:
> 
>> On Wed, Apr 18, 2012 at 11:44 AM, Len Giambrone 
>>  wrote:
>>> I'm can't execute shell scripts on a samba share served by our linux
> boxes.
>>> 
>>> lgiambro@lorien //kitserver/kits
>>> $ ls -la len.sh
>>> -rwx-- 1 lgiambro releng 24 Apr 18 10:48 len.sh
>>> 
>>> lgiambro@lorien //kitserver/kits
>>> $ cat len.sh
>>> #!/bin/sh
>>> echo it works
>>> 
>>> lgiambro@lorien //kitserver/kits
>>> $ ./len.sh
>>> -bash: ./len.sh: Permission denied
>> 
>> I suppose the same happens if you execute len.sh similar to the
> following?
>> 
>> $ bash -x ./len.sh
>> 
> 
> --
> 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
> 


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

Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

[James Johnston]

Hi,

Before I describe the issues I think I've found, I'd like to clarify my
understanding.  In the past, I have periodically run into random issues when
starting new programs from the bash shell.  The errors are always random and
cryptic ("bad address", etc. - that sort of thing).  Today this issue came
to a head on one installation of Cygwin 1.7.9, where simply opening the bash
shell could not happen without a large number of these errors, due to
commands in the /etc/profile failing.  Having been reading on this mailing
list, my understanding is that this is an issue with basing of DLLs - is
that correct?  Specifically, that Cygwin requires that a child process
created by fork() to have its Cygwin DLLs loaded into the child process's
address space in the exact same places as they are loaded in the parent
process, correct?  And it is also correct that Cygwin does not care where
Windows / operating system DLLs are loaded, provided that they do not
conflict with Cygwin DLLs or any heap/stack allocated by the Cygwin parent
process?

I assume the answer to all these questions is yes.  Please correct me if I
am wrong!  So, I then decided to analyze the address space of bash.exe to
see if I could determine the source of the problem, using VMMap at
http://technet.microsoft.com/en-us/sysinternals/dd535533 to see where each
DLL is loaded.  (ListDLLs, another SysInternals tool is handy, too).  I have
checked it against a clean Cygwin installation with default packages
installed, which I just installed today in a clean virtual machine.  The
issues still exist in that virtual machine, so I don't feel it is something
specific to my particular configuration.

In both cases, rebaseall was run as part of setup.

An analysis of bash.exe in VMMap on a clean Windows 7 computer shows the
following PE images were loaded in bash's address space (I have cut out most
operating system DLLs at the end of address space):

 * 0x0004: C:\Windows\System32\apisetschema.dll (ASLR)
 * 0x0040: C:\cygwin\bin\bash.exe
 * 0x6100: C:\cygwin\bin\cygwin1.dll
 * 0x6F4A: C:\Windows\SysWOW64\winrnr.dll (ASLR)
 * 0x6F50: C:\cygwin\bin\cygncursesw-10.dll
 * 0x6F71: C:\cygwin\bin\cygreadline7.dll (ASLR)
 * 0x6F74: C:\Windows\SysWOW64\pnrpnsp.dll (ASLR)
 * 0x6F76: C:\Windows\SysWOW64\NapiNSP.dll (ASLR)
 * 0x6F78: C:\cygwin\bin\cygintl-8.dll
 * 0x6F7E: C:\cygwin\bin\cygiconv-2.dll
 * 0x6FA8: C:\cygwin\bin\cyggcc_s-1.dll
 * 0x7372: C:\Windows\System32\wow64cpu.dll (ASLR)
 *  rest of system DLLs 

Here is the same thing, but on a Windows XP computer (remember, XP does not
support ASLR):

 * 0x0040: C:\cygwin\bin\bash.exe
 * 0x6100: C:\cygwin\bin\cygwin1.dll
 * 0x629C: C:\WINDOWS\system32\lpk.dll
 * 0x6FB7: C:\cygwin\bin\cygreadline7.dll
 * 0x6FC2: C:\cygwin\bin\cygncursesw-10.dll
 * 0x6FDA: C:\cygwin\bin\cygintl-8.dll
 * 0x6FDB: C:\cygwin\bin\cygiconv-2.dll
 * 0x6FF9: C:\cygwin\bin\cyggcc_s-1.dll
 * 0x71A5: C:\WINDOWS\system32\mswsock.dll
 *  rest of system DLLs 

Now, right off I see two problems with the Cygwin DLLs; here they are with
some possible solutions:

1.  cygreadline7.dll was compiled with /DYNAMICBASE, as indicated by the
ASLR flag (you can confirm via Visual C++ dumpbin command).  See
http://msdn.microsoft.com/en-us/library/bb384887.aspx for more.  What's
really important to note, is that by default this is turned ON in newer
Visual C++ linkers.  I'm not sure why this flag was set, but perhaps the
package maintainer forgot to turn it off?  Anyway, the DYNAMICBASE flag
means that the operating system is free to randomly rebase the DLL anywhere
it feels like: a sure recipe for disaster if fork() requires the DLL to be
loaded in the same place every time!!  In practice this is not usually an
issue because the operating system only rebases once so that the image
memory pages can still be reused across multiple processes.  But I think
that isn't set in stone: it's free to base it in one place for one process,
and then base it somewhere else for a different process (I have observed
this on the problem computer where bash couldn't even run /etc/profile).

It seems to me that the cygreadline7 maintainer needs to be sure this flag
is turned off.  And maybe there are other EXE or DLL files in Cygwin that
have this flag turned on?  I haven't checked.  In that case, perhaps the
rebaseall command could also turn the DYNAMICBASE flag off while it is doing
the rebase?  Additionally, rebaseall could operate on EXE files too, just to
turn off the DYNAMICBASE flag.  That way there would be no concern about
package maintainers who forget to turn off this flag.

2.  Cygwin DLL basing seems to start at 0x6100, and continues until
almost 0x7000.  This is too close to the upper end of address space: it
has a high risk of collision with operating system DLLs and ASLR-relocated
images.  In my opinion, starting the rebase at an address like 0x3000 or
0x400

Re: cygwin 1.7.13-1: can't execute shell scripts on samba share

[Len Giambrone]

-Len




On Apr 19, 2012, at 7:37 AM, Earnie Boyd wrote:

> On Wed, Apr 18, 2012 at 3:44 PM, Len Giambrone
>  wrote:
>> No.  That works.  presumably because it's executing "bash" and not
>> the script itself.
> 
> http://cygwin.com/acronyms/#TOFU
> 
> And does the script contain #! /bin/sh or the like on line 1 column 1?
> 

lgiambro@lorien ~
$ cat len.sh
#!/bin/sh
echo it works



> -- 
> Earnie
> -- https://sites.google.com/site/earnieboyd
> 
> --
> 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
> 


--
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: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 1:37 PM, De-Jian Zhao wrote:

On 2012-4-21 1:29, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:25 PM, Nellis, Kenneth wrote:

From: Corinna Vinschen

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


So, I had to play with "chmod -x cyg*.dll" and, of course, it
totally hosed Cygwin. I recovered by reinstalling from scratch
only after realizing that ATTRIB did not have an option to re-
establish X--we're talking XP here. So, as this is a Windows
thing, wondering how, through Windows, I could restore execute
access to the DLLs.


What's wrong with "chmod +x cyg*.dll"?



It doesn't work any more. You cannot restart a new terminal, either. You
will be trapped here.


Ah, I didn't realize that Ken did this in /bin.  You could use cacls in
this case as an alternative to reinstalling.

--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-21 1:40, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:32 PM, De-Jian Zhao wrote:

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" 
are listed
(Display all 262 possibilities? (y or n) y). I find that many of 
them are
*.dll libraries under /usr/bin/. This is inconvenient to find the 
real
executable applications (*.exe). Since *.dll files are only 
libraries,

they
are not necessary to have the attribute of "x". Thus, I run the 
command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I 
closed

the
terminal and failed to restart Cygwin. I started my older version of
Cygwin
(I did not deleted it after installing a new version), and added 
"x" to

the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought 
they were
only library files. When I tried to run a dll file, bash says 
"cannot

execute binary file". Are there some hidden stories?
DLLs are executables thus they need the +x bit. This is a Windows 
thing.



If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried
removing the x bit of an executable file blastall.exe (chmod a-x
blastall.exe); the file can not be executed under Cygwin, but still 
can be
executed under cmd console of Windows. It seems that Windows does not 
honor

the rwx bits assigned by Cygwin.

Is there a detailed description of the starting process of Cygwin 
system?

Or, how does Cygwin interact with *.dll files?

After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and 
perl

could not be started any more. This could be cured by ran "chmod a+x
/usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary 
executables

will communicate with their corresponding *.dll files when executed. The
*.dll provide the required functions and subroutines and that's enough.
There is no need to mark *.dll with an x bit.

I have no strong background of computer science. Maybe there is some 
basic
knowledge beyond my imagination. Hope you can help disclose it to me. 
Thanks.


Cygwin DLLs are no different than native Windows DLLs when it comes to
loading them.  The Windows loader is responsible for loading them.  So
we're stuck with whatever restrictions the Windows loader imposes on
Windows apps.



Yes. But does Windows loader can see the x bit assigned by Cygwin, a 
quite different OS?


At least, *.exe does not respect or even is blind to the -x operation of 
Cygwin, as abovementioned.



--
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: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 1:47 PM, De-Jian Zhao wrote:

On 2012-4-21 1:40, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:32 PM, De-Jian Zhao wrote:

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are
listed
(Display all 262 possibilities? (y or n) y). I find that many of them
are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe). Since *.dll files are only libraries,
they
are not necessary to have the attribute of "x". Thus, I run the command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I closed
the
terminal and failed to restart Cygwin. I started my older version of
Cygwin
(I did not deleted it after installing a new version), and added "x" to
the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought they
were
only library files. When I tried to run a dll file, bash says "cannot
execute binary file". Are there some hidden stories?

DLLs are executables thus they need the +x bit. This is a Windows thing.


If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried
removing the x bit of an executable file blastall.exe (chmod a-x
blastall.exe); the file can not be executed under Cygwin, but still can be
executed under cmd console of Windows. It seems that Windows does not honor
the rwx bits assigned by Cygwin.

Is there a detailed description of the starting process of Cygwin system?
Or, how does Cygwin interact with *.dll files?

After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl
could not be started any more. This could be cured by ran "chmod a+x
/usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary executables
will communicate with their corresponding *.dll files when executed. The
*.dll provide the required functions and subroutines and that's enough.
There is no need to mark *.dll with an x bit.

I have no strong background of computer science. Maybe there is some basic
knowledge beyond my imagination. Hope you can help disclose it to me.
Thanks.


Cygwin DLLs are no different than native Windows DLLs when it comes to
loading them. The Windows loader is responsible for loading them. So
we're stuck with whatever restrictions the Windows loader imposes on
Windows apps.



Yes. But does Windows loader can see the x bit assigned by Cygwin, a quite
different OS?


Cygwin is not an O/S.  The basis for Cygwin is the emulation _DLL_, 
cygwin1.dll.  Cygwin executables and DLLs are Windows binaries, subject

to whatever limitations the Windows loader has.  That's it.  If you're
not happy about that, you should complain to MS about it.


--
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: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 1:47 PM, De-Jian Zhao wrote:



Oh and...


At least, *.exe does not respect or even is blind to the -x operation of
Cygwin, as abovementioned.


Cygwin creates its Windows ACLs to support POSIX permisssions.  See the
Cygwin Users Guide for 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: Change dark blue terminal colour

[Dotan Cohen]

On Fri, Apr 20, 2012 at 13:34, Larry Hall wrote:
> If you're using mintty, edit ~/.minttyrc or change directly through the
> "Options" dialog in the System menu.  If you're using cmd.exe (you should
> update), change the colors through the "Properties" and "Default" dialogs
> in the System menu.
>

Thanks. The $TERM variable says that it is xterm. In the terminal's
context menu there is no options for overriding specifc colours, like
Putty has.

Is there a general xterm configuration for overriding a specific
colour? A few minutes on google didn't uncover anything.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-21 1:57, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:47 PM, De-Jian Zhao wrote:

On 2012-4-21 1:40, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:32 PM, De-Jian Zhao wrote:

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" 
are

listed
(Display all 262 possibilities? (y or n) y). I find that many 
of them

are
*.dll libraries under /usr/bin/. This is inconvenient to find 
the real
executable applications (*.exe). Since *.dll files are only 
libraries,

they
are not necessary to have the attribute of "x". Thus, I run the 
command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. 
I closed

the
terminal and failed to restart Cygwin. I started my older 
version of

Cygwin
(I did not deleted it after installing a new version), and 
added "x" to

the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I 
thought they

were
only library files. When I tried to run a dll file, bash says 
"cannot

execute binary file". Are there some hidden stories?
DLLs are executables thus they need the +x bit. This is a 
Windows thing.



If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried
removing the x bit of an executable file blastall.exe (chmod a-x
blastall.exe); the file can not be executed under Cygwin, but still 
can be
executed under cmd console of Windows. It seems that Windows does 
not honor

the rwx bits assigned by Cygwin.

Is there a detailed description of the starting process of Cygwin 
system?

Or, how does Cygwin interact with *.dll files?

After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" 
and perl

could not be started any more. This could be cured by ran "chmod a+x
/usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary 
executables
will communicate with their corresponding *.dll files when 
executed. The
*.dll provide the required functions and subroutines and that's 
enough.

There is no need to mark *.dll with an x bit.

I have no strong background of computer science. Maybe there is 
some basic

knowledge beyond my imagination. Hope you can help disclose it to me.
Thanks.


Cygwin DLLs are no different than native Windows DLLs when it comes to
loading them. The Windows loader is responsible for loading them. So
we're stuck with whatever restrictions the Windows loader imposes on
Windows apps.



Yes. But does Windows loader can see the x bit assigned by Cygwin, a 
quite

different OS?


Cygwin is not an O/S.  The basis for Cygwin is the emulation _DLL_, 
cygwin1.dll.  Cygwin executables and DLLs are Windows binaries, 
subject to whatever limitations the Windows loader has.  That's it.  
If you're not happy about that, you should complain to MS about it.



Then, what limitations does the Windows loader have?
As far as I know, there is no x bits for windows, right? How does the 
"chmod a-x" affect the file behavior under Windows if this is a Windows 
thing? I am completely confused. When I ran "chmod a-x *.dll", I assumed 
that these dll files were not executed directly under Cygwin or Windows; 
they were just some files storing the required functions or something; 
removing the x bits should not affect the behavior of Cygwin and 
Windows. If have run "chmod a-x" on the Windows system dll files, that 
will lead to the corruption of Windows, right? Thank God. I didn't do that.




--
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: Why /usr/bin/*.dll must be executable?

[Larry Hall (Cygwin)]

On 4/20/2012 2:21 PM, De-Jian Zhao wrote:

On 2012-4-21 1:57, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:47 PM, De-Jian Zhao wrote:

On 2012-4-21 1:40, Larry Hall (Cygwin) wrote:

On 4/20/2012 1:32 PM, De-Jian Zhao wrote:

On 2012-4-21 0:27, Corinna Vinschen wrote:

On Apr 21 00:17, De-Jian Zhao wrote:

On 2012-4-20 21:07, Václav Zeman wrote:

On 20 April 2012 15:02, De-Jian Zhao wrote:

Hi,

When I type "cyg" and Tab, many executables starting with "cyg" are
listed
(Display all 262 possibilities? (y or n) y). I find that many of them
are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe). Since *.dll files are only libraries,
they
are not necessary to have the attribute of "x". Thus, I run the
command
"chmod a-x /usr/bin/*.dll". Unexpectedly, cygwin is corrupted. I
closed
the
terminal and failed to restart Cygwin. I started my older version of
Cygwin
(I did not deleted it after installing a new version), and added
"x" to
the
previous *.dll files. The dead Cygwin revived.

I am confused why /usr/bin/*.dll should be executable. I thought they
were
only library files. When I tried to run a dll file, bash says "cannot
execute binary file". Are there some hidden stories?

DLLs are executables thus they need the +x bit. This is a Windows
thing.


If this is a windows thing, removing the x bit should not affect
Cygwin. Instead, Cygwin is corrupted after removing the x bit.

Windows requires the x bit for DLLs to be loadable as executable code
into the address space of a process. As Václav wrote, it's a Windows
thing.


Can Windows see the rwx bits assigned by Cygwin to the files? I tried
removing the x bit of an executable file blastall.exe (chmod a-x
blastall.exe); the file can not be executed under Cygwin, but still can be
executed under cmd console of Windows. It seems that Windows does not
honor
the rwx bits assigned by Cygwin.

Is there a detailed description of the starting process of Cygwin system?
Or, how does Cygwin interact with *.dll files?

After starting Cygwin, I ran "chmod a-x /usr/bin/cygperl5_10.dll" and perl
could not be started any more. This could be cured by ran "chmod a+x
/usr/bin/cygperl5_10.dll". It seems to me that the Cygwin binary
executables
will communicate with their corresponding *.dll files when executed. The
*.dll provide the required functions and subroutines and that's enough.
There is no need to mark *.dll with an x bit.

I have no strong background of computer science. Maybe there is some basic
knowledge beyond my imagination. Hope you can help disclose it to me.
Thanks.


Cygwin DLLs are no different than native Windows DLLs when it comes to
loading them. The Windows loader is responsible for loading them. So
we're stuck with whatever restrictions the Windows loader imposes on
Windows apps.



Yes. But does Windows loader can see the x bit assigned by Cygwin, a quite
different OS?


Cygwin is not an O/S. The basis for Cygwin is the emulation _DLL_,
cygwin1.dll. Cygwin executables and DLLs are Windows binaries, subject to
whatever limitations the Windows loader has. That's it. If you're not
happy about that, you should complain to MS about it.


Then, what limitations does the Windows loader have?


You might want to do a search to find some information about the Windows
loader.  This isn't really the forum to learn about such things.


As far as I know, there is no x bits for windows, right?


Windows doesn't use POSIX (rwx) permissions.  It uses ACLs (Access Control
Lists) for permissions.  Cygwin uses the ACLs to simulate POSIX permissions
for POSIX apps under it's control.  Setting or unsetting "x" is telling
Windows you want to change the executable permissions of the file in
question.


How does the "chmod
a-x" affect the file behavior under Windows if this is a Windows thing? I am
completely confused. When I ran "chmod a-x *.dll", I assumed that these dll
files were not executed directly under Cygwin or Windows; they were just
some files storing the required functions or something; removing the x bits
should not affect the behavior of Cygwin and Windows. If have run "chmod
a-x" on the Windows system dll files, that will lead to the corruption of
Windows, right? Thank God. I didn't do that.


Corruption is not a term I would use but if you're asking me if it's safe
for you to go around and change the permissions of any and all files on
your system, I would have to recommend against you doing so.

Changing the permissions of files on your system isn't something you should
do lightly.  Think of it as playing around in the registry.  If you don't
know the consequences, don't do it.

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

Re: Why /usr/bin/*.dll must be executable?

[Jon TURNEY]

On 20/04/2012 14:02, De-Jian Zhao wrote:
> When I type "cyg" and Tab, many executables starting with "cyg" are listed
> (Display all 262 possibilities? (y or n) y). I find that many of them are
> *.dll libraries under /usr/bin/. This is inconvenient to find the real
> executable applications (*.exe).

'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't
want to see those pesky dlls.

See /usr/share/doc/Cygwin/bash.README

--
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: Change dark blue terminal colour

[Andy Koppe]

On 20 April 2012 18:26, Dotan Cohen wrote:
> Hello all, I am a new Cygwin user. I have been looking online for a
> way to change the default ANSI BLUE to CYAN, as it is very difficult
> to see on the black terminal background. However, all I have been able
> to find were suggestions to use Putty's terminal or Console 2 instead
> of Cygwin's terminal. Is there no way to make this change in Cygwin's
> terminal?

Assuming you're using Cygwin's default terminal, stick this into ~/.minttyrc:

Blue=0,0,191

And in case you want to change bold blue as well:

BoldBlue=64,64,255

Adjust the RGB values as desired. The values shown are the default ones.

Andy

--
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: Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

[Christopher Faylor]

On Fri, Apr 20, 2012 at 05:44:38PM -, James Johnston wrote:
>[snip]
>...  Today this issue came
>to a head on one installation of Cygwin 1.7.9,...
>[snip]
>Thoughts, anyone?

Yep.  Update your Cygwin installation.  You're four revisions out of
date.

It should come not too great a surprise that we've had extensive
discussions about this issue and have made some changes in recent
releases.

--
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: Why /usr/bin/*.dll must be executable?

[Mike Kaganski]

On 4/21/2012 5:21 AM, De-Jian Zhao wrote:

...
Then, what limitations does the Windows loader have?
As far as I know, there is no x bits for windows, right? How does the 
"chmod a-x" affect the file behavior under Windows if this is a 
Windows thing? I am completely confused. When I ran "chmod a-x *.dll", 
I assumed that these dll files were not executed directly under Cygwin 
or Windows; they were just some files storing the required functions 
or something; removing the x bits should not affect the behavior of 
Cygwin and Windows. If have run "chmod a-x" on the Windows system dll 
files, that will lead to the corruption of Windows, right? Thank God. 
I didn't do that.




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

The term "Executable" is not limited to the files that are run directly. 
It rather shows that this file contains executable code, and in case of 
DLLs, this is almost always true (unless they are resource-only DLLs; 
note that sometimes unaware programmers create DLLs wich contain only 
resources, but fail to create proper resource-only DLLs, ant they still 
contain loading and unloading code).
Any code that may be executed (directly or indirectly) must have "x" 
under *nix. Windows had tried to make somewhat similar (with the same 
security concerns in mind) in its NT family, but it had to deal with 
file systems that have no notion of "executability" (FAT), so the notion 
was introduced in NTFS, but is not honored (thus, "execute" ACL 
permission is useless in Windows).
As Cygwin tries to emulate *nix, I suppose, it explicitly checks 
executable bit on loading files. So it's not correct to state that "this 
is completely Windows loader thing", but this thing is conceptually 
correct, so live with it.


--
Best regards, Mike.


--
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: Change dark blue terminal colour

[Andrew DeFaria]

On 4/20/2012 11:05 AM, Dotan Cohen wrote:

On Fri, Apr 20, 2012 at 13:34, Larry Hall wrote:

If you're using mintty, edit ~/.minttyrc or change directly through the
"Options" dialog in the System menu.  If you're using cmd.exe (you should
update), change the colors through the "Properties" and "Default" dialogs
in the System menu.


Thanks. The $TERM variable says that it is xterm. In the terminal's
context menu there is no options for overriding specifc colours, like
Putty has.
It doesn't matter what $TERM says. It matters what terminal emulator you 
are running. If mintty then follow the suggestion above...

Is there a general xterm configuration for overriding a specific
colour? A few minutes on google didn't uncover anything.
If you are using xterm, have you tried man xterm? Either that or 
http://lmgtfy.com/?q=xterm. It's the 3rd entry. (My question is what 
were you doing for a few minutes on Google such that you didn't think to 
simply type in xterm!)

--
Andrew DeFaria 
Why do people point to their wrist when asking for the time, but not to 
their crotch when they ask where the toilet is?



--
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: Why /usr/bin/*.dll must be executable?

[De-Jian Zhao]

On 2012-4-21 3:06, Jon TURNEY wrote:

On 20/04/2012 14:02, De-Jian Zhao wrote:

When I type "cyg" and Tab, many executables starting with "cyg" are listed
(Display all 262 possibilities? (y or n) y). I find that many of them are
*.dll libraries under /usr/bin/. This is inconvenient to find the real
executable applications (*.exe).

'export EXECIGNORE=*.dll' is a cygwin extension to bash to tell it you don't
want to see those pesky dlls.

See /usr/share/doc/Cygwin/bash.README


Cool! That's just what I need! Thanks, Jon.


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