Running grep and other cygwin commands from cmd.exe

[Tzuriel]

I hope I am asking this correctly.  I would like to be able to open a regular
cmd.exe (Windows shell) window and run cygwin commands from there without
opening bash in it's own command window.  Can this be done?  Basically, I want
to use .cmd and .bat scripts that use grep within scripts that run in a Windows
environment.  I hope this makes sense!

Thanks,

Tzuriel


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated [experimental]: bash-3.1-2

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A new release of bash, 3.1-2, is available for experimental use.

NEWS:
=
This is a minor patch update to the previous experimental bash-3.1-1.  It
adds four new upstream patches (documentation updates, minimal features
compilation fix, local array parsing fix, and failed tilde expansion fix),
plus a patch to fix a regression from 3.0 where bash no longer behaved as
a login shell when started with argv[0] beginning with '-'.  A list of
changes from the NEWS file was attached to
http://cygwin.com/ml/cygwin-announce/2005-12/msg00039.html; see also
/usr/share/doc/bash-3.1/.  I plan on making this version the current
version of bash in a couple of weeks if testing does not turn up any
severe problems.

DESCRIPTION:

Bash is an sh-compatible shell that incorporates useful features from the
Korn shell (ksh) and C shell (csh).  It is intended to conform to the IEEE
POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers functional
improvements over sh for both programming and interactive use. In
addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to Linux distributions.

UPDATE:
===
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.
Save it and run setup, answer the questions and pick up 'bash' in the
'Base' category (it should already be selected).  You will need to use the
"Exp" radio button to get this experimental version.

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

- --
Eric Blake
volunteer cygwin bash maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to 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:

[EMAIL PROTECTED]

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

http://sources.redhat.com/lists.html#unsubscribe-simple

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3uvH84KuGfSFAYARAmnYAKC22aY6B/Ra1fRVlLOgyjshgDDrfwCgtlQt
dVZf36sZFrtM6oXHawLQbbU=
=LHip
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Installation Errors

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to jgriffin on 1/30/2006 11:29 AM:
> I'm trying to install Cygwin on a stand alone computer. Here is what I'm 
> doing:

Most of this looked okay.  However, you probably installed without wiping
out the previous installation, or with a second cygwin1.dll somewhere in
the path.  Attaching the output of cygcheck -svr, as a text attachment,
would help.

> 
> Errors
> Most of the errors are coming from the post-install scripts. I get an error 
> dialog stating that cygpopt-0.dll could not be found.

Somehow, you missed a dependency when building your cd.  Without all the
required packages, you can't expect the installation to work properly.
Try again (also, you can use cygcheck -p cygpopt-0.dll to find out what
package you missed).

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3uU184KuGfSFAYARAjU/AKCM6+DY/6Neyu+i7FW7UdyL/Jb6UwCgwHzd
R/4TPB4YsGM7xBnHHWFTO1Q=
=iTvL
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Standalone DirectX Package

[Torsten Giebl]

Hello !


> Those are not Microsoft's; they have been completely re-implemented from
> scratch by volunteers using no MS code.  If you are just redistributing
> MS's headers from the PDSK or DXSDK you are most certainly violating a
> license somewhere.


Ah. Good to know. I will look at the DX SDK Package
and will try to find out if the dist. from converted libs
is legal.


CU


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Standalone DirectX Package

[Brian Dessent]

Torsten Giebl wrote:

> What about the DirectX Libs. that come with CYGWIN ?

Those are not Microsoft's; they have been completely re-implemented from
scratch by volunteers using no MS code.  If you are just redistributing
MS's headers from the PDSK or DXSDK you are most certainly violating a
license somewhere.

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Standalone DirectX Package

[Torsten Giebl]

Hello !


> I'm not sure if this is entirely legal, as I assume you have just
> converted the libraries and repackaged all the headers.  Microsoft may have
> a bit of an issue with it.


What about the DirectX Libs. that come with CYGWIN ?



CU


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Standalone DirectX Package

[Chris Sutcliffe]

> I put together the latest DirectX SDK ( Dec. 2005 ) for CYGWIN / Mingw :
>
> http://www.syntheticsw.com/~wizard/tmp/SDL/cyg-directx-devel.zip

I'm not sure if this is entirely legal, as I assume you have just
converted the libraries and repackaged all the headers.  Microsoft may
have a bit of an issue with it.

Chris

--
Chris Sutcliffe
http://emergedesktop.org

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Standalone DirectX Package

[Torsten Giebl]

Hello !


> /usr/local/lib vs /usr/lib?


No. The problem is just when the Win32Api Package
is updated, all my DirectX Libs. aso. will be overwritten.
As i want to use the standard CYGWIN dirs.

I put together the latest DirectX SDK ( Dec. 2005 ) for CYGWIN / Mingw :

http://www.syntheticsw.com/~wizard/tmp/SDL/cyg-directx-devel.zip

It would be cool to convert this into a CYGWIN Package,
add it to the CYGWIN dist. and delete the DirectX Files in the Win32API
Package.


CU

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where is SCP

[Christopher Faylor]

On Mon, Jan 30, 2006 at 07:01:04PM -0600, Yaakov S (Cygwin Ports) wrote:
>Igor Peshansky wrote:
>>Exactly where were you trying to search for it?  The answer to most
>>queries of "where is program foo" is the Cygwin package search page at
>> (also mentioned in the FAQ entry
>>).  You can
>>use Perl regular expressions to get better matches for short names, e.g.,
>>"\bscp\b" for a whole-word "scp" search.
>
>BTW, now there's also 'cygcheck -p'.  Maybe this should be added to the 
>aforementioned FAQ?

Yes, definitely.

Joshua?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where is SCP

[Yaakov S (Cygwin Ports)]

Igor Peshansky wrote:

Exactly where were you trying to search for it?  The answer to most
queries of "where is program foo" is the Cygwin package search page at
 (also mentioned in the FAQ entry
).  You can
use Perl regular expressions to get better matches for short names, e.g.,
"\bscp\b" for a whole-word "scp" search.


BTW, now there's also 'cygcheck -p'.  Maybe this should be added to the 
aforementioned FAQ?


$ cygcheck -p scp.exe
Found 2 matches for scp.exe.
openssh/openssh-4.1p1-2 The OpenSSH server and client programs
openssh/openssh-4.2p1-1 The OpenSSH server and client programs


Yaakov

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] New Package: pygtk2-2.6.3-1

[Yaakov S (Cygwin Ports)]

The following package has been added to the Cygwin net release:

*** pygtk2-2.6.3-1

PyGTK is a set of Python bindings for the Glib-2, ATK, Pango, GTK+-2,
and LibGlade-2 libraries, which allows GTK+ apps to be written in pure
Python.

Yaakov

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

[EMAIL PROTECTED]

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

http://sources.redhat.com/lists.html#unsubscribe-simple

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



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MSYS path behavior in Cygwin

[Igor Peshansky]

On Mon, 30 Jan 2006, Brian Dessent wrote:

> tom wrote:
>
> > I guess the two will be mutually exclusive, unless you Cygwin devs see
> > some reason to merge some of Earnie's work.  I'm have to believe
> > there's some reason why it hasn't been done though.  I'm sure it's
> > non-trivial to say the least.
> >
> > Thanks for the help anyways!  Cygwin and msys make life in Win32land
> > bearable.
>
> To do that would go against the grain of what Cygwin is trying to
> accomplish: provide a full posix environment.  So to have
> argument-translation code sort of defeats that purpose since all Cygwin
> programs are supposed to recognise posix paths.
>
> Now in reality, everyone has to run a non-Cygwin program from time to
> time, so of course there will be times where you run up against this.
> But the question becomes, when should the library translate paths, and
> when should it leave them alone?  Because you can't just unconditionally
> do it.  The way MSYS handles this is by assuming that everything in the
> MSYS bin directory is a MSYS binary that can handle posix paths, and
> that everything else is a win32/mingw app that needs win32 paths.  Now
> that's a rather stark and arbitrary distinction.  It works for MSYS
> since it's intended to be a rather minimal system, just enough to build
> packages using auto{conf,make},libtool.  But I think for Cygwin this
> would be way too restrictive.

Unfortunately, sometimes you can't do this even if you know that a Win32
program is being invoked.  The problem is that an arbitrary string with a
"/" in it may or may not be a path to a file -- and the only way to know
is to understand the semantics of the arguments.  Since you don't always
know those semantics, doing this in general is impossible.

> The workaround that I think most people use is a wrapper script that
> essentially just runs "cygpath -w" on each argument and then execs $1.
> So you can type "wrapper win32program /posix/path/to/file" and it ends
> up running "win32program c:/win32/path/to/file".  If you do it right,
> you can make this quite generic, so that you just prepend "wrapper" (or
> whatever you want to call it.)
>
> Below is one that I use in my .bashrc that calls perl.  It's probably
> got bugs, and it's not perfect -- for example if you pass something like
> -I/usr/local/bin it will not know how to translate that.
> [snip]

For more comprehensive behavior, you need to have program-specific wrapper
scripts.  For example, see my Java wrappers in the cygwin-apps CVS:
.
Notice that even those scripts don't do a complete job, since arguments
given to the Java programs themselves are left as-is (by design, because
those scripts can't just go about mangling arbitrary strings).
Igor
P.S. Is "dodos" short for "extinct birds"? :-)
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MSYS path behavior in Cygwin

[Brian Dessent]

tom wrote:

> I guess the two will be mutually exclusive, unless you Cygwin devs see some
> reason to merge some of Earnie's work.  I'm have to believe there's some 
> reason
> why it hasn't been done though.  I'm sure it's non-trivial to say the least.
> 
> Thanks for the help anyways!  Cygwin and msys make life in Win32land bearable.

To do that would go against the grain of what Cygwin is trying to
accomplish: provide a full posix environment.  So to have
argument-translation code sort of defeats that purpose since all Cygwin
programs are supposed to recognise posix paths.

Now in reality, everyone has to run a non-Cygwin program from time to
time, so of course there will be times where you run up against this. 
But the question becomes, when should the library translate paths, and
when should it leave them alone?  Because you can't just unconditionally
do it.  The way MSYS handles this is by assuming that everything in the
MSYS bin directory is a MSYS binary that can handle posix paths, and
that everything else is a win32/mingw app that needs win32 paths.  Now
that's a rather stark and arbitrary distinction.  It works for MSYS
since it's intended to be a rather minimal system, just enough to build
packages using auto{conf,make},libtool.  But I think for Cygwin this
would be way too restrictive.

The workaround that I think most people use is a wrapper script that
essentially just runs "cygpath -w" on each argument and then execs $1. 
So you can type "wrapper win32program /posix/path/to/file" and it ends
up running "win32program c:/win32/path/to/file".  If you do it right,
you can make this quite generic, so that you just prepend "wrapper" (or
whatever you want to call it.)

Below is one that I use in my .bashrc that calls perl.  It's probably
got bugs, and it's not perfect -- for example if you pass something like
-I/usr/local/bin it will not know how to translate that.  But it gets
the job done for most win32 programs, so that you can type "dodos
notepad /tmp/foobar" for example.  It should work with filenames/paths
with spaces in them.

dodos () {
perl - "$@" <<'_EOF_'

my @args = shift (@ARGV);

foreach (@ARGV) {
chomp(my $arg = `cygpath -w "$_" 2>/dev/null`);
$arg = $_ if (length($arg) == 0);
push @args, $arg;
}
exec @args;
_EOF_
}

Brian

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where is SCP

[Igor Peshansky]

On Mon, 30 Jan 2006, Scott Purcell wrote:

> Hello,
> I need to scp some files to a remote machine on our network, and I
> cannot find the scp module?
> When I loaded cygwin, I loaded most default stuff, but even today, I am
> trying to search for it, and cannot find scp?

Exactly where were you trying to search for it?  The answer to most
queries of "where is program foo" is the Cygwin package search page at
 (also mentioned in the FAQ entry
).  You can
use Perl regular expressions to get better matches for short names, e.g.,
"\bscp\b" for a whole-word "scp" search.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MSYS path behavior in Cygwin

[tom]

See this thread for more info:
http://sourceforge.net/forum/forum.php?thread_id=1430505&forum_id=290275

I guess the two will be mutually exclusive, unless you Cygwin devs see some
reason to merge some of Earnie's work.  I'm have to believe there's some reason
why it hasn't been done though.  I'm sure it's non-trivial to say the least.

Thanks for the help anyways!  Cygwin and msys make life in Win32land bearable.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: csh script hangs only on cygwin

[Stewart Midwinter]

* Subject: Re: csh script hangs only on cygwin
* References: <[EMAIL PROTECTED]>
* Reply-to: cygwin at cygwin dot com

Corinna Vinschen wrote:

>WFM.  I tried it for > 3 hours with no hang.

Corinna, what OS and type of box are you running that on?  My problem
arose ONLY when running on a Xeon and with Windows Server 2003.  On
other boxes, and other operating systems, e.g Windows 2000, there was
no problem.

thanks
S

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where is SCP

[Herman Poon]

Scott Purcell wrote:

> Hello,
> I need to scp some files to a remote machine on our network, and I
> cannot find the scp module?
> When I loaded cygwin, I loaded most default stuff, but even today, I am
> trying to search for it, and cannot find scp?
>
> Thanks,

Hi,

scp is part of the openssh package which you will find under the "Net"
category in the Cygwin setup.

HTH,

Herman



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: where is SCP

[Reid Thompson]

Scott Purcell wrote:

Hello,
I need to scp some files to a remote machine on our network, and I
cannot find the scp module?
When I loaded cygwin, I loaded most default stuff, but even today, I am
trying to search for it, and cannot find scp?

Thanks,

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

  

install openssh

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

where is SCP

[Scott Purcell]

Hello,
I need to scp some files to a remote machine on our network, and I
cannot find the scp module?
When I loaded cygwin, I loaded most default stuff, but even today, I am
trying to search for it, and cannot find scp?

Thanks,

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: unmount drive in cygwin - is it possible

[Tony Richardson]

Mark Bevan  yahoo.co.uk> writes:
> I have compiled ntfsprogs 1.12.1 for use with cygwin -
> compilation went well and I know have the set of
> executables available.
> 
> Whenever I run ntfsresize (even just to get info on
> current NTFS filesystem using -i option) I am told :
> 
> ntfsresize v1.12.1 (libntfs 8:1:0)
> ERROR: Device '/cygdrive/e' is mounted read-write. You
> must 'umount' it first.
> 
> However there doesn't seem to be a way to unmount a
> disk in cygwin :
> 
> $ umount /cygdrive/e
> umount: /cygdrive/e: No such file or directory
> 
> Maybe this because this because the underlying windows
> operating system (Windows XP) doesn't allow for this
> or maybe I am not using the right commands ?

Did you try using the raw device name instead of the filesstem?
That is, something like:

   ntfsresize /dev/sda1

for the first partition on the first disk.  See the "Special
Filenames" of the Cygwin User's Guide for more info.

Tony



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19-4 exec family of functions find wrong file to execute

[Martin]

Any response?
TIA
--- Martin <[EMAIL PROTECTED]> wrote:

> I am attempting to invoke a command with
> execvp/execlp.  If a file appears in my PATH before
> the executable desired and has the same name as the
> executable, the first occurrence of the file name is
> used as the executable to invoke.  Even though the
> first file is NOT marked as executable.
> 
> The attached testcase illustrates this.
> Here's a simple shell log:
> 
> bash-3.00$ gcc test2.c -o test2
> bash-3.00$ PATH=/usr/bin:.
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ touch echo
> bash-3.00$ ls -l echo
> -rw-r--r-- 1 test None 0 Jan 21 15:39 echo
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ PATH=.:/usr/bin
> bash-3.00$ test2 nopathnoext
> nopathnoext: No such device or address
> bash-3.00$ rm -f echo
> bash-3.00$ test2 nopathnoext
> NoPathNoExt
> bash-3.00$ echo garbage > echo
> bash-3.00$ test2 nopathnoext
> nopathnoext: Permission denied
> bash-3.00$ ls -l echo
> -rw-r--r-- 1 test None 8 Jan 21 15:40 echo
> bash-3.00$ test2 nopathext
> NoPathExt
> bash-3.00$ test2 path
> Path
> 
> Is this normal behavior for execlp/execvp?
> Shouldn't the execution permission be set in order to
> execute it?
> 
> Thanks for your help,
> Martin
> 







__ 
Find your next car at http://autos.yahoo.ca

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters

[Igor Peshansky]

On Mon, 30 Jan 2006, Svend Sorensen wrote:

> On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:

Again, .  Thanks.

> > Ugh, top-posting...  Reformatted.
> >
> > On Mon, 30 Jan 2006, Svend Sorensen wrote:
> >
> > > On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:
> >
> > .  Thanks.
> >
> > > > On Thu, 26 Jan 2006, Svend Sorensen wrote:
> > > >
> > > > > When I use pdksh to expand the name of a file with spaces or
> > > > > other shell metachars in it, the filename is expanded without
> > > > > escaping the metacharacters.
> > > >
> > > > Thanks for the report.  I've been able to reproduce this.
> > > > There's an upstream patch that fixes the issue, and I'm currently
> > > > working on integrating that and other patches into the build to
> > > > produce a new release (but no ETA yet).
> > > >
> > > > > The pdksh version strings are identical.
> > > >
> > > > This is unfortunate.  What is the patchlevel shown for the pdksh
> > > > package on NetBSD?
> > > >
> > > > FWIW, I will include the full list of patches in the README for
> > > > the new release.
> > >
> > > The NetBSD system I tested has pdksh-5.2.14nb1 installed.  There are
> > > two patches in pkgsrc, one which removes a Makefile check for pdksh
> > > in the /etc/shells file, and one which removes a declaration of
> > > errorno. Other than that, it uses the vanilla pdksh-5.2.14.tar.gz
> > > sources.
> >
> > Hmm, this is extremely surprising, as 5.2.14 doesn't contain any code
> > to quote shell metacharacters on tab completion.  Are you sure those
> > are vanilla sources?  I know OpenBSD uses its own CVS repository for
> > PDKSH -- does NetBSD do this too?  Can you compare the tarball with
> > ?
>
> It turns out I was running NetBSD's base ksh, which must be a patched
> pdksh.

Ah, I thought so.

> I tested the version of pdksh in pkgsrc, and it has no metacharacter
> expansion.  The pkgsrc version of pdksh uses that source tarball you
> mentioned.

Right.  If you could get a pointer at the NetBSD CVS repository for pdksh,
or at least a list of NetBSD-specific patches on top of the base sources,
that would be great.

> > > I have attached the patches from pkgsrc.
> >
> > These patches don't seem to do anything interesting.
> >
> > The next release of PDKSH on Cygwin will be built with a metacharacter
> > quoting patch (from Debian).  I'd still like to investigate this to
> > see why it works for you on NetBSD without that patch...
>
> NetBSD must patch their stock pdksh, which would make this a feature
> request, not a bug report.

Nevertheless, I've been meaning to add upstream patches for a while...
They address some very nasty bugs in the vanilla sources.

> Should NetBSD modify their base KSH_VERSION reporting to show it is
> patched?

I'd say yes, if only to avoid the confusion you had at the start of this
thread (with the identical version numbers).

> Thanks for your help, Igor.

Don't thank me yet -- you'll probably be one of the people testing the new
release. :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters

[Svend Sorensen]

On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:
> Ugh, top-posting...  Reformatted.
>
> On Mon, 30 Jan 2006, Svend Sorensen wrote:
>
> > On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:
>
> .  Thanks.
>
> > > On Thu, 26 Jan 2006, Svend Sorensen wrote:
> > >
> > > > When I use pdksh to expand the name of a file with spaces or other
> > > > shell metachars in it, the filename is expanded without escaping the
> > > > metacharacters.
> > >
> > > Thanks for the report.  I've been able to reproduce this.  There's an
> > > upstream patch that fixes the issue, and I'm currently working on
> > > integrating that and other patches into the build to produce a new
> > > release (but no ETA yet).
> > >
> > > > The pdksh version strings are identical.
> > >
> > > This is unfortunate.  What is the patchlevel shown for the pdksh
> > > package on NetBSD?
> > >
> > > FWIW, I will include the full list of patches in the README for the
> > > new release.
> >
> > The NetBSD system I tested has pdksh-5.2.14nb1 installed.  There are
> > two patches in pkgsrc, one which removes a Makefile check for pdksh in
> > the /etc/shells file, and one which removes a declaration of errorno.
> > Other than that, it uses the vanilla pdksh-5.2.14.tar.gz sources.
>
> Hmm, this is extremely surprising, as 5.2.14 doesn't contain any code to
> quote shell metacharacters on tab completion.  Are you sure those are
> vanilla sources?  I know OpenBSD uses its own CVS repository for PDKSH --
> does NetBSD do this too?  Can you compare the tarball with
> ?

It turns out I was running NetBSD's base ksh, which must be a patched pdksh.

I tested the version of pdksh in pkgsrc, and it has no metacharacter
expansion.  The pkgsrc version of pdksh uses that source tarball you
mentioned.

> > I have attached the patches from pkgsrc.
>
> These patches don't seem to do anything interesting.
>
> The next release of PDKSH on Cygwin will be built with a metacharacter
> quoting patch (from Debian).  I'd still like to investigate this to see
> why it works for you on NetBSD without that patch...

NetBSD must patch their stock pdksh, which would make this a feature
request, not a bug report.

Should NetBSD modify their base KSH_VERSION reporting to show it is patched?

Thanks for your help, Igor.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Installation Errors

[jgriffin]

I'm trying to install Cygwin on a stand alone computer. Here is what I'm doing:
 
1) Download setup
2) Download everything to a local directory
3) Copy that local directory and setup.exe to a CD
4) Attempted to install from the CD - got errors
5) After installing from CD tried reinstalling some packages from CD - got 
errors
6) Copied the setup.exe and packages to a folder on the target machine, 
cleaned out previous install and attempted a new installation - got errors
7) After the install goes to completion (I tap enter to dismiss all the error 
dialogs), I attempt to run the cygwin x server. I get another error dialog and 
after checking the log file, cygwin could not find fonts. I checked the cygwin 
x server FAQ (Section 8.4) and tried their instructions. The umount command is 
not applicable since there is no "fonts" folder to unmount. I did reinstall 
the entire X package to no avail.

Errors
Most of the errors are coming from the post-install scripts. I get an error 
dialog stating that cygpopt-0.dll could not be found.

 
Any help would be appreciated!
 
Joseph
 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: unmount drive in cygwin - is it possible

[Dave Korn]

On 30 January 2006 18:10, Mark Bevan wrote:

> Hello,
> 
> I have compiled ntfsprogs 1.12.1 for use with cygwin - compilation went
> well and I know have the set of executables available. 
> 
> Whenever I run ntfsresize (even just to get info on current NTFS
> filesystem using -i option) I am told : 
> 
> ntfsresize v1.12.1 (libntfs 8:1:0)
> ERROR: Device '/cygdrive/e' is mounted read-write. You must 'umount' it
> first. 
> 
> However there doesn't seem to be a way to unmount a disk in cygwin :
> 
> $ umount /cygdrive/e
> umount: /cygdrive/e: No such file or directory
> 
> Maybe this because this because the underlying windows operating system
> (Windows XP) doesn't allow for this or maybe I am not using the right
> commands ?  

  Neither exactly.  Drives _can_ be unmounted by the underlying OS, but cygwin 
doesn't provide any utility to do this.  The 'mount'
and 'umount' commands in cygwin don't actually mount/unmount filing systems, 
they just allow you to make a unix-y view on the
existing FS.

  As to ntfsresize, it may be a weakness in the coding that it still requires 
the drive to be r/w even if you're only making a query
for info it could read from an r/o drive, or there may be some complex reason 
why it needs that anyway.

  However, I don't suppose your HD is actually read-only, unless of course E: 
is your CDROM; it may be that cygwin's /dev/hdX
devices don't function quite the same as Linux's.  It's quite possible that the 
_actual_ error that is occurring is that libntfs is
trying to lock the HD for exclusive access, which is something you just can't 
do in 'doze, and then the ntfsresize utility makes a
bogus assumption that the only thing that could stop it locking the drive for 
exclusive r/w access would be if it was r/o.  I
haven't looked at it in detail.  You're not likely to get much by the way of 
useful results from ntfsprogs without some porting
effort.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

unmount drive in cygwin - is it possible

[Mark Bevan]

Hello,

I have compiled ntfsprogs 1.12.1 for use with cygwin -
compilation went well and I know have the set of
executables available.

Whenever I run ntfsresize (even just to get info on
current NTFS filesystem using -i option) I am told :

ntfsresize v1.12.1 (libntfs 8:1:0)
ERROR: Device '/cygdrive/e' is mounted read-write. You
must 'umount' it first.

However there doesn't seem to be a way to unmount a
disk in cygwin :

$ umount /cygdrive/e
umount: /cygdrive/e: No such file or directory

Maybe this because this because the underlying windows
operating system (Windows XP) doesn't allow for this
or maybe I am not using the right commands ?

The mount table for the system is :

$ mount
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)
e: on /cygdrive/e type system (binmode,noumount)

Hope someone can help - I am guessing the noumount
part is trying to tell me something - hopefully there
is a way to get around this..

Mark



___ 
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo 
http://uk.photos.yahoo.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

sshd password authentication results in identity of NT AUTHORITY\SYSTEM

[Perdue, Dave T. CIV NAVAIR 5.4.3, Bldg 2035, Rm 205, Cube 200]

Hi all,
Our facility has been using Cygwin-1.5.12-1 on Windows 2000 with our 
account home directories on a windows network shared folder using both a local 
login and an ssh remote system login with no problems.
I recently tried Cygwin-1.5.18 and 19 and find that the network share 
account home directories return an access denied when logging in using ssh with 
password authentication, but a local login works fine.  
The Cygwin "whoami" command reports the correct username, however the 
Window Resource kit "whoami.exe" reports "NT Authority\SYSTEM" for the username 
when using a password authenticated ssh login.  The user's SID is identical, 
just the username is different.  
I have read responses in the Cygwin mail lists that indicated that RSA 
authenticated logins should act this way (no access to network shares due to 
incomplete user impersonation) however it also indicated that password 
authentication should provide network share access.  
A minimal installation of Cygwin to support ssh (Cygwin with cygrunsrv 
and openssh) shows proper user context switching for Cygwin-1.5.12-1 but fails 
using Cygwin-1.5.19-4.  
I do not have access to versions 13-17 so I cannot determine at what 
point full support of password authentication "broke".  
Is no access to network shares when using ssh password authentication 
the intended Cygwin ssh functionality?

Dave

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: readline-5.1 && CGDB

[Bob Rossi]

On Mon, Jan 30, 2006 at 10:50:13AM -0500, Bob Rossi wrote:
> On Mon, Jan 30, 2006 at 07:11:45AM -0700, Eric Blake wrote:
> > According to Bob Rossi on 1/28/2006 9:19 PM:
> > > On Linux, something totally different happens. When I initialize
> > > readline, it eventually calls tgetent, which happens to set LINES and
> > > COLS to the correct size of the terminal. On cygwin this doesn't happen.
> > > The call readline makes to tgetent leaves LINES and COLS alone. Then,
> > > in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless
> > > I set the LINES and COLUMNS environment variables before the call to
> > > initscr.
> > 
> > http://www.die.net/doc/linux/man/man3/tgetent.3.html does not document
> > that tgetent() messes with the environment, but if that is the case, you
> > may be onto something.  Perhaps it really is something cygwin1.dll needs
> > to patch to be more similar to linux.
> 
> I've finally produced a small test case like you asked me too. It did
> take some time, but it should certainly help discover the problem. I've
> attached the program.

And at last I believe I found the problem, but only after compiling
ncurses with debug.

The function shell.c:sh_set_lines_and_columns in readline sets the 
LINES and COLUMNS environment variables. It get's it's data from the
PTY you assign to rl_instream. The LINES and COLUMNS environment
variables effect the way ncurses work. If they are set, ncurses assumes
that the size of the terminal is LINESxCOLUMNS and sets the ncurses
variables LINES and COLS appopriatly.

So, when I give readline a PTY, if the size of the LINES and COLUMNS are 
different then that of stdout, then ncurses get's confused.

Chet, do you consider this desired functionality? I don't think readline
should modify the LINES and COLUMNS environment variables if the PTY
it's using is not stdout. What do you think? 

Anyways, for know, I can probably try to make the PTY I give readline
the same size as the stdout PTY.

Thanks,
Bob Rossi

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process

[Christopher Faylor]

On Sun, Jan 29, 2006 at 11:58:42PM +0100, Louis Lecaroz wrote:
>somebody wrote:
>>What did you actually *do* to get from one step to the next in the
>>above?  Where does your MSVC-linked DLL come into it?  What loads that
>>DLL?  What is your system like (the information requested in
>>http://cygwin.com/problems.html)?

That's two requests that you follow the guidelines at this page now and
you still haven't completely complied.

>First, my DLL is written & built in C by using MS DevStudio 2003.  so
>no by using gcc & CygWin libs.
>
>Next, I declared it through the LD_PRELOAD, which force cygwin
>processes (trougth the crt cygwin library) to load it in their memory
>space.  That's really simple to reproduce, only create an empty dll
>with DllMain & a MessageBox showing environment variables in the Attach
>process step of Dll Main, & you will see that :
>
>-The first cygwin process (bash for example) you request load it
>correctly & environment variable are all in the process
>
>-Next from bash, start VI for example,
>
>-A new instance (the forky instance) of bash will be started also with
>the LD_PRELOAD dll loaded correctly & also with all environment
>variables (If I remember, the cygwin fork() method uses the
>CreateProcess with longjmg, ect...  & pipes for synchronizing
>initialization throught the parent & the forky).
>
>-vim.exe is started through the forky instance of bash (If I am right),
>the LD_PRELOAD dll is still (& always) loaded correctly but only 3 or 4
>environment variables have been propaged (by using GetEnvironmentString
>win32 APIs as my DLL due to many constraints is compiled by using
>devenv & not cygwin/gcc as i said above).
>
>The problem has been reproducible on my computers, all using a clean
>install of CygWin 1.5.19-4 with & without last snapshot, & the behavior
>is exctly reprodicble on Win2000 Server & Win2003 Enterprise server.
>Downgrading to 1.5.18-x resolve this issue :(

Since you have now (finally) informed us that you are using a non-cygwin
binaries, then please read Brian Ford's response to your question.  Cygwin
now uses a more efficient mechanism for communicating the environment to
cygwin processes.  It does not fill out the windows environment if it
knows that the process being started is using the cygwin DLL.

http://cygwin.com/ml/cygwin/2006-01/msg01353.html

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters

[Igor Peshansky]

Ugh, top-posting...  Reformatted.

On Mon, 30 Jan 2006, Svend Sorensen wrote:

> On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:

.  Thanks.

> > On Thu, 26 Jan 2006, Svend Sorensen wrote:
> >
> > > When I use pdksh to expand the name of a file with spaces or other
> > > shell metachars in it, the filename is expanded without escaping the
> > > metacharacters.
> >
> > Thanks for the report.  I've been able to reproduce this.  There's an
> > upstream patch that fixes the issue, and I'm currently working on
> > integrating that and other patches into the build to produce a new
> > release (but no ETA yet).
> >
> > > The pdksh version strings are identical.
> >
> > This is unfortunate.  What is the patchlevel shown for the pdksh
> > package on NetBSD?
> >
> > FWIW, I will include the full list of patches in the README for the
> > new release.
>
> The NetBSD system I tested has pdksh-5.2.14nb1 installed.  There are
> two patches in pkgsrc, one which removes a Makefile check for pdksh in
> the /etc/shells file, and one which removes a declaration of errorno.
> Other than that, it uses the vanilla pdksh-5.2.14.tar.gz sources.

Hmm, this is extremely surprising, as 5.2.14 doesn't contain any code to
quote shell metacharacters on tab completion.  Are you sure those are
vanilla sources?  I know OpenBSD uses its own CVS repository for PDKSH --
does NetBSD do this too?  Can you compare the tarball with
?

> I have attached the patches from pkgsrc.

These patches don't seem to do anything interesting.

The next release of PDKSH on Cygwin will be built with a metacharacter
quoting patch (from Debian).  I'd still like to investigate this to see
why it works for you on NetBSD without that patch...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: rpcgen question

[Christian Gagneraud]

Hi all,

just for info, i have succesfully build and run my rpc code that was originally 
developped for GNU/Linux.


The problem was simply solved by generating the code with linux (pc GNU/Linux) 
and build/run it on windows.


But now i'm trying to build it for mingw32 (without multi-thread support) and 
facing some issues.


Does anyone have useful information about rpc/linux/cygwin and mingw32.

I have found lot of information about this problem, but it doesn't seems there 
is a maintained version of sunrpc or oncrpc that can be used cross-used.


Christian.



Brett Serkez wrote:



Since yesterday, i have made some investigation, and i have found that
rpcgen comes from the same package (both on RH and cygwin), but it's a
problem of version: - RH: /* @(#)rpc.h2.4 89/07/11 4.0 RPCSRC;
from 1.9 88/02/08 SMI */ - Cygwin: /* @(#)rpc.h2.3 88/08/10 4.0
RPCSRC; from 1.9 88/02/08 SMI */


Correct, the features in question were added later.


And finaly, i will try to keep the generated code on linux and try to
build/use it on cygwin... Don't know if it's a good or bad idea! :(


A good idea.  It may not be necessary to regenerate the code for every
platform.  Working on projects in the past, it was the norm to generate
and check-in the generated code on the primary UNIX platform, and only
compile on the various UNIXies/Linux.  Much of the upgraded
functionality is in the code generator, althought threading depends upon
the appropriate threading libraries availability on each platform.

Brett

Brett C. Serkez, Techie



--
+-+
| Chritian Gagneraud  |
|  SW Test & QA Engineer, 3G Linux Platform   |
| CELAD on behalf of Freescale Semiconductor - WBSG EMEA  |
| Phone:  33-(0)5.61.19.99.74 |
| eMail:  [EMAIL PROTECTED]|
+-+


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters

[Svend Sorensen]

The NetBSD system I tested has pdksh-5.2.14nb1 installed.  There are
two patches in pkgsrc, one which removes a Makefile check for pdksh in
the /etc/shells file, and one which removes a declaration of errorno. 
Other than that, it uses the vanilla pdksh-5.2.14.tar.gz sources.

I have attached the patches from pkgsrc.

On 1/30/06, Igor Peshansky <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Jan 2006, Svend Sorensen wrote:
>
> > When I use pdksh to expand the name of a file with spaces or other
> > shell metachars in it, the filename is expanded without escaping the
> > metacharacters.
>
> Thanks for the report.  I've been able to reproduce this.  There's an
> upstream patch that fixes the issue, and I'm currently working on
> integrating that and other patches into the build to produce a new release
> (but no ETA yet).
>
> > The pdksh version strings are identical.
>
> This is unfortunate.  What is the patchlevel shown for the pdksh package
> on NetBSD?
>
> FWIW, I will include the full list of patches in the README for the new
> release.
>
> Igor Peshansky, volunteer PDKSH maintainer for Cygwin
> --
> http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
>  |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
> '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
>
> "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
> "But no -- you are no fool; you call yourself a fool, there's proof enough in
> that!" -- Rostand, "Cyrano de Bergerac"
>


patch-aa
Description: Binary data


patch-ab
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: MSYS path behavior in Cygwin

[tom]

Dave Korn  artimi.com> writes:

>   But cygwin apps understand *nix style paths natively!  ...

Right - My problem comes when I want to run a windows app from the cygwin shell.
For example:
gvim.exe /c/src/myfile.cs

Why would I want to do this:
1.  The Cygwin shell in general has all sorts of goodies that cmd doesn't have.
I have a cygwin shell open 24/7.  'Nuff said.
2.  There are, however, still windows applications that I may want to run from
the command line.  (i.e. Visual Studio or some other native windows app.)  
3.  When typing the *nix path, I get the tab auto-completion.

However they did it, the MSYS devs made it so that I can type a cygwin path, and
yet a windows path gets sent as the argument to the windows executable.  

I posted on the MSYS list and they suggested I ask here.  Maybe I should 
clarify 
my intent.  

Anyway, thanks for your help!




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: MSYS path behavior in Cygwin

[Dave Korn]

On 30 January 2006 16:25, tom wrote:

> That said, one thing I loved about msys is the ability to pass a *nix
> style path and have it automatically converted, i.e. I could start gvim
> like so:  
> gvim.exe /c/src/myfile.cs
> and the path would convert to 'C:\src\myfile.cs' for the windows exe.
> 
> I know cygwin has the cygpath util to deal with this... But is there any
> way to get the MSYS automatic path conversion in Cygwin? 

  But cygwin apps understand *nix style paths natively!  Perhaps you need to 
ask yourself _why_ you want to do what you want to
do...

>I know Cygwin
> has 'MinGW runtime' library packages - Is there some way to use those
> libs in Cygwin to get the desired effect? Any insight?   

  Yes: MSYS is a fork of Cygwin, and that is why MSYS contains Cygwin's 
patch-converting magic.



cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

MSYS path behavior in Cygwin

[tom]

Hey all, 
 
I used to use MSYS simply as my general purpose shell (infinitely better than
cmd!) However, I've started using Cygwin since I really just use it as a shell
rather than a build environment, and Cygwin has the full selection of tools.  
 
That said, one thing I loved about msys is the ability to pass a *nix style path
and have it automatically converted, i.e. I could start gvim like so: 
gvim.exe /c/src/myfile.cs  
and the path would convert to 'C:\src\myfile.cs' for the windows exe. 
 
I know cygwin has the cygpath util to deal with this... But is there any way to
get the MSYS automatic path conversion in Cygwin? I know Cygwin has 'MinGW
runtime' library packages - Is there some way to use those libs in Cygwin to get
the desired effect? Any insight? 
 
Thanks! 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Cygwin Bash window disappear?!

[Igor Peshansky]

On Mon, 30 Jan 2006, Dave Korn wrote:

> On 30 January 2006 15:54, Igor Peshansky wrote:
>
> > On Mon, 30 Jan 2006, Dave Korn wrote:
> >
> >> On 28 January 2006 04:19, Daniel mark wrote:
> >>
> >>> Hello Eric:
> >>
> >>> //
> >>> Cygwin Configuration Diagnostics
> >>
> >>> Path: C:\Program Files\texmf\miktex\bin
> >>
> >>> Path = 'C:\Program
> >>> Files\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Sys
> >>> tem32\Wbem;
> >>
> >>   First thing to try is to get rid of all those clashing
> >> win32-versions of *nix apps from your %PATH% and re-run setup.
> >
> > Huh?  Since when does MikTeX conflict with Cygwin?
>
>   I could see the included makeinfo interfering with
> /etc/postinstall/update-info-dir.sh.  And people are always complaining
> about seeming-hangs in setup at the post-texmf.sh script.

update-info-dir.sh doesn't use makeinfo.  Besides, postinstall scripts
should not rely on the path containing /bin -- they should use explicit
paths (or else set the PATH themselves).  Plus, I believe setup prepends
/bin to the PATH before running the scripts.

post-texmf.sh regenerates all of the binary LaTeX format files -- it's
*supposed* to take a long time, especially with slower disks.  Perhaps it
should be renamed to "post-texmf-THIS-MAY-TAKE-A-WHILE.sh" (so people at
least get a visual clue in setup)? :-)

> > We still haven't gotten the exact error message that the OP gets when
> > running c:\cygwin\Cygwin.bat from a CMD window. Igor
>
>   Yep, we don't have enough information to diagnose the problem yet,
> that suggestion above was only a suggestion for something to try.

Well, let's hope this doesn't take the OP off on a tangent and make him
forget to actually post some useful output. :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Cygwin Bash window disappear?!

[Dave Korn]

On 30 January 2006 15:54, Igor Peshansky wrote:

> On Mon, 30 Jan 2006, Dave Korn wrote:
> 
>> On 28 January 2006 04:19, Daniel mark wrote:
>> 
>>> Hello Eric:
>> 
>>> //
>>> Cygwin Configuration Diagnostics
>> 
>>> Path:   C:\Program Files\texmf\miktex\bin
>> 
>>> Path = 'C:\Program
>>> Files\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Sys
>>> tem32\Wbem;
>> 
>>   First thing to try is to get rid of all those clashing
>> win32-versions of *nix apps from your %PATH% and re-run setup.
> 
> Huh?  Since when does MikTeX conflict with Cygwin?

  I could see the included makeinfo interfering with 
/etc/postinstall/update-info-dir.sh.  And people are always complaining about
seeming-hangs in setup at the post-texmf.sh script.

> We still haven't gotten the exact error message that the OP gets when
>   running c:\cygwin\Cygwin.bat from a CMD window. Igor

  Yep, we don't have enough information to diagnose the problem yet, that 
suggestion above was only a suggestion for something to
try.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Cygwin Bash window disappear?!

[Igor Peshansky]

On Mon, 30 Jan 2006, Dave Korn wrote:

> On 28 January 2006 04:19, Daniel mark wrote:
>
> > Hello Eric:
>
> > //
> > Cygwin Configuration Diagnostics
>
> > Path:   C:\Program Files\texmf\miktex\bin
>
> > Path = 'C:\Program 
> > Files\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
>
>   First thing to try is to get rid of all those clashing win32-versions
> of *nix apps from your %PATH% and re-run setup.

Huh?  Since when does MikTeX conflict with Cygwin?

I wonder if cygcheck should add c:\cygwin\bin to the PATH if it isn't
there (e.g., when run from CMD and /bin isn't in the system PATH), just so
we know if the "Not Found: sh" message means that the bash postinstall
didn't complete, or simply that /bin isn't in the PATH.

We still haven't gotten the exact error message that the OP gets when
running c:\cygwin\Cygwin.bat from a CMD window.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: readline-5.1 && CGDB

[Bob Rossi]

On Mon, Jan 30, 2006 at 07:11:45AM -0700, Eric Blake wrote:
> According to Bob Rossi on 1/28/2006 9:19 PM:
> > On Linux, something totally different happens. When I initialize
> > readline, it eventually calls tgetent, which happens to set LINES and
> > COLS to the correct size of the terminal. On cygwin this doesn't happen.
> > The call readline makes to tgetent leaves LINES and COLS alone. Then,
> > in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless
> > I set the LINES and COLUMNS environment variables before the call to
> > initscr.
> 
> http://www.die.net/doc/linux/man/man3/tgetent.3.html does not document
> that tgetent() messes with the environment, but if that is the case, you
> may be onto something.  Perhaps it really is something cygwin1.dll needs
> to patch to be more similar to linux.

I've finally produced a small test case like you asked me too. It did
take some time, but it should certainly help discover the problem. I've
attached the program.

Basically, you can run the program like './main' and that will have
readline operate on stdout, or you can run it like './main use_pty' and
that will have readline operate on a PTY that I have created. Besides
the code that opens the PTY, there is only the main function, and a
function that modifies the readline library.

If you run with the use_pty option, then ncurses thinks the terminal
size is 25x80 after the call to rl_reset_terminal. Here's the output:

[EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ ./main.exe use_pty
before rline_initialize LINES=0 COLS=0

before rl_callback LINES=0 COLS=0
after rl_callback LINES=75 COLS=85

before rl_reset_terminal LINES=75 COLS=85
after rl_reset_terminal LINES=25 COLS=80

after rline_initialize LINES=25 COLS=80

before initscr LINES=25 COLS=80
after initscr LINES=25 COLS=80

However, if you run without that option, then ncurses thinks the terminal 
size is the correct terminal size. Here's the output:

[EMAIL PROTECTED] ~/cvs/cgdb/builddir/tmp] $ ./main
before rline_initialize LINES=0 COLS=0

before rl_callback LINES=0 COLS=0
(tgdb)  after rl_callback LINES=75 COLS=85

before rl_reset_terminal LINES=75 COLS=85
after rl_reset_terminal LINES=75 COLS=85

after rline_initialize LINES=75 COLS=85

before initscr LINES=75 COLS=85
after initscr LINES=75 COLS=85

I've tracked down the code in readline to the line that manipulates the
LINES/COLS curses variables when initialize readline with a PTY. (This
same code does not modify the LINES/COLS variable when readline is
initialized with stdout).

The code is in terminal.c:_rl_init_terminal_io line 420 for me. It looks
like 
 tgetent_ret = tgetent (term_buffer, term);

where term is the string "dumb".

What I can't understand is, why would tgetent act differently when I
initialize readline with a created PTY, instead of stdout?

Thanks,
Bob Rossi

#include 
#include 
#include 
#include 
#include 
#include 

/*
  PTY CODE ***
 /
#define SLAVE_SIZE 64

static size_t strlcpy_local(char *dst, const char *src, size_t size) {
const char *s = src;
char *d = dst;
size_t n = size;

if (n)
while (--n && (*d++ = *s++)) {}

if (n == 0) {
if (size)
*d = '\0';

while (*s++) {}
}

return s - src - 1;
}

int pty_open(
  int *masterfd, 
  int *slavefd, 
  char *slavename, 
  size_t slavenamesize, 
  const struct termios *slave_termios, 
  const struct winsize *slave_winsize) 
{
 char *name;

 if (!masterfd || !slavefd || !slavename || slavenamesize < 64)
  return -1;

 if ((*masterfd = open("/dev/ptmx", 2 | 0x8000)) == -1)
  return -1;

 if (grantpt(*masterfd) == -1)
 {
  close(*masterfd);
  return -1;
 }

 if (unlockpt(*masterfd) == -1)
 {
  close(*masterfd);
  return -1;
 }

 if (!(name = ptsname(*masterfd)))
 {
  close(*masterfd);
  return -1;
 }

 if (strlcpy_local(slavename, name, slavenamesize) >= slavenamesize)
 {
  close(*masterfd);
  return -1;
 }

 if ((*slavefd = open(slavename, 2 | 0x8000)) == -1)
 {
  close(*masterfd);
  return -1;
 }

 if (slave_termios && tcsetattr(*slavefd, 2, slave_termios) == -1)
 {
  close(*masterfd);
  close(*slavefd);
  return -1;
 }

 if (slave_winsize && ioctl(*slavefd, (('T' << 8) | 2), slave_winsize) == -1)
 {
  close(*masterfd);
  close(*slavefd);
  return -1;
 }

 return 0;
}

struct pty_pair 
{
  int masterfd;
  int slavefd;
  char slavename[SLAVE_SIZE];
};
typedef struct pty_pair *pty_pair_ptr;

pty_pair_ptr pty_pair_create (void)
{
  int val;
  static char local_slavename[SLAVE_SIZE];
  pty_pair_ptr ptr = (pty_pair_ptr)malloc (sizeof (struct pty_pair));
  if (!ptr)
return NULL;

  ptr->masterfd = -1;
  ptr->sl

RE: Cygwin Bash window disappear?!

[Dave Korn]

On 28 January 2006 04:19, Daniel mark wrote:

> Hello Eric:

> //
> Cygwin Configuration Diagnostics

> Path: C:\Program Files\texmf\miktex\bin

> Path = 'C:\Program
> Files\texmf\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;



  First thing to try is to get rid of all those clashing win32-versions of *nix 
apps from your %PATH% and re-run setup.



cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bootstrap error

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Alexander Klimov on 1/30/2006 2:11 AM:
> 
> BTW, I have not rebuild temacs because most of build tools are
> not compatible with the old cygwin dll, e.g., rm produces an error
> 
>  The procedure entry point getline could not be located in the [DLL]
>  cygwin1.dll

If you downgrade cygwin1.dll, you must also downgrade everything that has
been released since cygwin1.dll to avoid this error (that would include
coreutils down to 5.3.0-9, findutils down to 4.2.25-2, libreadline6 down
to 5.0-4, etc).

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFD3iJW84KuGfSFAYARAigOAJjwP6JF+n4Vsi6ru8cftzKS8KwqAKDMgNEx
x16B72uclxZ0XjGjfLONGw==
=bQyW
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: readline-5.1 && CGDB

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Rossi on 1/28/2006 9:19 PM:
> On Linux, something totally different happens. When I initialize
> readline, it eventually calls tgetent, which happens to set LINES and
> COLS to the correct size of the terminal. On cygwin this doesn't happen.
> The call readline makes to tgetent leaves LINES and COLS alone. Then,
> in Cygwin when I get to initscr, LINES and COLS is set to 25x80, unless
> I set the LINES and COLUMNS environment variables before the call to
> initscr.

http://www.die.net/doc/linux/man/man3/tgetent.3.html does not document
that tgetent() messes with the environment, but if that is the case, you
may be onto something.  Perhaps it really is something cygwin1.dll needs
to patch to be more similar to linux.


- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3h6h84KuGfSFAYARAksIAJ9elsYMWPiSZHWpanbnBv6nJHpw5QCgwmEQ
floUSXqiaA0uiBNLyKGqa/Q=
=vmkr
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters

[Igor Peshansky]

On Thu, 26 Jan 2006, Svend Sorensen wrote:

> When I use pdksh to expand the name of a file with spaces or other
> shell metachars in it, the filename is expanded without escaping the
> metacharacters.

Thanks for the report.  I've been able to reproduce this.  There's an
upstream patch that fixes the issue, and I'm currently working on
integrating that and other patches into the build to produce a new release
(but no ETA yet).

> The pdksh version strings are identical.

This is unfortunate.  What is the patchlevel shown for the pdksh package
on NetBSD?

FWIW, I will include the full list of patches in the README for the new
release.

Igor Peshansky, volunteer PDKSH maintainer for Cygwin
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)

[Peter Ekberg]

On Mon, Jan 23, 2006 at 10:01:44PM +0100, Peter Ekberg wrote:
> On Mon, Jan 16, 2006 at 12:13:12PM +0100, Peter Ekberg wrote:
> > On Mon, Jan 09, 2006 at 10:58:00AM +0100, Peter Ekberg wrote:
> > > Hello!
> > > 
> > > I recently tried to build a package that was using cpp for other
> > > purposes than preprocessing C files. Its configure script was
> > > looking for a way to not have cpp predefine anything, and it
> > > specifically tried the -undef option, but failed. From reading the
> > > docs, I couldn't figure out why. Here's a quote from "info cpp":
> > > 
> > > '-undef'
> > >  Do not predefine any system-specific or GCC-specific macros.  The
> > >  standard predefined macros remain defined.  *Note Standard
> > >  Predefined Macros::.
> > > 
> > > So I searched the web a bit and figured that I could probably fix
> > > it in the specs file. I realise that the specs file probably isn't
> > > the canonical place to change this, but I'll leave that to the gcc
> > > maintainer.
> > > 
> > > Attached is a patch for the specs file that wraps all old define
> > > rules for cpp inside the following:
> > > 
> > > %{!undef:old define rules}
> > > 
> > > I don't know if this is the correct thing to do, but it works for
> > > me.
> > 
> > GCC maintainer, are you there? Can you come out and play, please? :-)
> 
> Ping.

Pong.

Cheers,
Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bootstrap error

[Corinna Vinschen]

On Jan 30 11:11, Alexander Klimov wrote:
> On Sun, 29 Jan 2006, Eli Zaretskii wrote:
> > Then it's probably a good idea to post the information you found on
> > the Cygwin mailing list.  Perhaps they will be able to suggest
> > solutions or otherwise shed some light on this problem.
> 
> The problem is that I have no idea what to tell them: temacs fails
> with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a
> reasonable bug report.
> 
> Let me put the question differently: what was changed between 18-1 and
> 19-4 in the DLL (note that .h files are irrelevant since I used temacs
> built with 19-4).
> 
> Cygwin gurus, the start of the thread is here
> 

Sorry, I can't make a lot out of this error report.  Please try to nail
down the problem somewhat further, for instance, by providing a minimal
testcase which allows to reproduce the problem with a minimum of
involved code.

Since this revolves around malloc, it might be worth to note that two
changes to malloc have been made in Cygwin between 1.5.18 and 1.5.19.
First, we switched from Doug Lea's malloc implementation version 2.8.0
to 2.8.3, second, due to a reworked mmap implementation, which uses
simple VirtualAlloc for private anonymous maps, we lowered the
DEFAULT_MMAP_THRESHOLD from 16 Megs to the usual default of 256K.


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: readdir after rewinddir not working in 20060128 snapshot

[Corinna Vinschen]

On Jan 30 00:29, Yitzchak Scott-Thoennes wrote:
> After a rewinddir, readdir seems to return as many empty entries as there
> were actual entries left to read, followed by . and ..

Thanks for the testcase!  Since the underlying NT call NtQueryDirectoryInfo
is able to return more than one directory entry in one call, I thought it
might be a good idea to implement readdir caching.  Unfortunately I forgot
to reset the cache in case of rewinddir.  I've applied a fix now.


Corinna

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

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: bootstrap error

[Alexander Klimov]

On Sun, 29 Jan 2006, Eli Zaretskii wrote:
> > From: Alexander Klimov <[EMAIL PROTECTED]>
> >
> > On Sat, 28 Jan 2006, Eli Zaretskii wrote:
> > > Perhaps try downgrading to the previous version of Cygwin--there might
> > > be some bug in the latest version.

I made the following experiment: I installed cygwin 1.5.18-1 and now
 ./temacs.exe --batch --load loadup bootstrap
creates emacs.exe

BTW, I have not rebuild temacs because most of build tools are
not compatible with the old cygwin dll, e.g., rm produces an error

 The procedure entry point getline could not be located in the [DLL]
 cygwin1.dll

I reverted back to 19-4 and now temacs again fails with apparent
recursion (malloc() from cygwin1.dll calls malloc from temacs).

> > I have no doubt about it -- I currently use emacs which was built from
> > cvs on 2006-01-16 (before I upgraded cygwin) and the problems with
> > build starts to appear only *after* the last cygwin update.
>
> Then it's probably a good idea to post the information you found on
> the Cygwin mailing list.  Perhaps they will be able to suggest
> solutions or otherwise shed some light on this problem.

The problem is that I have no idea what to tell them: temacs fails
with DLL 1.5.19-4 but dumps emacs with DLL 1.5.18-1 is not a
reasonable bug report.

Let me put the question differently: what was changed between 18-1 and
19-4 in the DLL (note that .h files are irrelevant since I used temacs
built with 19-4).

Cygwin gurus, the start of the thread is here


-- 
Regards,
ASK

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pgsql on cygwin problem

[Reini Urban]

2005/8/29, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hello. I had a problem at installation postgesql as service nt. I do all
> under the documentation which is in a
> file/usr/share/doc/Cygwin/postgresql-7.4.5. README On item 8 at me there is
> a mistake at initialization of a database.
>
> $ initdb -D /var/postgresql/data
> The files belonging to this database system will be owned by user
> "postgres".
> This user must also own the server process.
>
> The database cluster will be initialized with locale C.
>
> fixing permissions on existing directory /var/postgresql/data... ok
> creating directory /var/postgresql/data/base... ok
> creating directory /var/postgresql/data/global... ok
> creating directory /var/postgresql/data/pg_xlog... ok
> creating directory /var/postgresql/data/pg_clog... ok
> selecting default max_connections... Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> 10
> selecting default shared_buffers... Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> Signal 12
> 50

so IPC via cygserver is working ok

> creating configuration files... ok
> creating template1 database in /var/postgresql/data/base/1... Signal 12
>
> initdb: failed

so most likely the file permissions are wrong.
HTH

> Prompt please in what there can be a problem.
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: /proc//exe points to void

[Yitzchak Scott-Thoennes]

On Tue, Jan 24, 2006 at 06:45:28PM +0100, Corinna Vinschen wrote:
> On Jan 20 13:50, Sam Steingold wrote:
> > >> > On Mar 10 16:00, Sam Steingold wrote:
> > >> >> /proc//exe points to "foo", not to "foo.exe", so it cannot be
> > >> >> opened &c.
> > >> > 
> > >> >
> > >> 
> > >> how do I find out which file is running if /proc//exe cannot be
> > >> opened?
> > >
> > > access(2) or stat(2)
> > 
> > http://www.opengroup.org/onlinepubs/009695399/functions/access.html
> > the above spec of access appears to indicate that if access() succeeds
> > then open() must succeed too.
> > this is not the case in cygwin: /proc/self/exe cannot be open()ed.
> 
> I've just checked in a patch which tacks on the .exe suffix to
> /proc/$PID/exe, as well as a patch to realpath which returns the
> pathname with .exe suffix, even if the original name has no suffix
> given.  We will give this a try.  Please test the next snapshot.

Mostly for the archives, I note that this makes perl's $^X variable
include the ".exe" suffix.  This is probably a good thing, but at the
moment triggers a test failure.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/