Re: Please test the latest developer's snapshot

[Corinna Vinschen]

On Dec  4 02:20, Ben wrote:
> Just wanted to drop in a note saying that I've tried the snapshot on
> RTM Vista x64 on AMD, and I had no luck, either freshly installed, or
> with rebase/rebaseall. I tried rebaseall with ash, but got the usual
> Vista-related errors. I tried running rebase against ash, and then
> rebaseall again, but still no joy. All of the above I ran using first
> 0x7000 as base, and then 0x6500.

http://cygwin.com/ml/cygwin/2006-11/msg00595.html


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: GPGME 1.0.3 Build Problem

[djh]

Marcus,
  thanks for your efforts.

> Anyway, I have changed GPGME in SVN HEAD to not use a non-installed
> library at all.  This should fix the problem as well.  It would be
> good if someone tested out if that is indeed the case.
> 
> Thanks,
> Marcus

 here are the results I get from using everthing in:

  * gpgme-1.0.3.tar.gz
 
with the exceptipn of Makefile.am, which I used the new 1192 revision 
Makefile.am
which was mv'd to Makefile.am for the following:

Regards,
  Darel Henman


 Results 

$ ./configure

# configured as:  (December 4, 2006)
#GPGME v1.0.3 has been configured as follows:
#GnuPG path:/usr/local/bin/gpg
#GnuPG version: 1.4.5, min. 1.2.2
#
#GpgSM path:no
#GpgSM version: unknown, min. 1.9.6
#
#GPGME Pthread: yes
#GPGME Pth:


$ make -k 

make  all-recursive
make[1]: Entering directory `/usr/src/gpgme/gpgme-1.0.3'
Making all in gpgme
make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme'
make  all-am
make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme'
make[2]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme'
Making all in tests
make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests'
Making all in gpg
make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg'
/bin/sh ../../libtool --tag=CC --mode=link gcc  -g -O2 -Wall -Wcast-align 
-Wshadow -Wstrict-prototypes   -o t-encrypt.exe  t-encrypt.o 
../../gpgme/libgpgme.la 
gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe 
t-encrypt.o  ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a 
-L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function 
`_gpgme_sema_cs_destroy':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to 
`__gpgme_ath_mutex_destroy'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function 
`_gpgme_sema_subsystem_init':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to 
`__gpgme_ath_init'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to 
`__gpgme_ath_mutex_lock'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to 
`__gpgme_ath_mutex_unlock'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to 
`__gpgme_ath_read'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to 
`__gpgme_ath_write'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to 
`__gpgme_ath_waitpid'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to 
`__gpgme_ath_select'
collect2: ld returned 1 exit status
make[3]: *** [t-encrypt.exe] Error 1
/bin/sh ../../libtool --tag=CC --mode=link gcc  -g -O2 -Wall -Wcast-align 
-Wshadow -Wstrict-prototypes   -o t-encrypt-sym.exe  t-encrypt-sym.o 
../../gpgme/libgpgme.la 
gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sym.exe 
t-encrypt-sym.o  ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a 
-L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function 
`_gpgme_sema_cs_destroy':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to 
`__gpgme_ath_mutex_destroy'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function 
`_gpgme_sema_subsystem_init':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to 
`__gpgme_ath_init'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to 
`__gpgme_ath_mutex_lock'
../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to 
`__gpgme_ath_mutex_unlock'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to 
`__gpgme_ath_read'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to 
`__gpgme_ath_writ e'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid':
/usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to 
`__gpgme_ath_waitpid'
../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select':
/usr/src/gpgme/gpg

gpgme

[Wynfield Henman]

I saw the reference to "gpgme" with some misleading (to me) version
number, such as 1.1.2, tacked on and said it was in ...somewhere like
../cygwin/ports. ..

The the real version number is 1.0.3 for the latest stable, but I
guess cygwin rules/convention requires a different numbering system???

Hearing that gpgme has a port I executed  setup.exe and searched for
gpgme, but it is not there (or I can't find it alphabetically).

Any notions?

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

[Brian Dessent]

Did you really need to start a new thread for this?

Wynfield Henman wrote:

> I saw the reference to "gpgme" with some misleading (to me) version
> number, such as 1.1.2, tacked on and said it was in ...somewhere like
> ../cygwin/ports. ..

Cygwin Ports is a separate project.  Type it into Google and follow the
first hit.  It's off-topic for this list because it has its own mailing
list.

> guess cygwin rules/convention requires a different numbering system???

Um, no.  Have you even looked at the gpgme ftp site?

ftp://ftp.gnupg.org/gcrypt/gpgme/

> Hearing that gpgme has a port I executed  setup.exe and searched for
> gpgme, but it is not there (or I can't find it alphabetically).

You need to add the URL to setup.exe if you want to use it.  Again, it's
not part of the official Cygwin project.

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/

1.5.21-1 Release: System resources not freed, can lead to system reboot.

[Dave Silvia]

Hi!

I have a simple script that illustrates a problem I'm dealing with in installing
a software package which operates under Cygwin. It uses a modified
configure/config.status scripting and then runs a make. The problem is that when
the scripts are running, it seems they keep invoking other scripts and the
resources are left allocated. So, by the time it gets to the make, there are not
enough resources and the build aborts. When I go into Windows Task Manager, even
though the Cygwin (bash) shells have long since terminated, the resources are
not freed.

If I run the simple script, it shows the same type of behavior, i.e., slowly
eroding resources. And, if I just let it keep running, it doesn't see that the
resources have been used up and the system reboots.

--
#!/bin/sh

#filename: keepGoing.sh

echo Howdy!

./keepGoing.sh
--

I have a Windows XP Pro SP2 platform with 1024 Mb Ram and about 60 Gb free disk
space and a min/max pagefile of 2/6 Gb

My question is, does this exhibit expected behavior?

I've checked the FAQ and mail archive, but nothing appears to be related. But
then, I may not be using the "magic" search phrase.

thx,
Dave S.

wxMS_developers · Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/join


wxMS_developers RSS feed
http://rss.groups.yahoo.com/group/wxMS_developers/rss


wxWidgets Code Exchange
http://wxcodex.net/

--
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 does Cygwin store its parameters?

[Dave Silvia]

Hi!

I'm trying to write a script that knows what the user selected for parameters at
installation.  For example, What type of line endings (CRLF, LF, etc.). Where
does Cygwin store this sort of information, if anywhere?

thx,
Dave S.

wxMS_developers · Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/join


wxMS_developers RSS feed
http://rss.groups.yahoo.com/group/wxMS_developers/rss


wxWidgets Code Exchange
http://wxcodex.net/

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

python-impacket

[nofear0720]

does anybody know where the python-impacket library can be downloaded for
cygwin ?? 

thanks in advance
-- 
View this message in context: 
http://www.nabble.com/python-impacket-tf2750630.html#a7674346
Sent from the Cygwin Users mailing list archive at Nabble.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/

GCC 3.4.4-2 libg2c vs. lib search path

[Axel Naumann]

Hi,

yes, I have gcc-g77 installed :-)

GCC 3.4.4-2 can't find libg2c.a; look e.g. at gcc -lg2c vs. gcc -lm. The
same problem exists for libfrtbegin.a.

This looks like a regression from 3.4.4-1. The cygwin package search
tells me:
3.4.4-1: usr/lib/gcc/i686-pc-cygwin/3.4.4/libg2c.a
3.4.4-2: usr/lib/gcc/i686-pc-cygwin/libg2c.a

But for 3.4.4-2 gcc -print-search-dirs gives

libraries: =/usr/lib/gcc/i686-pc-cygwin/3.4.4/:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../:
/lib/i686-pc-cygwin/3.4.4/:
/lib/:
/usr/lib/i686-pc-cygwin/3.4.4/:
/usr/lib/

(my line breaks)

Could someone have a look at it, please? I can survive now with

cd /usr/lib/gcc/i686-pc-cygwin/3.4.4/
ln -s ../libg2c.a
ln -s ../libfrtbegin.a

but I don't want to make that too public (even more public than
cygwin@cygwin.com, that is :-)

Cheers, Axel.

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

Please ignore: GCC 3.4.4-2 libg2c vs. lib search path

[Axel Naumann]

If only I could use search properly :-/ Sorry about the noise.

Axel.


Axel Naumann wrote:
> Hi,
> 
> yes, I have gcc-g77 installed :-)
> 
> GCC 3.4.4-2 can't find libg2c.a; look e.g. at gcc -lg2c vs. gcc -lm. The
> same problem exists for libfrtbegin.a.
> 
> This looks like a regression from 3.4.4-1. The cygwin package search
> tells me:
> 3.4.4-1: usr/lib/gcc/i686-pc-cygwin/3.4.4/libg2c.a
> 3.4.4-2: usr/lib/gcc/i686-pc-cygwin/libg2c.a
> 
> But for 3.4.4-2 gcc -print-search-dirs gives
> 
> libraries: =/usr/lib/gcc/i686-pc-cygwin/3.4.4/:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../:
> /lib/i686-pc-cygwin/3.4.4/:
> /lib/:
> /usr/lib/i686-pc-cygwin/3.4.4/:
> /usr/lib/
> 
> (my line breaks)
> 
> Could someone have a look at it, please? I can survive now with
> 
> cd /usr/lib/gcc/i686-pc-cygwin/3.4.4/
> ln -s ../libg2c.a
> ln -s ../libfrtbegin.a
> 
> but I don't want to make that too public (even more public than
> cygwin@cygwin.com, that is :-)
> 
> Cheers, Axel.
> 

--
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 does Cygwin store its parameters?

[Dave Korn]

On 04 December 2006 11:04, Dave Silvia wrote:

> Hi!
> 
> I'm trying to write a script that knows what the user selected for
> parameters at installation.

  Are you sure this is the best way to achieve whatever end result you're
using?  Give us some more detail, maybe there's a better way without having to
know this stuff.

>   For example, What type of line endings (CRLF, LF, etc.). Where 
> does Cygwin store this sort of information, if anywhere?

  The type of line-endings can be inferred from the mount-mode of the root
directory; it's not stored explicitly anywhere AFAIK.  Most of the remaining
information is stored in /etc/setup/last-{action,cache,connection,mirror}.



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: Ctrl-C and non-cygwin programs

[Simon Marlow]

Brian Dessent wrote:
> Simon Marlow wrote:
>
>> Then run the program, hit Ctrl-C and see what happens.  The
> behaviour differs depending on the environment:
>>
>>   * In a Cygwin shell started from cygwin.bat, with the CYGWIN
>> environment variable empty: correct behaviour, Ctrl-C is caught
>> and handled.
>>
>>   * In a Cgwin shell started from cygwin.bat, with CYGWIN=tty:
>> Ctrl-C apparently just kills the child process, the event is
>> not caught.
>>
>>   * In an xterm (Cygwin), with Cygwin bash: again, the child process
>> is just killed.
>>
>>   * In a CMD.EXE shell, Ctrl-C is caught and handled.
>
> The problem is that in the case of CYGWIN=tty or under xterm/rxvt, the
> program is not attached to a Windows console at all.  It is running
> under a Cygwin pseudoterminal (pty), which to a non-Cygwin
> app will look
> as if it was totally detached with just pipes connected to stdin and
> stdout.  Since there's no console, there's no way for a
> ConsoleCtrlHandler event to fire.

Ok, thanks.  So the bit I didn't realise was that a process needs to be 
attached to an actual Windows console in order to get Ctrl-C events.  This is a 
bit of a problem, because it essentially means that a Cygwin shell running in 
either CYGWIN=tty mode or in an xterm cannot behave like a Windows shell for 
invoking non-cygwin console programs.  Any console program that relies on being 
able to catch Ctrl-C to clean up cannot be used reliably from an xterm.

This is a shame, because I really like using Cygin xterm under windows - its 
terminal behaviour seems a lot more reliable than the Cygwin bash console.  
Incedentally, what does bash do to the child process when it detects Ctrl-C and 
there's no console?  TerminateProcess()?

I have one suggestion: could this be documented somewhere please?  I spent a 
lot of time searching mailing lists and documentation for the answer to this 
question, but didn't find it anywhere.  Apologies if I missed it.

Cheers,
Simon

--
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: bash scripting problem

[Andrew Louie]

Gary R. Van Sickle  worldnet.att.net> writes:


> Do you have a link to such a script?  I don't mean a proof-of-principle; I'm
> sure a suitable example can be contrived.  What I'm looking for is a shell
> script "in the wild" that purposely has a carriage return embedded in it for
> reasons other than ending a line of the script.
> 

I'm not sure what you mean. The scripts that give me problems are packages (like
the configure script for subversion 1.4x, before the cygwin release) and simple
bash scripts i created in VIM 7 to just change directories and run perl scripts
both had this dos line endings problem. 

all of my mounts are mounted binmode.

Is there a utility like a hex editor for cygwin that can check files for the
"\r" line endings?


--
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: bash scripting problem

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Andrew Louie on 12/4/2006 6:37 AM:
> Is there a utility like a hex editor for cygwin that can check files for the
> "\r" line endings?

od can display the contents of a file (I like 'od -Ax -tcz').  Or you can
use 'file', which detects CRLF line endings in text files.  Or go for
broke and use hexl-mode of emacs.  In short, yes, there are a number of
cygwin utilities that can detect line endings.

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

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

iD8DBQFFdCb+84KuGfSFAYARAgzPAKClhUgTEe7ZQej9MN+1Jzymcf+1xQCgmBWa
XZ38+j6/KH2O/qn9XO4Fe5I=
=dWZq
-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/

Vista x64 STARTUPINFO Issue

[McArdle, Christian]

As I understand it, cygwin doesn't yet work on Vista x64. Does anyone know if a 
fix is under development?

>From what I have read, it is related to Windows no longer using the 
>STARTUPINFO reserved parameters to pass information onto the new process. I 
>have no idea exactly how cygwin does this, but I've done similar things in a 
>more portable fashion using named pipes (named after a newly created GUID), so 
>whether that would be a solution or not, I don't know...

Christian.

_
This email message, including any attachments, may contain confidential and 
proprietary information for the sole use of the intended recipient.  If you are 
not the intended recipient, you are hereby notified that any use, copying or 
dissemination of this message is strictly prohibited.  If you received this 
message in error, please notify Brooks Automation, Inc. immediately by reply 
email or by calling Brooks US Headquarters at +1 978-262-2400. Then delete this 
message from your system, without making any copy or distribution.  Thank you.

--
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: Ruby hangs when executing: ruby -r mkmf -e 'have_func("rb_hash_foreach")'

[Jared Silva]

Rebase fixed the problem for me too.

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: No manual entry for ls

[Jared Silva]

I will do what I can.

--
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: bash scripting problem

[fergus]

>> Is there a utility like a hex editor for cygwin that can check files 
for the

>> "\r" line endings?

> od can display the contents of a file (I like 'od -Ax -tcz').
> Or you can use 'file', which detects CRLF line endings in text files.
> Or go for broke and use hexl-mode of emacs.

Or

   grep -l "^M" 

(typed at the keyboard as ctrl-V ctrl-M). This might give you what you 
want ...


Fergus

--
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: Ctrl-C and non-cygwin programs

[Brian Dessent]

(There's no need to CC me individually, I set the Reply-To: to the
list.)

Simon Marlow wrote:

> Ok, thanks.  So the bit I didn't realise was that a process needs to be 
> attached to an actual Windows console in order to get Ctrl-C events.  This is 
> a bit of a problem, because it essentially means that a Cygwin shell running 
> in either CYGWIN=tty mode or in an xterm cannot behave like a Windows shell 
> for invoking non-cygwin console programs.  Any console program that relies on 
> being able to catch Ctrl-C to clean up cannot be used reliably from an xterm.

This is hardly the only problem you will face when running non-Cygwin
programs attached to a pty.  Native programs (that is, those that use
MSVCRT as C library) will see stdout as a pipe and thus will buffer
their output by default, which can be very confusing for interactive
programs when you get no output and then all of a sudden 4k worth.  And
likewise for input, a native program will think that its stdin is a pipe
and not a console, and thus many interactive programs will fail to work
when attached to a pty, especially those with a password prompt.  Try
using the Windows version of telnet.exe in a xterm, it ain't pretty.  So
the ctrl-C behavior is just one in a long list.

> This is a shame, because I really like using Cygin xterm under windows - its 
> terminal behaviour seems a lot more reliable than the Cygwin bash console.

The thing you need to realize is that the goal of the Cygwin project is
to provide the ability to compile and execute POSIX code without
modification.  Replacing the Windows Console API with something else
that's usable for foreign/non-Cygwin apps is secondary.

To be able to accomplish this, the Cygwin DLL has to invent a number of
ficticious APIs and concepts that simply do not exist on Windows, or
exist in a limited matter but in such a restrictive way as to be
useless.  The list of such fictions includes fork(), exec(), signals,
pseudoterminals, etc.  The only way to maintain the illusion of these
things working is by having all processes "in on the joke", i.e. linked
against cygwin1.dll and cooperating.  When you have a native application
in the mix that has no idea what a pty is, it's just going to see a
pipe.  And a native application has no (real) concept of "how do I
handle SIGINT", all it has is this ConsoleCtrlHandler thing which only
works if it's attached to a console.

> Incedentally, what does bash do to the child process when it detects Ctrl-C 
> and there's no console?  TerminateProcess()?

No. Remember the whole idea is to run POSIX code unmodified?  bash has
no idea that it's running under Windows, it's running the same code path
as it would on *nix.  So on *nix, when you press ^C, the tty device
driver sends SIGINT to the foreground process group.  The shell is not
involved in this at all, except that it is responsible for arranging all
of the processes in the pipeline into a process group.  The difference
between Linux and Cygwin is that on Linux the tty device driver is part
of the kernel, but since this idea of a tty does not exist on Windows
this code is all in the cygwin DLL.

What you may be asking is, "in the case of a native program, since there
is nothing to receive a SIGINT, how does this turn into the process
being terminated (and the ConsoleCtrlHandler being run if it was
attached to a console)?"  In the case of a Cygwin process exec()ing a
non-Cygwin process, the way this is handled is by leaving behind a stub
process.  The stub is the remainder of the Cygwin process before it
exec()ed (recall that Windows has no actual exec(), so replacing one
process with another has to be faked by spawning a new process and then
pretending it has the PID of the exec()ed one), and its function is to
receive signals on behalf of the non-Cygwin process that it supposedly
exec()ed.  When it receives a SIGINT and there is no console, the only
thing it can do is terminate the process.

Now, I suppose that it might be possible in this exec() emulation code
to always create a hidden, unused console for the non-Cygwin process
even if it will not actually be interacting with it, for the sole
purpose of being able to call this ConsoleCtrlHander stuff.  I don't
know if this is possible or if it would break other things.  It would be
extremely annoying to see a console flash and then disappear every time
a native program was executed from a pty.  There may be a way to
suppress this flashing, but that would require even further kludging I'm
sure, and it may not be possible on older versions of Windows.

I think at the end of the day though the problem here is that getting
non-Cygwin applications to work sanely with ptys is not a high priority
compared to providing a full and rich set of emulation for POSIX APIs. 
In other words, if you have problems using the Windows version of
telnet.exe you should install the inetutils package and use the Cygwin
version.  And likewise, if you want your program to be able to
gr

Resources not freed

[fergus]

I nicked the title from a recent post.

Some Cygwin sessions (specifically those using "find" or "diff", and 
when the task is very great, as in say "diff -rq /largedisk1 
/largedisk2"*) I find that hogged resources are not freed when Cygwin is 
exit-ed. The egg-timer churns away on rather simple Explore requests, 
and there's lots of disk-hunting. The system never seems to recover. 
Usually I re-boot.


* I do this a lot, being over-anxious about backup.

As far back as 2003 and as recently as 2006 there are posts about this, 
with references to virtual memory, swap memory and so on, not being 
freed. It seems to be a subtly difficult problem to describe, or perhaps 
it wears many guises.


1. Have I identified a real phenomenon or am I imagining it?

2. Can you characterise the class(es) of Cygwin activity most prone to 
cause this?


3. Is there anything to be done to improve matters (eg, increasing RAM 
from 512M to 1G or even 2G)?


Thank you.

Fergus

PS Is there a switch I can add to "find /" so that /proc is not traversed?

--
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: bash scripting problem

[Kenneth Nellis]

-Original Message-
From: Rob Walker 
Sent: Friday, December 01, 2006 6:29 PM
To: cygwin@cygwin.com
Subject: Re: bash scripting problem

d2u may also corrupt "text" files that need to have CR in them.  This 
includes bash scripts that need to parse or output CR.

-Response Message-
I found it surprising, but verified that it is not a Cygwin issue,
that d2u (a k a dos2unix) blindly deletes all CRs. Curious why it
wouldn't only delete CRs that precede LFs, thus allowing singleton CRs.
Not a Cygwin issue per se, but one of which its users must be aware.
--Ken Nellis


--
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: GPGME 1.0.3 Build Problem

[Marcus Brinkmann]

At Mon, 04 Dec 2006 18:42:01 +0900,
"djh" <[EMAIL PROTECTED]> wrote:
> 
>  here are the results I get from using everthing in:
> 
>   * gpgme-1.0.3.tar.gz
>  
> with the exceptipn of Makefile.am, which I used the new 1192 revision 
> Makefile.am
> which was mv'd to Makefile.am for the following:

That can't work.  Makefile.am is the basis for the generated files
Makefile.in and Makefile, the latter of which is actually used.  These
files are only automatically generated when in maintainer mode.

If you have the development tools installed, you can easily recreate
these files by running ./autogen.sh in the toplevel directory.
Otherwise, please let me know and I will send you a patch against
1.0.3 or a complete tar ball.

Thanks,
Marcus


--
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: Problem with perl debugger and stdin

[Yitzchak Scott-Thoennes]

On Sat, Dec 02, 2006 at 02:25:24PM -0800, Andrew Certain wrote:
> In a normal UNIX environment, you can run the perl debugger 
> and still redirect an input file to stdin.  In other words,
> 
> perl -d myscript < mydata
> 
> does the right thing, namely, that you enter the debugger, the debugger
> reads input from the keyboard, but if the script reads from STDIN, it gets
> lines from mydata.
> 
> Under cygwin, however, the same invocation causes the debugger to read
> commands from mydata.

There's probably something the debugger is doing for linux but not for cygwin
because it thinks cygwin can't do it, but a quick scan of perl5db.pl didn't
reveal it to me.

Doing
   PERLDB_OPTS=TTY=/dev/tty perl -d ...
should work, though.

> Please include this line when replying.

Is this some kind of behaviorist experiment?  What's my prize?

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

vi and terminal behaviour

[Carles Cufi]

Hi there,

I have been using both the default Cygwin shell and rxvt for a while.
I seem to have some trouble getting the terminal emulators to behave correctly 
(i.e. as it does under Linux).
When I edit a file using vi and use the "cw" key sequence to change a word, the 
expected outcome is for the word under the cursor to disappear and switch to 
insert mode so that it can be replaced with what the user types next.
However under both the default Cygwin shell and rxvt I get a $ dollar sign at 
the end of the word after pressing "cw" instead of the word disappearing, both 
terminals behave identically.
The graphical version of vim, gvim, works as expected.

Is there something I need to tweak to make this work as in gvim or the Linux 
version of vim?

Thanks in advance,

Carles




 

Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

--
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: vi and terminal behaviour

[Matt Wozniski]

On 12/4/06, Carles Cufi wrote:

However under both the default Cygwin shell and rxvt I get a $ dollar sign at 
the end
of the word after pressing "cw" instead of the word disappearing, both terminals
behave identically.


Carlos:
That is vim's default behavior.  To get the behavior you want, you
need "set nocompatible" in your .vimrc (or, copy it over from your
linux box with, eg. scp)

--
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: Vista x64 STARTUPINFO Issue

[Larry Hall (Cygwin)]

McArdle, Christian wrote:

As I understand it, cygwin doesn't yet work on Vista x64. Does anyone know
if a fix is under development?


From what I have read, it is related to Windows no longer using the
STARTUPINFO reserved parameters to pass information onto the new process.
I have no idea exactly how cygwin does this, but I've done similar things
in a more portable fashion using named pipes (named after a newly created
GUID), so whether that would be a solution or not, I don't know...


From the above, it's seems like you've read this thread but if not, this is
the current state of affairs:



If you have some ideas that you'd like to propose, feel free.  :-)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

--
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: Vista x64 STARTUPINFO Issue

[Corinna Vinschen]

On Dec  4 13:17, Larry Hall (Cygwin) wrote:
> McArdle, Christian wrote:
> >As I understand it, cygwin doesn't yet work on Vista x64. Does anyone know
> >if a fix is under development?
> >
> >>From what I have read, it is related to Windows no longer using the
> >>STARTUPINFO reserved parameters to pass information onto the new process.
> >>I have no idea exactly how cygwin does this, but I've done similar things
> >>in a more portable fashion using named pipes (named after a newly created
> >>GUID), so whether that would be a solution or not, I don't know...
> 
> From the above, it's seems like you've read this thread but if not, this is
> the current state of affairs:
> 
> 
> 
> If you have some ideas that you'd like to propose, feel free.  :-)

Looks like I have solved this issue today, but I'm still testing.
Stay tuned.


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: Please test the latest developer's snapshot

[Ben]

Sorry;

From my admittedly confused reading of the list traffic, I thought

that the patches in the snapshot would also work on 64-bit.

Ben

On Dec  4 02:20, Ben wrote:

> Just wanted to drop in a note saying that I've tried the snapshot on
> RTM Vista x64 on AMD, and I had no luck, either freshly installed, or
> with rebase/rebaseall. I tried rebaseall with ash, but got the usual
> Vista-related errors. I tried running rebase against ash, and then
> rebaseall again, but still no joy. All of the above I ran using first
> 0x7000 as base, and then 0x6500.

http://cygwin.com/ml/cygwin/2006-11/msg00595.html


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: Where does Cygwin store its parameters?

[Dave Korn]

On 04 December 2006 12:07, Dave Korn wrote:

  JFTR:  This is pretty ham-fistedly worded so I will clarify FTA.

> On 04 December 2006 11:04, Dave Silvia wrote:
> 
>> Hi!
>> 
>> I'm trying to write a script that knows what the user selected for
>> parameters at installation.

>>   For example, What type of line endings (CRLF, LF, etc.). Where
>> does Cygwin store this sort of information, if anywhere?
> 
>   The type of line-endings can be inferred from the mount-mode of the root
> directory; it's not stored explicitly anywhere AFAIK.  

  What I mean is that there is no explicit flag anywhere that says "cygwin was
installed in binary or text mode".

  The mount-mode of the root directory *is* of course explicitly stored, in
the registry; and if it has not been changed since, you can /deduce/ that the
current mode is the result of the mode chosen last time setup.exe was run.


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/

printf '\377\376h\000\r\000\n\000'|file - #wrong result?

[Tom Rodman]

Should this directed to the "file" package maintainer?:

   ~ $   date;uname -a
   Mon Dec  4 14:31:38 CST 2006
   CYGWIN_NT-5.0 OurServer121 1.5.22(0.156/4/2) 2006-11-13 17:01 i686 Cygwin
   ~ $ printf '\377\376h\000\r\000\n\000'|file -
   /dev/stdin: MPEG ADTS, layer I, v1, 192 kBits, 32 kHz, Stereo
   --snip
   ~ $ date;uname -a
   Mon Dec  4 14:34:15 CST 2006
   Linux localhost.localdomain 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 
i686 i386 GNU/Linux
   ~ $ printf '\377\376h\000\r\000\n\000'|file -
   standard input:  Little-endian UTF-16 Unicode character data, 
with CR line terminators
   ~ $

>From above you can see linux and cygwin "file" output differs.  The printf
above was inspired recently when "file" mis-identified a unicode file.

I don't think this is a new problem.

--
thanks,
Tom 

--
PS
  above unicode contains one line with a single "h" char

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

/etc/setup/last-* files and quiet setup conflict (was: Where does Cygwin store its parameters?)

[cuicui]

Dave Korn wrote:

On 04 December 2006 11:04, Dave Silvia wrote:


Hi!

I'm trying to write a script that knows what the user selected for
 parameters at installation.


Are you sure this is the best way to achieve whatever end result 
you're using?  Give us some more detail, maybe there's a better way 
without having to know this stuff.



For example, What type of line endings (CRLF, LF, etc.). Where does
 Cygwin store this sort of information, if anywhere?


The type of line-endings can be inferred from the mount-mode of the 
root directory; it's not stored explicitly anywhere AFAIK.  Most of 
the remaining information is stored in 
/etc/setup/last-{action,cache,connection,mirror}.


BTW, i've recently planned to autoupdate the Cygwin environment (using
switches of setup.exe and a "virtual" package on "Base" category) on the
workstations i manage and i noticed that remaining /etc/setup/last-*
files take precedence over the setup switches.

In other words if the last action was "Install from Internet" and the
setup switch is "setup -L ...", the setup will try to download files
from Internet instead of using the local directory only.

That was an issue for me as far as my files are stored on a public SaMBa
share (read only).

Cleaning /etc/setup/last-* before setup files does the trick.

Anyway, this was just to mention a possible minor bug. Another
suggestion for quiet setup: no possibilities for the user to close the
window (equivalent to the "/qb!" option of msiexec) when using the quiet
option...

All the best,

Nicolas C.

--
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.


--
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: printf '\377\376h\000\r\000\n\000'|file - #wrong result?

[Corinna Vinschen]

On Dec  4 14:47, Tom Rodman wrote:
> Should this directed to the "file" package maintainer?:

No.  You're using different versions of the `file' package.  The output
of `file' is based on data files which are updated with each new version.

Hint: Don't rely on the output of file being 100% accurate.  It's using
  approximations based on descriptions of file headers and typical
  content.


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: 1.5.21-1 Release: System resources not freed, can lead to system reboot.

[Matthew Woehlke]

Dave Silvia wrote:

I have a simple script that illustrates a problem I'm dealing with in installing
a software package which operates under Cygwin. It uses a modified
configure/config.status scripting and then runs a make. The problem is that when
the scripts are running, it seems they keep invoking other scripts and the
resources are left allocated. So, by the time it gets to the make, there are not
enough resources and the build aborts. When I go into Windows Task Manager, even
though the Cygwin (bash) shells have long since terminated, the resources are
not freed.

If I run the simple script, it shows the same type of behavior, i.e., slowly
eroding resources. And, if I just let it keep running, it doesn't see that the
resources have been used up and the system reboots.

--
#!/bin/sh

#filename: keepGoing.sh

echo Howdy!

./keepGoing.sh
--


Well, yes, you have an infinite recursion similar to a classical stack 
overflow, only in this instance it is processes that you overflow. That 
last line invokes a new shell process to run the script, and waits for 
said process to exit. What are you *expecting* to happen? Your script 
fails to illustrate any reasonable problem.



thx,
Dave S.
[three wx* links snipped]


Hmm, that's a lot of lines for a .sig, especially rather spammy ones. If 
those are yours, you might want to consider a more polite (read: 
shorter) signature.


--
Matthew
"Briins!" -- Zombies


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

Setting vim to nocompatible by default in Cygwin

[Carles Cufi]

Hi there,

After some discussion with Matt Wozniski I've come to the conclusion that the 
default global config file for vim (/usr/share/vim/vimrc) included with Cygwin 
differs quite importantly from the ones included in other UNIX-like operating 
systems like Linux or Mac OS X (and yes, I know Cygwin is not an OS...)
The key difference is that Cygwin does not set the "nocompatible" flag by 
default, something the other two OSs do. This results in old style vi-like 
behavior when editing with vim, which I personally feel is undesirable.
I would therefore suggest to include the "nocompatible" flag set by default 
when installing Cygwin.

Thanks,

Carles




 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

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

bash CRLF problems (I have read the recent announcement)

[Kevin Layer]

I'm really perplexed by the following behavior:

[EMAIL PROTECTED] ~
$ cat -v foo1.sh
echo 8010 > foo1.out

[EMAIL PROTECTED] ~
$ cat -v foo2.sh
sh foo1.sh
version=`cat foo1.out`
echo ${version}.bar > foo2.out
cat -v foo2.out

[EMAIL PROTECTED] ~
$ sh foo2.sh
8010^M.bar^M

[EMAIL PROTECTED] ~
$ mount
C:\cygwin\bin on /usr/bin type system (textmode)
C:\cygwin\lib on /usr/lib type system (textmode)
C:\cygwin on / type system (textmode)
c: on /c type system (textmode)
z: on /z type system (textmode)

[EMAIL PROTECTED] ~
$


The (real) scripts involved run on non-Windows platforms, so putting
in `d2u' isn't an option.  I'd rather not resort to `tr' either, since
I have a large number of places to fix.  Large.

The bug, IMO, is the assigment to version of `cat foo1.out` contains a
^M.  I'm on a text mount, so this is counter to what I thought would
happen.

I experimented with `igncr' and couldn't get it to work.

Help?  Thanks

installation details:

Cygwin Configuration Diagnostics
Current System Time: Mon Dec 04 14:53:33 2006

Windows 2003 Server Ver 5.2 Build 3790 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
.
c:\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\emacs-21.3\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\Intel\DMIX
c:\Program Files\Microsoft Platform SDK\Bin\
c:\Program Files\Microsoft Platform SDK\Bin\WinNT\
c:\Program Files\Microsoft Platform SDK\bin\win64\x86\AMD64

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 5(rfr)  GID: 10513(Domain Users)
544(Administrators)  545(Users)   10513(Domain Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 5(rfr)  GID: 10513(Domain Users)
544(Administrators)  545(Users)   10513(Domain Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

USER = 'rfr'
PWD = '/c'
CYGWIN = 'nontsec'
HOME = '/home/rfr'
MAKE_MODE = 'unix'

MSSDK = 'C:\Program Files\Microsoft Platform SDK\.'
HOMEPATH = '\Documents and Settings\rfr'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = 'C:\Documents and Settings\rfr\Application Data'
PROGRAMW6432 = 'C:\Program Files'
HOSTNAME = 'mad64'
MSTOOLS = 'C:\Program Files\Microsoft Platform SDK\.'
TERM = 'cygwin'
PROCESSOR_IDENTIFIER = 'AMD64 Family 15 Model 4 Stepping 10, AuthenticAMD'
WINDIR = 'C:\WINDOWS'
COMMONPROGRAMW6432 = 'C:\Program Files\Common Files'
CVSROOT = '[EMAIL PROTECTED]:/cvs'
OLDPWD = '/home/rfr'
USERDOMAIN = 'FRANZ'
COMMONPROGRAMFILES(X86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
TEMP = '/c/DOCUME~1/rfr/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
LIB = 'C:\Program Files\Microsoft Platform SDK\Lib\AMD64;C:\Program 
Files\Microsoft Platform SDK\Lib\AMD64\atlmfc'
USERNAME = 'rfr'
PROCESSOR_LEVEL = '15'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
USERPROFILE = 'C:\Documents and Settings\rfr'
PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\TWINKIE'
PROCESSOR_ARCHITECTURE = 'x86'
!C: = 'C:\cygwin\bin'
SHLVL = '1'
USERDNSDOMAIN = 'WIN.FRANZ.COM'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
INETSDK = 'C:\Program Files\Microsoft Platform SDK\.'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/c/DOCUME~1/rfr/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
CVS_RSH = '/bin/ssh'
PROCESSOR_REVISION = '040a'
BASEMAKE = 'C:\Program Files\Microsoft Platform SDK\Include\BKOffice.Mak'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files (x86)'
BKOFFICE = 'C:\Program Files\Microsoft Platform SDK\.'
NUMBER_OF_PROCESSORS = '1'
PROGRAMFILES(X86) = 'C:\Program Files (x86)'
INCLUDE = 'C:\Program Files\Microsoft Platform SDK\Include\crt;C:\Program 
Files\Microsoft Platform SDK\Include\mfc;C:\Program Files\Microsoft Platform 
SDK\Include'
SESSIONNAME = 'Console'
COMPUTERNAME = 'MAD64'
_ = '/usr/bin/cygcheck'
POSIXLY_CORRECT = '1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x0020
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = 'c:'
  flags = 0x0008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin/bin'
  flags = 0x0008
HKEY_

Re: bash CRLF problems (I have read the recent announcement)

[Larry Hall (Cygwin)]

Kevin Layer wrote:

I'm really perplexed by the following behavior:

[EMAIL PROTECTED] ~
$ cat -v foo1.sh
echo 8010 > foo1.out

[EMAIL PROTECTED] ~
$ cat -v foo2.sh
sh foo1.sh
version=`cat foo1.out`
echo ${version}.bar > foo2.out
cat -v foo2.out

[EMAIL PROTECTED] ~
$ sh foo2.sh
8010^M.bar^M

[EMAIL PROTECTED] ~
$ mount
C:\cygwin\bin on /usr/bin type system (textmode)
C:\cygwin\lib on /usr/lib type system (textmode)
C:\cygwin on / type system (textmode)
c: on /c type system (textmode)
z: on /z type system (textmode)

[EMAIL PROTECTED] ~
$


The (real) scripts involved run on non-Windows platforms, so putting
in `d2u' isn't an option.  I'd rather not resort to `tr' either, since
I have a large number of places to fix.  Large.

The bug, IMO, is the assigment to version of `cat foo1.out` contains a
^M.  I'm on a text mount, so this is counter to what I thought would
happen.



Time to adjust your expectations. ;-)  Text mounts write CRNL as EOLs
for all files that are not explicitly opened as binary (or text for
that matter).  Text mounts remove the CR from EOLs read from files that
are not explicitly opened as binary (or text).  'cat' explicitly opens
the file as binary.  If you need it to work otherwise, write a simple
wrapper.  Or just do the easy thing and change your mode to 'binary'
and run 'd2u' on your local versions of the scripts.  This is most
compatible with the majority of "non-Windows" platforms. ;-)



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

--
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: bash CRLF problems (I have read the recent announcement)

[Kevin Layer]

Larry Hall (Cygwin) <[EMAIL PROTECTED]> wrote:

>> > version=`cat foo1.out`
>> > ...
>> Time to adjust your expectations. ;-)  Text mounts write CRNL as EOLs
>> for all files that are not explicitly opened as binary (or text for
>> that matter).  Text mounts remove the CR from EOLs read from files that
>> are not explicitly opened as binary (or text).  'cat' explicitly opens
>> the file as binary.  

What is the portable way to get the contents of foo1.out into a
variable, getting proper translation of the end of lines?  (If the
answer is use `d2u' that is not portable.)  I thought I was safe by
using text mounts--I spent quite a while looking at the archives
before posting and thought I had covered all bases. 

Kevin

--
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: bash CRLF problems (I have read the recent announcement)

[Wilks, Dan]

Kevin Layer wrote:
> I'm really perplexed by the following behavior:
>
> [EMAIL PROTECTED] ~
> $ cat -v foo1.sh
> echo 8010 > foo1.out
>
> [EMAIL PROTECTED] ~
> $ cat -v foo2.sh
> sh foo1.sh
> version=`cat foo1.out`
> echo ${version}.bar > foo2.out
> cat -v foo2.out
>
> [EMAIL PROTECTED] ~
> $ sh foo2.sh
> 8010^M.bar^M
>
> [EMAIL PROTECTED] ~
> $ mount
> C:\cygwin\bin on /usr/bin type system (textmode)
> C:\cygwin\lib on /usr/lib type system (textmode)
> C:\cygwin on / type system (textmode)
> c: on /c type system (textmode)
> z: on /z type system (textmode)
>
> [EMAIL PROTECTED] ~
> $
>
>
> The (real) scripts involved run on non-Windows platforms, so putting
> in `d2u' isn't an option.  I'd rather not resort to `tr' either, since
> I have a large number of places to fix.  Large.
>
> The bug, IMO, is the assigment to version of `cat foo1.out` contains a
> ^M.  I'm on a text mount, so this is counter to what I thought would
> happen.

I don't know if this helps you or not, but I get slightly different
output, consistent with what I believe you expected.  igncr will indeed
eat the \r from the `cat...` (thanks Eric once again).  Unfortunately
you're still left with the trailing \r from the last cat.

[EMAIL PROTECTED]:~% sh foo2.sh
8010.bar^M

[EMAIL PROTECTED]:~% sh --version
GNU bash, version 3.2.5(7)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.

[EMAIL PROTECTED]:~% echo $SHELLOPTS
braceexpand:emacs:hashall:histexpand:history:igncr:interactive-comments:
monitor

But as was recently pointed out on the list, echo -n would suppress the
final \r in your test case.

Dan

--
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: Resources not freed

[Gary Johnson]

On 2006-12-04, fergus wrote:

> PS Is there a switch I can add to "find /" so that /proc is not traversed?

find / -path /proc -prune -o -name foo -print

If you omit the final -print, "/proc" will be printed along with all 
occurrences of "foo".  See the find(1) man page.

Regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
 | Spokane, Washington, USA

--
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: GPGME 1.0.3 Build Problem

[djh]

Marcus,
 
> That can't work.  Makefile.am is the basis for the generated files
> Makefile.in and Makefile, the latter of which is actually used.  These
> files are only automatically generated when in maintainer mode.

Yes, your right. I just read about the GNU build system last night and realized 
that.  Sorry about my ignorance of the gnu autotools workflow.  I see where the 
distribution was not in an "autoconfiscated" state when I changed the .am file.

> If you have the development tools installed, you can easily recreate
> these files by running ./autogen.sh in the toplevel directory.
> Otherwise, please let me know and I will send you a patch against
> 1.0.3 or a complete tar ball.
> 
> Thanks,
> Marcus

I could find no no ./autogen.sh  in the toplevel directory.

But, I did try the below:

gpgme-1.0.3 $  aclocal  # aclocal (GNU automake) 1.9.6
--- result:
/usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of 
AM_PATH_LIBMCRYPT
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal

gpgme-1.0.3 $  automake  # automake (GNU automake) 1.9.6
--- result
Makefile.am:42: BUILD_W32_GLIB does not appear in AM_CONDITIONAL
Makefile.am:106: BUILD_W32_GLIB does not appear in AM_CONDITIONAL
Makefile.am:115: HAVE_W32_SYSTEM does not appear in AM_CONDITIONAL
Makefile.am:172: BUILD_W32_GLIB does not appear in AM_CONDITIONAL
Makefile.am:178: required file `./stpcpy.c' not found
Makefile.am:178: required file `./vasprintf.c' not found
Makefile.am:178: required file `./isascii.c' not found
Makefile.am:178: required file `./funopen.c' not found
Makefile.am:178: required file `./putc_unlocked.c' not found
Makefile.am:178: required file `./memrchr.c' not found
Makefile.am:178: required file `./ttyname_r.c' not found

Fails with $? = 1
--- 

Consequently, a new Makefile.in does not get created.


Thanks,
  Darel Henman



--
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: Unicode text editor mined 2000 release 13.2

[Thomas Wolff]

mined 2000.13.2
  (Dec 2006)

Mined is a powerful text editor with a comprehensive yet concise and 
easy-to-use user interface supporting modern interaction paradigms, 
and fast, small-footprint behaviour.

More information (with screenshots, overview and change log) 
and download are available from the mined web site at
http://towo.net/mined/



Mined 2000.13.2 is a maintenance release with enhancements in
* character input support
* interoperability


Major enhancements in release 2000.13:

Documentation enhancements:
* Revised manual structure, featuring more comprehensive new 
  chapters on
  * Structured editing support
  * Character handling support
  * Language support

Character encoding support enhancements:
* Auto-detection and explicit selection of UTF-16 with 
  and without BOM (big endian and little endian).
* Updated to Unicode 5.0.0 (final, from beta2 in 2000.12).

Character input support enhancements:
* Added support for multiple accented character input.
* Additional accent prefix keys for most frequent accents of all 
  Latin-based languages (macron, breve, dot above, ogonek, caron, stroke).
* Added support for convenient combining character input with accent prefix 
keys.
* Added support for convenient quotation marks input with accent prefix keys.
* Support for Greek (monotonic and polytonic).
* Support for Cyrillic accented characters.

Interactive enhancements:
* Revised menu structure to be more intuitive.
* Improved menu handling system.

Interoperability enhancements:
* Making use of xterm 216 mode which provides detection of 
  Alt-/Control-modified digits and punctuation keys.
* Improved support for some legacy terminals.

File handling enhancements:
* Consistent setting of file access modes when cloning a file 
  or creating a new file with executable permission.



Thomas Wolff
[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/

cygwin + vista x64

[Andrew Paprocki]

Corinna,

I've been trying to figure out why cygwin isn't working properly on
Vista x64. I saw the thread you posted to here:

http://www.cygwin.com/ml/cygwin/2006-11/msg00595.html

I see that cygwin is performing the trick outlined here:

http://www.catch22.net/tuts/undoc01.asp

(Search for "Pass arbitrary data to a child process!")

This is achieved because the child_info class is declared to have:

DWORD zero[4]; // must be zeroed

It appears as if this trick is no longer working under Vista x64. The
question is, does this code now have to resort to using
VirtualAllocEx/WriteProcessMemory, or is there a way around it?

Have you been able to isolate this into a simple binary test? I am
currently running on a Vista x64 system right now with VS2005
installed in case you would like me to try out anything which may be
of help.

-Andrew

--
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 + vista x64

[Larry Hall (Cygwin)]

Andrew Paprocki wrote:

Corinna,

I've been trying to figure out why cygwin isn't working properly on
Vista x64. I saw the thread you posted to here:

http://www.cygwin.com/ml/cygwin/2006-11/msg00595.html

I see that cygwin is performing the trick outlined here:

http://www.catch22.net/tuts/undoc01.asp

(Search for "Pass arbitrary data to a child process!")

This is achieved because the child_info class is declared to have:

DWORD zero[4]; // must be zeroed

It appears as if this trick is no longer working under Vista x64. The
question is, does this code now have to resort to using
VirtualAllocEx/WriteProcessMemory, or is there a way around it?

Have you been able to isolate this into a simple binary test? I am
currently running on a Vista x64 system right now with VS2005
installed in case you would like me to try out anything which may be
of help.



You may be interested in this update from Corinna today:




--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

--
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: bash CRLF problems (I have read the recent announcement)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Kevin Layer on 12/4/2006 3:59 PM:
> I'm really perplexed by the following behavior:
> 
> [EMAIL PROTECTED] ~
> $ cat -v foo1.sh
> echo 8010 > foo1.out
> 
> [EMAIL PROTECTED] ~
> $ cat -v foo2.sh
> sh foo1.sh
> version=`cat foo1.out`

The result of `` comes from a pipe instead of a disk file, and only disk
files are affected by text mode mounts, so command substitution can only
strip \r if igncr is set.  cat reads its inputs in binary (at one point,
cat used to read in text mode by default, unless you passed --binary, but
the upstream maintainer removed that on the ground that POSIX requires
binary behavior from cat).  I could consider adding cat --text to cygwin's
cat, but it would be cygwin-only, so you would not be very portable in
using it.  However, instead of spawning two processes to assign your
variable (a subshell for ``, then cat), you could try this instead, with
several benefits - bash opens the file in text mode, the variable
assignment is faster due to fewer processes, and the line does not rely on
any cygwin-specific extensions:

read version < foo1.out

Another thing you could do is avoid putting line endings in foo1.out in
the first place - either use 'echo -n 8081 > foo1.out', 'echo -e 8081\\c >
foo1.out' (both of which rely on unportable usage of echo), or 'printf
8081 > foo1.out' (portable to POSIX sh, but not all platforms conform to
POSIX yet).  A patch along this line was just submitted to autoconf, in
its use of files containing results of runtime programs.

> $ mount
> C:\cygwin\bin on /usr/bin type system (textmode)

Asking for problems.  Usually, it is safer if you limit textmode mounts to
the directories that contain your files, rather than globally making the
basic cygwin files text mode.

> 
> The bug, IMO, is the assigment to version of `cat foo1.out` contains a
> ^M.  I'm on a text mount, so this is counter to what I thought would
> happen.

Again, based on the POSIX wording, cat must operate on binary files, so it
opens in binary mode by default, even on text mounts.  Which means the
command substitution sees the \r.  You can also play with CYGWIN=nobinmode
to turn pipes into text mode, so that the command substitution never sees
the \r, but that has other odd effects, such as breaking 'tar xjf
foo.tar.bz2'.

> 
> I experimented with `igncr' and couldn't get it to work.

Examples of what you tried?

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

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

iD8DBQFFdPX+84KuGfSFAYARApzLAKCh46ov7l9hLZsPnrpw13K1T2JWBgCeOqFb
EkIlGw93EAndVHNyzKA+Zaw=
=fyM1
-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: gpgme

[Wynfield Henman]

On 12/4/06, Brian Dessent <[EMAIL PROTECTED]> wrote:

Did you really need to start a new thread for this?


Two issues where mentioned, which you apparently missed.


Wynfield Henman wrote:

> I saw the reference to "gpgme" with some misleading (to me) version
> number, such as 1.1.2, tacked on and said it was in ...somewhere like
> ../cygwin/ports. ..

Cygwin Ports is a separate project.  Type it into Google and follow the
first hit.  It's off-topic for this list because it has its own mailing
list.

Are you saying that "cygwin ports" are not ports of software to run on cygin?



> guess cygwin rules/convention requires a different numbering system???
Um, no.  Have you even looked at the gpgme ftp site?

Yes and it is as I stated. Now answer why the cygwin ports located
gpgme is label as version 1.2.0 when no such official version exists?


ftp://ftp.gnupg.org/gcrypt/gpgme/

Yes you can verify that the latest release is 1.0.3  NOT  1.2.xx


You need to add the URL to setup.exe if you want to use it.  Again, it's
not part of the official Cygwin project.

You're unclear here.  Do you mean that setup.exe is not inherently
related to cygwin?
Or that adding a URL to setup.exe is not.  Though it seems it should
be, if software is otherwise not available, (yet listed as a cygwin
port).

Brian


Wynfield

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

[Christopher Faylor]

On Tue, Dec 05, 2006 at 02:18:37PM +0900, Wynfield Henman wrote:
>On 12/4/06, Brian Dessent <[EMAIL PROTECTED]> wrote:
>>Did you really need to start a new thread for this?
>
>Two issues where mentioned, which you apparently missed.
>
>>Wynfield Henman wrote:
>>
>>> I saw the reference to "gpgme" with some misleading (to me) version
>>> number, such as 1.1.2, tacked on and said it was in ...somewhere like
>>> ../cygwin/ports. ..
>>
>>Cygwin Ports is a separate project.  Type it into Google and follow the
>>first hit.  It's off-topic for this list because it has its own mailing
>>list.
>Are you saying that "cygwin ports" are not ports of software to run on 
>cygin?
>
>
>>> guess cygwin rules/convention requires a different numbering system???
>>Um, no.  Have you even looked at the gpgme ftp site?
>Yes and it is as I stated. Now answer why the cygwin ports located
>gpgme is label as version 1.2.0 when no such official version exists?
>
>>ftp://ftp.gnupg.org/gcrypt/gpgme/
>Yes you can verify that the latest release is 1.0.3  NOT  1.2.xx
>
>>You need to add the URL to setup.exe if you want to use it.  Again, it's
>>not part of the official Cygwin project.
>You're unclear here.  Do you mean that setup.exe is not inherently
>related to cygwin?
>Or that adding a URL to setup.exe is not.  Though it seems it should
>be, if software is otherwise not available, (yet listed as a cygwin
>port).

He's basically saying that you have to follow the instructions on the
cygwinports web site.

cygwinports is a separate project and is only loosely affiliated with
the stuff at http://cygwin.com/ .  If you have questions about it, there are
links to mailing lists on the cygwinports web site, which, apparently is:

http://cygwinports.dotsrc.org/

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/

print from xfig

[Steven Woody]

i can run xfig successuflly, but i can not print our network printer.
it reported:

lpr: printer error: can't open 'd:\printersharename'

what do i do? thank you.

--
woody

then sun rose thinly from the sea and the old man could see the other
boats, low on the water and well in toward the shore, spread out
across the current.

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