Re: [ITP] pygtk2-2.6.3-1
On Jan 29 14:45, Yaakov S (Cygwin Ports) wrote: Yaakov S (Cygwin Ports) wrote: ftp://sunsite.dk/projects/cygwinports/release/python/pygtk2/pygtk2-2.6.3-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/python/pygtk2/pygtk2-2.6.3-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/python/pygtk2/setup.hint Uploaded into the python dir. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [please upload] monotone-0.26pre1 (test)
On Jan 29 20:21, Lapo Luchini wrote: Please upload as TEST version, keeping 0.25 as default. http://cyberx.lapo.it/cygwin/monotone/monotone-0.26pre1-1-src.tar.bz2 http://cyberx.lapo.it/cygwin/monotone/monotone-0.26pre1-1.tar.bz2 Since that's a test version, it requires to changes setup.hint. Could you please also add a link to this changes setup.hint? Thanks. PS: test release can be announced on the announce mailing list as well, that's right? Well, people would never know that a test version is available, isn't it? ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [maybe-ITP] gamin
On Jan 26 17:05, Yaakov S (Cygwin Ports) wrote: Try these: ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint Lapo, you asked for it, how about actually reviewing it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [maybe-ITP] gamin
Corinna Vinschen wrote: On Jan 26 17:05, Yaakov S (Cygwin Ports) wrote: Try these: ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.5-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint Lapo, you asked for it, how about actually reviewing it? Yes of course, just the time to actually get in the office, this is work ;-) At a first look it seems to have a bug we discovered Thursday after the mail exchange with Yaakov: Socket directory /tmp/fam-lapo has wrong permissions This is probably caused by the fact that on FAT permissions are always 755, no matter what. I and Alex will now inspect his source package and patches more specifically and propose further patches, like one to ignore the permission actually (I wonder if there is a better solution to it). Lapo
Re: [please upload] monotone-0.26pre1 (test)
Corinna Vinschen wrote: On Jan 29 20:21, Lapo Luchini wrote: Please upload as TEST version, keeping 0.25 as default. http://cyberx.lapo.it/cygwin/monotone/monotone-0.26pre1-1-src.tar.bz2 http://cyberx.lapo.it/cygwin/monotone/monotone-0.26pre1-1.tar.bz2 Since that's a test version, it requires to changes setup.hint. Could you please also add a link to this changes setup.hint? Thanks. What is right is right, here you go: http://cyberx.lapo.it/cygwin/monotone/setup.hint Works with 'genini', so I guess it works with 'upset' too. PS: test release can be announced on the announce mailing list as well, that's right? Well, people would never know that a test version is available, isn't it? ;-) Yeah, I guess so 0=) Lapo
g-b-s patch: upstream patch list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I finally made my upstream patching generic, following Igor's suggestion
of providing foo-ver-rel.patch.tar.bz2 if there is more than one patch
file being applied to foo-ver.tar.*. I used this patch on readline-5.1-2,
and have been testing it on my (soon-to-be-released) bash-3.1-2. The idea
is that you create a single file, CYGWIN-PATCHES/upstream_patches.lst,
which is a listing of pathnames relative to ${srcdir} containing upstream
patches. Then g-b-s can use the contents of that file to manipulate a
.patches directory to create/unpack the patch tarball.
2006-01-30 Eric Blake [EMAIL PROTECTED]
* templates/generic-build-script: Add ability to apply upstream
patches, listed in CYGWIN-PATCHES/upstream_patches.lst.
(mkdirs): Use new .patches directory.
(fixup): New function.
(prep): Unpack patch tarball.
(mkpatch): Apply upstream patches before doing diff.
(spkg): Make patch tarball if needed.
(checksig): Look at patch tarball sig.
(install): manifest.lst is not executable.
- --
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
iD8DBQFD3iAY84KuGfSFAYARArKCAJ9THVYXlUa7rfKrSOZN/JYacbGNPQCbBilw
fI79URGOOQqxE0OwvOYTgqk=
=jX/A
-END PGP SIGNATURE-
Index: templates/generic-build-script
===
RCS file: /cvs/cygwin-apps/packaging/templates/generic-build-script,v
retrieving revision 1.46
diff -u -p -r1.46 generic-build-script
--- templates/generic-build-script 28 Jan 2006 20:33:13 - 1.46
+++ templates/generic-build-script 30 Jan 2006 14:12:19 -
@@ -70,6 +70,7 @@ export src_orig_pkg=${topdir}/${src_orig
# determine correct names for generated files
export src_pkg_name=${FULLPKG}-src.tar.bz2
export src_patch_name=${FULLPKG}.patch
+export src_patch_tar_name=${FULLPKG}.patch.tar.bz2
export bin_pkg_name=${FULLPKG}.tar.bz2
export log_pkg_name=${FULLPKG}-BUILDLOGS.tar.bz2
@@ -80,12 +81,15 @@ export installlogname=${FULLPKG}-INSTALL
export src_pkg=${topdir}/${src_pkg_name}
export src_patch=${topdir}/${src_patch_name}
+export src_patch_tar=${topdir}/${src_patch_tar_name}
export bin_pkg=${topdir}/${bin_pkg_name}
export srcdir=${topdir}/${BASEPKG}
export objdir=${srcdir}/.build
export instdir=${srcdir}/.inst
export srcinstdir=${srcdir}/.sinst
export buildlogdir=${srcdir}/.buildlogs
+export patchdir=${srcdir}/.patches
+export upstream_patchlist=${srcdir}/CYGWIN-PATCHES/upstream_patches.lst
export configurelogfile=${srcinstdir}/${configurelogname}
export makelogfile=${srcinstdir}/${makelogname}
export checklogfile=${srcinstdir}/${checklogname}
@@ -182,12 +186,11 @@ unpack() {
tar xv${opt_decomp}f $1
}
+# make hidden directories used by g-b-s
mkdirs() {
(cd ${topdir} \
- rm -fr ${objdir} ${instdir} ${srcinstdir} \
- mkdir -p ${objdir} \
- mkdir -p ${instdir} \
- mkdir -p ${srcinstdir} )
+ rm -fr ${objdir} ${instdir} ${srcinstdir} ${patchdir} \
+ mkdir -p ${objdir} ${instdir} ${srcinstdir} ${patchdir} )
}
mkdirs_log() {
(cd ${topdir} \
@@ -195,14 +198,45 @@ mkdirs_log() {
rm -fr ${buildlogdir} \
mkdir -p ${buildlogdir} )
}
+
+# Internal function for applying upstream patches
+# $1 is directory to patch, $2 is file containing patch names
+fixup() {
+ if [ -f $2 ] ; then
+(cd $1
+for patch in `cat $2` ; do
+ echo APPLYING UPSTREAM PATCH `basename ${patch}`
+ patch -Z -p0 ${srcdir}/${patch}
+done
+)
+ fi
+}
+
+# Unpack the original tarball, and get everything set up for g-b-s
prep() {
(cd ${topdir} \
unpack ${src_orig_pkg} \
+ mkdirs \
+ if [ -f ${src_patch_tar} ] ; then
+(cd ${patchdir}
+tar xvjf ${src_patch_tar}
+if [ -f ${src_patch_name} ] ; then
+ mv ${src_patch_name} ${src_patch}
+fi
+if [ -f upstream_patches.lst ] ; then
+ for patch in `cat upstream_patches.lst` ; do
+ cp -p ${patch} ${srcdir}/${patch}
+ if [ -f ${patch}.sig ] ; then
+ cp -p ${patch}.sig ${srcdir}/${patch}.sig
+ fi
+ done
+fi )
+ fi
+ fixup ${srcdir} ${patchdir}/upstream_patches.lst
cd ${topdir} \
if [ -f ${src_patch} ] ; then \
patch -Z -p0 ${src_patch} ;\
- fi \
- mkdirs )
+ fi )
}
prep_log() {
prep $@ \
@@ -212,6 +246,8 @@ prep_log() {
tar xvjf ${topdir}/${log_pkg_name}
fi
}
+
+# Configure the package
conf() {
(cd ${objdir} \
CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
@@ -227,6 +263,8 @@ conf_log() {
conf $@ 21 | tee ${configurelogfile}
return ${PIPESTATUS[0]}
}
+
+# Rerun configure
reconf() {
(cd ${topdir} \
rm -fr ${objdir} \
@@ -237,6 +275,8 @@ reconf_log() {
reconf $@ 21 | tee ${configurelogfile}
Re: [maybe-ITP] gamin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yaakov S (Cygwin Ports) wrote:
OK, I have it built; but test results are sporadic (they vary each
time I run the tests).
I needed this patch in order to have it working on FAT32 disks, but
both on FAT and NTFS the test results seem quite consistent to me: all
is good on NTFS and all-but-test-9 on FAT.
Test 9 checks if a directory mtime gets modified when you write a file
in it and I guess FAT just doesn't work that way.
What did you mean exactly with vary each time?
- --- gamin-0.1.5-orig/libgamin/gam_api.c 2005-08-06 00:31:46.0
+0200
+++ gamin-0.1.5/libgamin/gam_api.c 2006-01-30 13:17:14.0
+0100
@@ -228,12 +229,15 @@
dir);
goto unsafe;
}
+#ifndef __CYGWIN__
+// this can't work on FAT disks, that have no permissions
if (st.st_mode (S_IRWXG|S_IRWXO)) {
gam_error(DEBUG_INFO,
Socket directory %s has wrong permissions\n,
dir);
goto unsafe;
}
+#endif
if (((st.st_mode (S_IRWXU)) != S_IRWXU)) {
gam_error(DEBUG_INFO,
Socket directory %s has wrong permissions\n,
@@ -307,12 +311,15 @@
goto cleanup;
}
#endif
+#ifndef __CYGWIN__
+// this can't work on FAT disks, that have no permissions
if (st.st_mode (S_IRWXG|S_IRWXO)) {
gam_error(DEBUG_INFO,
Socket %s has wrong permissions\n,
path);
goto cleanup;
}
+#endif
/*
* Looks good though binding may fail due to an existing server
*/
Reading that file, me and Alex have a doubt: is it normal that only 2
out of 3 times defined(__FreeBSD__) is added in the FreeBSD patch set
you added a corresponding defined(__CYGWIN__)?
I don't quite get that part, so I guess that you did either the right
thing or did forget about the last case ;-)
About possibly implementing an NT backend (using
http://tinyurl.com/c27fn probably), well, I guess it is feasible but
with 1300+ lines of code for all but the simplest backend (dnotify)
we're a bit scared about that, and moreover efficiency is not a really
big issue in our case.
Not in the short time period, that's for sure.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJD3iRJAAoJEJLw0EUVBG94d18QAKugLtFSL51ExnjXNW39hpHY
PSJ6HvJxpQDDe9/Cx0JHIrvADvgWGS3Yfl19N4p1Vq/pYTWbuh4DgXyHhQyCik+W
biawt3ocFk7xRzcy/1hRt5KqXPYhY5EspuZTekv9qTVh59rTb/MWkSGCAIAsadxO
vbnyLP13yergGLgmrHeDoR2UIqOqL2BpVsjfMsWhsQxyPiZNMRoD0ggt2/AsvKQg
OJ3exomeN93OweNw11ETZazz/HzZVCgslNz2kPbgy8JpZDphA22XLFieijDJdQwg
bixfhsEBLiN8qQDhQi5b9wh3EsnfDSRoo1OW2FoO0hAOHHemOcTc1/nC2jP5hMUe
Xzj+BXAVz01BrvrsRqcQ7tcjcAV5tXLZum8FdxnBGcWONcpq+7UnbcvOC9svvTMA
h4adUv577R5ciE6xwNcMsISjk+aHoV3oAliYe9RCnH7Lx9fKV7EC4SZFDbOCwMkd
erqkpJMwGRfksjTLBncX9ctazo0WPi0GeyU0sO7BkRb75Gq2fE84X5+Ny+kbhihW
TzSKbphJhCzFoyM1QG/sRa/dMN3X0rqjeoiPsq2MZIG39zMy8N9b95xIn8tb2yMI
6wcE6iPC8mzxJBqRc/aXnx3dFhlZrVjIrnhYAhwiVvznwSZQUNq+wNVb9taE
5v5LUSzA6zijAAvi7nbW
=mC7m
-END PGP SIGNATURE-
Re: g-b-s patch: upstream patch list
On Mon, 30 Jan 2006, Eric Blake wrote:
I finally made my upstream patching generic, following Igor's suggestion
of providing foo-ver-rel.patch.tar.bz2 if there is more than one patch
file being applied to foo-ver.tar.*. I used this patch on
readline-5.1-2, and have been testing it on my (soon-to-be-released)
bash-3.1-2. The idea is that you create a single file,
CYGWIN-PATCHES/upstream_patches.lst, which is a listing of pathnames
relative to ${srcdir} containing upstream patches. Then g-b-s can use
the contents of that file to manipulate a .patches directory to
create/unpack the patch tarball.
Heh, this is cool, thanks for doing this. I was working on the same kind
of functionality for pdksh over the weekend, and also have a whole bunch
of changes to the g-b-s, with essentially a very similar approach. Some
of your stuff looks cleaner, while some of mine may be more general --
I'll need to review and compare these in more detail. Some initial
comments on your patch below.
2006-01-30 Eric Blake ebb9atbyu.net
* templates/generic-build-script: Add ability to apply upstream
patches, listed in CYGWIN-PATCHES/upstream_patches.lst.
(mkdirs): Use new .patches directory.
(fixup): New function.
(prep): Unpack patch tarball.
(mkpatch): Apply upstream patches before doing diff.
(spkg): Make patch tarball if needed.
(checksig): Look at patch tarball sig.
(install): manifest.lst is not executable.
First off, please, please don't bundle unrelated changes into the same
patch. I like the idea of the leading comments, and of fixing up the mode
on manifest.lst, but could that be a separate patch, with a separate
ChangeLog? That makes it much easier to review the changes.
FWIW, in the comments, I'd replace g-b-s by the script everywhere,
since they will also appear in the actual build scripts. Also, I think
it's worth mentioning that depend() only lists the *static* DLL
dependencies.
Now, for the upstream patches functionality, I think it would be easier if
I actually posted my changes and we could compare on-list. I'll clean
them up and post them in the next couple of days.
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
Re: g-b-s patch: upstream patch list
On Mon, Jan 30, 2006 at 10:45:10AM -0500, Igor Peshansky wrote: 2006-01-30 Eric Blake ebb9atbyu.net * templates/generic-build-script: Add ability to apply upstream patches, listed in CYGWIN-PATCHES/upstream_patches.lst. Now, for the upstream patches functionality, I think it would be easier if I actually posted my changes and we could compare on-list. I'll clean them up and post them in the next couple of days. FWIW, when I looked at this, it looked easiest just to apply the patches in unpack().
Re: g-b-s patch: upstream patch list
On Mon, 30 Jan 2006, Yitzchak Scott-Thoennes wrote: On Mon, Jan 30, 2006 at 10:45:10AM -0500, Igor Peshansky wrote: 2006-01-30 Eric Blake ebb9atbyu.net * templates/generic-build-script: Add ability to apply upstream patches, listed in CYGWIN-PATCHES/upstream_patches.lst. Now, for the upstream patches functionality, I think it would be easier if I actually posted my changes and we could compare on-list. I'll clean them up and post them in the next couple of days. FWIW, when I looked at this, it looked easiest just to apply the patches in unpack(). Maybe, but I'd rather keep unpack() as it is -- i.e., a helper function to replace an unconditional tar xf. That way, if a package has non-tar.gz source archives, the maintainers don't have to rack their brains to figure out how to edit unpack(). 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
New Package: pygtk2-2.6.3-1
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.
Re: [maybe-ITP] gamin
Lapo Luchini wrote: I needed this patch in order to have it working on FAT32 disks, but both on FAT and NTFS the test results seem quite consistent to me: all is good on NTFS and all-but-test-9 on FAT. I'd rather not outright #ifndef __CYGWIN__ these if there's a better solution. I don't know if there's a way to determine if the drive is FAT or NTFS, but AFAICS there is a way to determine if Windows is NT or not (and presume that NT is running on NTFS and not FAT, which should be the norm), for example: http://cygnome2.sourceforge.net/install/release/nautilus/nautilus-2.4.2-cygwin.patch Although this raises an interesting question: Linux can also use FAT disks, so what happens then?? Test 9 checks if a directory mtime gets modified when you write a file in it and I guess FAT just doesn't work that way. Possibly, but I only have NTFS drives at my disposal. What did you mean exactly with vary each time? Sometimes C test 4 failed and sometimes not; some of the python tests would fail but either different ones or in different ways. Reading that file, me and Alex have a doubt: is it normal that only 2 out of 3 times defined(__FreeBSD__) is added in the FreeBSD patch set you added a corresponding defined(__CYGWIN__)? I don't quite get that part, so I guess that you did either the right thing or did forget about the last case ;-) Hmmm, probably missed that one. I'll try to take a look at this, as well as the FAT patch, tomorrow. About possibly implementing an NT backend (using http://tinyurl.com/c27fn probably), well, I guess it is feasible but with 1300+ lines of code for all but the simplest backend (dnotify) we're a bit scared about that, and moreover efficiency is not a really big issue in our case. Not in the short time period, that's for sure. You understand, of course, that this will be up to you to write. I would like to see these FreeBSD changes ported to 0.1.7, which should be easier than writing a new backend (?). Yaakov
[ITP] gail-1.8.8-1
Here's the next GNOME package, already in all the major distros, just needs a review: ftp://sunsite.dk/projects/cygwinports/release/GNOME/gail/gail-1.8.8-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/GNOME/gail/gail-1.8.8-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/GNOME/gail/setup.hint category: Gnome requires: cygwin atk-runtime gtk2-x11-runtime libart_lgpl2 libgnomecanvas2 sdesc: Accessibility support for GTK+ and libgnomecanvas ldesc: GAIL provides accessibility support for gtk+ and libgnomecanvas by implementing AtkObjects for widgets in gtk+ and libgnomecanvas. The GAIL library is a GTK+ module. For example, if the module is loaded in a program which calls gtk_widget_get_accessible() for a GtkEntry an instance of GailEntry is returned. This module is normally used with the atk-bridge GTK+ module from at-spi to allow an assistive technology, e.g a screenreader, to query or drive the program. Yaakov
Re: New Package: pygtk2-2.6.3-1
Yaakov S (Cygwin Ports) wrote: The following package has been added to the Cygwin net release: Sorry about that. Resent to the correct list. Yaakov
Re: [maybe-ITP] gamin
On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote: Lapo Luchini wrote: I needed this patch in order to have it working on FAT32 disks, but both on FAT and NTFS the test results seem quite consistent to me: all is good on NTFS and all-but-test-9 on FAT. I'd rather not outright #ifndef __CYGWIN__ these if there's a better solution. I don't know if there's a way to determine if the drive is FAT or NTFS, I'm sure there is -- Corinna posted a test program to cygwin@ earlier this month that prints various attributes of the drives. It was meant for shares, but I'm sure it also applies to local drives. Besides, cygcheck prints out what kind of drive it is, so you can get some code from there too. but AFAICS there is a way to determine if Windows is NT or not (and presume that NT is running on NTFS and not FAT, which should be the norm), for example: Umm, you don't want to assume that any disk is NTFS on NT... See below. http://cygnome2.sourceforge.net/install/release/nautilus/nautilus-2.4.2-cygwin.patch Although this raises an interesting question: Linux can also use FAT disks, so what happens then?? Exactly, and so can NT. Better to find out what disk we're working with. Test 9 checks if a directory mtime gets modified when you write a file in it and I guess FAT just doesn't work that way. Possibly, but I only have NTFS drives at my disposal. Floppies are usually FAT. How about using one? :-) HTH, 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
Re: [maybe-ITP] gamin
On Mon, Jan 30, 2006 at 08:29:05PM -0500, Igor Peshansky wrote: On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote: Possibly, but I only have NTFS drives at my disposal. Floppies are usually FAT. How about using one? :-) FAT but not FAT32. There can be differences. Can you format a floppy as FAT32? cgf
Re: [maybe-ITP] gamin
On Mon, 30 Jan 2006, Christopher Faylor wrote: On Mon, Jan 30, 2006 at 08:29:05PM -0500, Igor Peshansky wrote: On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote: Possibly, but I only have NTFS drives at my disposal. Floppies are usually FAT. How about using one? :-) FAT but not FAT32. There can be differences. Good point. Can you format a floppy as FAT32? According to http://support.microsoft.com/?kbid=253774, no: Floppy disks are formatted as FAT12, even if you have formatted your hard disk to FAT32. The utility, Format.com is prohibited from making a FAT32 file system on a floppy disk. It should be possible to create a small partition for testing, but it's probably much easier to do in VMware... 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
Re: [maybe-ITP] gamin
Christopher Faylor wrote: FAT but not FAT32. There can be differences. AFAIK, we're only concerned with the permissions issue, which IIRC is the same for both. Can you format a floppy as FAT32? Not on Windows. A FAT32 volume must have a minimum of 65,527 clusters, with a minimum cluster size of 512 bytes, which adds up to be a lot more than a floppy. http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_lxty.asp http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_tdrn.asp Yaakov
Re: [maybe-ITP] gamin
Igor Peshansky wrote: I'm sure there is -- Corinna posted a test program to cygwin@ earlier this month that prints various attributes of the drives. It was meant for shares, but I'm sure it also applies to local drives. Besides, cygcheck prints out what kind of drive it is, so you can get some code from there too. For the archives (and my own reference), that's: http://www.cygwin.com/ml/cygwin/2006-01/msg00818.html Umm, you don't want to assume that any disk is NTFS on NT... See below. I agree that it wasn't a perfect assumption. Exactly, and so can NT. Better to find out what disk we're working with. Which again would imply that working with FAT drives is broken on gamin in general, not just on Windows. Floppies are usually FAT. How about using one? :-) What an idea. :-) I'll see what I can do tomorrow. Yaakov
Security advisory: xpdf (CVE-2005-3624/25/26/27)
Xpdf is vulnerable to integer overflows that may be exploited to execute arbitrary code. Solution: apply this patch to xpdf-3.01: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-text/xpdf/files/xpdf-3.01-sec-rollup.patch More information: http://www.gentoo.org/security/en/glsa/glsa-200601-17.xml Yaakov
Re: [ITP] gail-1.8.8-1
When trying to build from source I get: Making all in libgail-util make[4]: Entering directory `/usr/src/gail-1.8.8/.build/docs/reference/libgail-util' gtk-doc: Scanning header files if grep -l '^..*$' /usr/src/gail-1.8.8/docs/reference/libgail-util/gail-libgail-util.types /dev/null 21 ; then \ CC=/bin/sh ../../../libtool --mode=compile gcc -I/usr/src/gail-1.8.8 -I../../.. -DXTHREADS -DXUSE_MTSAFE_API -I/usr/include/atk-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0-O2 -pipe -Wall LD=/bin/sh ../../../libtool --mode=link gcc -O2 -pipe -Wall CFLAGS= LDFLAGS=../../../gail/libgail-util/libgailutil.la gtkdoc-scangobj --module=gail-libgail-util --output-dir=/usr/src/gail-1.8.8/docs/reference/libgail-util ; \ else \ cd /usr/src/gail-1.8.8/docs/reference/libgail-util ; \ for i in gail-libgail-util.args gail-libgail-util.hierarchy gail-libgail-util.interfaces gail-libgail-util.prerequisites gail-libgail-util.signals ; do \ test -f $i || touch $i ; \ done \ fi cd /usr/src/gail-1.8.8/docs/reference/libgail-util \ gtkdoc-scan --module=gail-libgail-util --source-dir=../../../libgail-util --ignore-headers= touch scan-build.stamp gtk-doc: Rebuilding template files cd /usr/src/gail-1.8.8/docs/reference/libgail-util gtkdoc-mktmpl --module=gail-libgail-util touch tmpl-build.stamp gtk-doc: Building XML cd /usr/src/gail-1.8.8/docs/reference/libgail-util \ gtkdoc-mkdb --module=gail-libgail-util --source-dir=../../../libgail-util --output-format=xml --expand-content-files= --main-sgml-file=gail-libgail-util-docs.sgml Unknown option: expand-content-files Can't move ./xml/gailtextutil.xml.new to ./xml/gailtextutil.xml: Permission denied at /usr/share/gtk-doc/data/gtkdoc-common.pl line 71, INPUT line 21. make[4]: *** [sgml-build.stamp] Error 13 make[4]: Leaving directory `/usr/src/gail-1.8.8/.build/docs/reference/libgail-util' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/gail-1.8.8/.build/docs/reference' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/gail-1.8.8/.build/docs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gail-1.8.8/.build' make: *** [all] Error 2 Ciao Volker
No Terminal Windows appear
After I install cygwin and type starx in bash, I do not get the terminal windows. See log below. Thanks in advance. I am running Windows XP professional. Juanjo Juanjo [EMAIL PROTECTED] ~ $ xstart bash: xstart: command not found Juanjo [EMAIL PROTECTED] ~ $ startx Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.8.2.0-4 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: X :0 -multiwindow -clipboard _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information (==) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TT F/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/ X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winSetEngine - Multi Window or Rootless = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 768 depth: 32 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 null screen fn ReparentWindow null screen fn RestackWindow InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shar ed memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (--) Using preset keyboard for English (USA) (409), type 4 Rules = xorg Model = pc105 Layout = us Variant = (null) Options = (null ) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No Terminal Windows appear
On Mon, 30 Jan 2006, Juanjo Carmona-Serradilla wrote: After I install cygwin and type starx in bash, I do not get the terminal windows. See log below. Thanks in advance. I am running Windows XP professional. Juanjo Juanjo [EMAIL PROTECTED] ~ $ startx [snip] startx will only open a terminal if one is present in ~/.Xsession. Why not use startxwin.sh? 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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-30 10:30:58 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (d_cachepos): Rename from d_pos to distinct clearly from __d_position. Change throughout. (fhandler_disk_file::rewinddir): Reset readdir cache on NT. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3363r2=1.3364 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.161r2=1.162
src/winsup/cygwin ChangeLog fhandler_disk_file.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-30 13:44:16 Modified files: winsup/cygwin : ChangeLog fhandler_disk_file.cc Log message: * fhandler_disk_file.cc (fhandler_disk_file::rewinddir): Simplify conditional. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3364r2=1.3365 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.162r2=1.163
Re: /proc/pid/exe points to void
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/pid/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/pid/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/
Re: pgsql on cygwin problem
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: bootstrap error
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 http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html -- 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: readdir after rewinddir not working in 20060128 snapshot
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
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 http://lists.gnu.org/archive/html/emacs-devel/2006-01/msg00931.html 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: ATT: gcc maintainer (was Re: cpp does not honor the -undef option.)
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
meTM.
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: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters
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: readline-5.1 CGDB
-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: bootstrap error
-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: Cygwin Bash window disappear?!
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: readline-5.1 CGDB
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 stdio.h
#include curses.h
#include readline/readline.h
#include termios.h
#include unistd.h
#include stdlib.h
/*
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;
RE: Cygwin Bash window disappear?!
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: Cygwin Bash window disappear?!
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?!
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/
MSYS path behavior in Cygwin
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: MSYS path behavior in Cygwin
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/
Re: MSYS path behavior in Cygwin
Dave Korn dave.korn at 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: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters
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: rpcgen question
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: snip 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
Ugh, top-posting... Reformatted. On Mon, 30 Jan 2006, Svend Sorensen wrote: On 1/30/06, Igor Peshansky [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR. 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 ftp://ftp.cs.mun.ca/pub/pdksh/pdksh-5.2.14.tar.gz? 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: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process
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: readline-5.1 CGDB
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/
sshd password authentication results in identity of NT AUTHORITY\SYSTEM
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/
unmount drive in cygwin - is it possible
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/
RE: unmount drive in cygwin - is it possible
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/
Installation Errors
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: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters
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: http://cygwin.com/acronyms/#PCYMTNQREAIYR. 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 ftp://ftp.cs.mun.ca/pub/pdksh/pdksh-5.2.14.tar.gz? 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/
Re: 1.5.19: pdksh 5.2.14-3 tab-complete and shell metacharacters
On Mon, 30 Jan 2006, Svend Sorensen wrote: On 1/30/06, Igor Peshansky [EMAIL PROTECTED] wrote: Again, http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. Ugh, top-posting... Reformatted. On Mon, 30 Jan 2006, Svend Sorensen wrote: On 1/30/06, Igor Peshansky [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR. 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 ftp://ftp.cs.mun.ca/pub/pdksh/pdksh-5.2.14.tar.gz? 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-4 exec family of functions find wrong file to execute
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: unmount drive in cygwin - is it possible
Mark Bevan mark_bevan_email at 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/
where is SCP
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: where is SCP
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/
Re: where is SCP
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: csh script hangs only on cygwin
* 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: MSYS path behavior in Cygwin
See this thread for more info: http://sourceforge.net/forum/forum.php?thread_id=1430505forum_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: where is SCP
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 http://cygwin.com/packages/ (also mentioned in the FAQ entry http://cygwin.com/faq/faq.setup.html#faq.setup.what-packages). 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 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: MSYS path behavior in Cygwin
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:
http://cygwin.com/cgi-bin/cvsweb.cgi/wrappers/java/?cvsroot=cygwin-apps.
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/
[ANNOUNCEMENT] New Package: pygtk2-2.6.3-1
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: where is SCP
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 http://cygwin.com/packages/ (also mentioned in the FAQ entry http://cygwin.com/faq/faq.setup.html#faq.setup.what-packages). 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/
Re: where is SCP
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 http://cygwin.com/packages/ (also mentioned in the FAQ entry http://cygwin.com/faq/faq.setup.html#faq.setup.what-packages). 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: Standalone DirectX Package
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: Standalone DirectX Package
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
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
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
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: Installation Errors
-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/
[ANNOUNCEMENT] Updated [experimental]: bash-3.1-2
-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/
Running grep and other cygwin commands from cmd.exe
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/
Updated [experimental]: bash-3.1-2
-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-
