Re: [patch/rfc]: bash: fix globbing for executables without ".exe"
On 8/30/2012 7:10 AM, Christopher Faylor wrote: On Thu, Aug 30, 2012 at 02:43:34AM -0700, Gregory M. Turner wrote: Not sure if this belongs in the cygport, upstream or /dev/null. Fixes, i.e.: "ls /bin/b*sh" failing to show /bin/bash. If you're reporting an issue with a cygwin program it belongs in the cygwin mailing list. cygwin-apps is not for patches to bash or bug reports for bash. cgf My bad, will repost to cygwin as you suggest, but just for future reference: that leaves only cygport-specific stuff and setup.exe as on-topic here? I have some odds-and-ends in my tree that I really ought to be sharing, but to do so it'd obviously help if I fully groked c.c/lists.html. -gmt
Re: perl_vendor
Yaakov (Cygwin/X) writes: > cygport 0.11.0 should make it much easier to maintain this quantity of > Perl modules, since it can now generate setup.hint files with > appropriate requires: automatically. I don't think Cygwin READMEs are > necessary for these either. Yes, I've seen your announcement and anticipate it will be a great help. I won't be able to work on it during the next two or three weeks (or so it seems), unfortunately. > As for the .cygport files, they look good for the most part, but your > dependency checks could be replaced by the simpler DEPEND syntax. Hopefully yes. > Let me know if I can be of further assistance with this. Thanks, but let me get started first… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: perl_vendor
Reini Urban writes: > What's the problem? Lack of upates for these? My problem is that I need quite a bunch of additional Perl distributions, I need to package them into Cygwin packages since they will need to be installed with setup.exe and the way things are bundled in perl_vendor makes dependency tracking more difficult. I already have a solution, I simply don't use perl_vendor and re-package everything I need from it (essentially all of it, so the selection is quite sound). That's what I linked to, I wasn't proposing that everything in this bundle should go into Cygwin. I won't bring this up again, I think everybody has said what they wanted to say. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [ITA] w32api-3.0b_svn5368-1
On Thu, Aug 30, 2012 at 4:56 AM, Jon TURNEY wrote: WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. >>> >>> >>> No problems with ddraw.h status? > > > There's probably some decruftification which can take place later in the > xserver, of stuff which presumably predates the existence of libdxguid.a in > mingw.org's w32api > > >> Jon's xserver patch takes care of that. The only change needed in >> w32api is for _PROTECT_BOOL_MACRO in windef.h: >> >> http://cygwin.com/ml/cygwin-apps/2012-08/msg00074.html > > > I'd rather not make windef.h any convoluted, and there's probably a more > elegant way to solve this problem. > > Given that we are going to have to change x11proto's Xwindows.h anyhow, it > might be possible to do it all there, but I haven't found the way yet... So hold on the patch to mingw-w64?
Re: perl_vendor
On Sat, Aug 4, 2012 at 10:18 AM, Achim Gratz wrote: > [Summary of previous discussion] I think that each perl module > distribution should have its own Cygwin package. Since our perl > installation at work needs quite a few more distributions, I created the > missing cygport files while the switch to 5.14 was pending. To ease > installation I also made a bundle package that does nothing but list all > those individual packages as dependencies so they can be installed > together by selecting a single package. > > > I am aware that splitting perl_vendor up into individual packages would > require great effort and I fully understand that you don't want to > shoulder that alone. As a transitory measure with much less impact, the > distributions inside perl_vendor could each get empty packages that > depend on perl_vendor (sort of the reverse of what I've been doing with > my umbrella package), which would at least make it more explicit what is > available even though the install (and update) still happens en bloc. > If you like this idea better, I should be able to provide corresponding > Cygwin packages (or just the definitions, whatever your preference) in > about two weeks. You can have all packages in vendor, but I doubt that they are all needed and that it is useful. The reasoning for having them together was to support self-installation via CPAN and reporting tests results automatically in case of errors, not to bother the list with such minor issues. Splitting them up will break this idea. People will complain how to install perl packages and upstream maintainers will complain about missing cygwin feedback. There are only some package with are not needed for CPAN and CPAN::Reporter, which others found useful to have as default. DBI should be added also IMHO, esp. since using the default DBI from CPAN is still a security risk for three quarters of a year now. What's the problem? Lack of upates for these? Updates via cpan are easier than updates via setup.exe > Moving a distribution out from perl_vendor into its own package later on > (LWP springs to mind, which is about the only distribution that I update > with some regularity) would require a coordinated release of two > packages, but that seems manageable. > > As for taking over maintainership of all (or the majority) of these perl > distribution packages: I am open to the idea in general, but would want > to have a co-maintainer in the beginning and I would need access to a > build host at least for the XS modules. The cygport definitions I have > in hand certainly need some more work before they would be good for > general release, but so far I've got zero feedback on them. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [ITA] w32api-3.0b_svn5368-1
On 30/08/12 00:16, Yaakov (Cygwin/X) wrote: On Thu, 2012-08-30 at 06:11 +0800, JonY wrote: On 8/29/2012 14:14, Yaakov (Cygwin/X) wrote: On Thu, 2012-08-23 at 19:45 +0100, Jon TURNEY wrote: Yaakov, you might like to try the attached patch. With an appropriate change to prevent BOOL redefinition errors, this builds X server for me. WFM. Once your _PROTECT_BOOL_MACRO patch for windef.h is accepted, I can roll an xproto update and this will be GTG. No problems with ddraw.h status? There's probably some decruftification which can take place later in the xserver, of stuff which presumably predates the existence of libdxguid.a in mingw.org's w32api Jon's xserver patch takes care of that. The only change needed in w32api is for _PROTECT_BOOL_MACRO in windef.h: http://cygwin.com/ml/cygwin-apps/2012-08/msg00074.html I'd rather not make windef.h any convoluted, and there's probably a more elegant way to solve this problem. Given that we are going to have to change x11proto's Xwindows.h anyhow, it might be possible to do it all there, but I haven't found the way yet...
Re: [RFC] setup: allow building with i686-w64-mingw32
On Thu, Aug 30, 2012 at 04:50:24AM -0500, Yaakov (Cygwin/X) wrote: >On Wed, 2012-08-29 at 20:57 -0500, Yaakov (Cygwin/X) wrote: >> On Fri, 2012-06-01 at 02:45 -0500, Yaakov (Cygwin/X) wrote: >> > The attached draft patch fixes most of the issues with the build. (I >> > just added the necessary mingw64-i686-* libraries to Ports.) ntdll.h >> > needs some more work though; perhaps JonY could provide some input? >> >> Revised patches for mingw-w64-headers SVN HEAD attached. > >Pending those changes, revised patch for setup attached. Tested with >i686-pc-mingw32 and i686-w64-mingw32, as well as compile-only with >x86_64-w64-mingw32 (autoload.c still needs changes for x64, as do other >things when we get to that point). Once those changes are available, feel free to check this in. cgf
Re: [patch/rfc]: bash: fix globbing for executables without ".exe"
On Thu, Aug 30, 2012 at 02:43:34AM -0700, Gregory M. Turner wrote: >Not sure if this belongs in the cygport, upstream or /dev/null. Fixes, >i.e.: "ls /bin/b*sh" failing to show /bin/bash. If you're reporting an issue with a cygwin program it belongs in the cygwin mailing list. cygwin-apps is not for patches to bash or bug reports for bash. cgf
Re: [RFC] setup: allow building with i686-w64-mingw32
On Wed, 2012-08-29 at 20:57 -0500, Yaakov (Cygwin/X) wrote:
> On Fri, 2012-06-01 at 02:45 -0500, Yaakov (Cygwin/X) wrote:
> > The attached draft patch fixes most of the issues with the build. (I
> > just added the necessary mingw64-i686-* libraries to Ports.) ntdll.h
> > needs some more work though; perhaps JonY could provide some input?
>
> Revised patches for mingw-w64-headers SVN HEAD attached.
Pending those changes, revised patch for setup attached. Tested with
i686-pc-mingw32 and i686-w64-mingw32, as well as compile-only with
x86_64-w64-mingw32 (autoload.c still needs changes for x64, as do other
things when we get to that point).
Yaakov
2012-08-30 Yaakov Selkowitz
Fix build with mingw-w64 headers and start on X86-64 compatibility.
* archive_tar.cc (archive_tar::next_file_name): Fix sscanf formats
for 64-bit size_t.
* autoload.c: Define DECLSPEC_IMPORT for mingw-w64 headers.
* bootstrap.sh: Use i686-w64-mingw32 toolchain if available.
* choose.cc (ChooserPage::OnMouseWheel): Fix return type.
* choose.h (ChooserPage::OnMouseWheel): Ditto.
* filemanip.cc (nt_wfopen): Fix argument cast for _open_osfhandle.
* filemanip.h: Include to fix missing mode_t typedef
error with mingw-w64 headers.
* gpg-packet.cc: Include "win32.h" to avoid macro redefinition
errors with mingw-w64 headers.
(ARRAYSIZE): Do not redefine.
* main.cc: Remove CINTERFACE define.
(_argv): Declare if using mingw-w64 headers.
(main_display): Use C++ syntax for COM.
(WinMain): Move up _argv definition to before it is first used.
* mklink2.cc: Remove CINTERFACE define.
(make_link_2): Use C++ syntax for COM.
* netio.cc (auth_proc): Fix return type.
* ntdll.h: Include PSDK headers with mingw-w64 instead of DDK.
* package_message.h: Include "win32.h" instead of .
* proppage.cc (PropertyPage::FirstDialogProcReflector): Fix return type.
Use SetWindowLongPtr and DWLP_* instead of SetWindowLong and DWL_*.
(PropertyPage::DialogProcReflector): Ditto.
(PropertyPage::DialogProc): Ditto.
(PropertyPage::OnMouseWheel): Ditto.
* proppage.h (PropertyPage::FirstDialogProcReflector): Fix return type.
(PropertyPage::DialogProcReflector): Ditto.
(PropertyPage::DialogProc): Ditto.
(PropertyPage::OnMouseWheel): Ditto.
* propsheet.cc (PROPSHEETHEADER_V1_SIZE): Do not redefine.
* site.cc (drop_proc): Fix return type.
* win32.h: Include
Define DECLSPEC_IMPORT for mingw-w64 headers.
* window.cc (Window::FirstWindowProcReflector): Use GWLP_* with
SetWindowLongPtr calls.
(Window::WindowProcReflector): Ditto.
Index: archive_tar.cc
===
RCS file: /cvs/cygwin-apps/setup/archive_tar.cc,v
retrieving revision 2.17
diff -u -p -r2.17 archive_tar.cc
--- archive_tar.cc 8 Mar 2012 09:20:03 - 2.17
+++ archive_tar.cc 30 Aug 2012 09:01:53 -
@@ -171,7 +171,7 @@ archive_tar::next_file_name ()
else if (state.have_longname)
state.have_longname = 0;
- sscanf (state.tar_header.size, "%o", &state.file_length);
+ sscanf (state.tar_header.size, "%Io", &state.file_length);
state.file_offset = 0;
// vp2 (_tar_vfile, "%c %9d %s\n", state.tar_header.typeflag,
@@ -190,7 +190,7 @@ archive_tar::next_file_name ()
MAX_PATH);
err++;
state.parent->read (&state.tar_header, 512);
- sscanf (state.tar_header.size, "%o", &state.file_length);
+ sscanf (state.tar_header.size, "%Io", &state.file_length);
state.file_offset = 0;
skip_file ();
return next_file_name ();
Index: autoload.c
===
RCS file: /cvs/cygwin-apps/setup/autoload.c,v
retrieving revision 2.9
diff -u -p -r2.9 autoload.c
--- autoload.c 17 Mar 2010 17:51:18 - 2.9
+++ autoload.c 30 Aug 2012 09:01:53 -
@@ -17,6 +17,7 @@ static const char *cvsid = "\n%%% $Id: a
#endif
#define WIN32_LEAN_AND_MEAN
+#define DECLSPEC_IMPORT
#include
typedef struct {
Index: bootstrap.sh
===
RCS file: /cvs/cygwin-apps/setup/bootstrap.sh,v
retrieving revision 2.6
diff -u -p -r2.6 bootstrap.sh
--- bootstrap.sh 24 Feb 2012 20:21:42 - 2.6
+++ bootstrap.sh 30 Aug 2012 09:01:53 -
@@ -50,14 +50,22 @@ fi
cd "$builddir"
build=`$srcdir/cfgaux/config.guess`
-host="i686-pc-mingw32"
-if hash $host-g++ 2> /dev/null; then
+if hash i686-w64-mingw32-g++ 2> /dev/null; then
+ host=i686-w64-mingw32
CC="$host-gcc"
CXX="$host-g++"
-else
+elif hash i686-pc-mingw32-g++ 2> /dev/null; then
+ host=i686-pc-mingw32
+ CC="$host-gcc"
+ CXX="$host-g++"
+elif hash g++-3 2> /dev/null; then
+ host=i686-pc-mingw32
CC="gcc-3 -mno-cygwin"
CXX="g++-3 -mno-cygwin"
+else
+ echo "mingw32-target g++ required for building setup"
+ exit 1
fi
echo "running configure"
Index: choose.cc
===
RCS file: /cvs/cygwin-apps/setup/choose.cc,v
retrieving revision 2.161
diff -u -p -r2.161 choose.cc
--- choose.cc 22 Dec 2011 17:5
[patch/rfc]: bash: fix globbing for executables without ".exe"
Not sure if this belongs in the cygport, upstream or /dev/null. Fixes,
i.e.: "ls /bin/b*sh" failing to show /bin/bash.
-gmt
In cygwin, we have "the .exe hack" where both foo and foo.exe are treated as
hardlinks to the same thing if foo is an executable or a symlink to an
executable.
This doesn't present a problem when globbing for something that matches
"foo.exe"
since readdir() always seems to tack the .exe on to the end. However, when
globbing for "foo", we completely fail to find the file, for the same reason.
The only thing for it is to explicitly check for this circumstance and inject
a match into our results iff the glob matches "foo" but not "foo.exe".
-gmt
diff -urN bash-4.2.orig/lib/glob/glob.c bash-4.2/lib/glob/glob.c
--- bash-4.2.orig/lib/glob/glob.c 2012-08-29 14:04:40.707465500 -0700
+++ bash-4.2/lib/glob/glob.c2012-08-29 14:51:45.275465500 -0700
@@ -675,6 +675,102 @@
bcopy (dp->d_name, nextname, D_NAMLEN (dp) + 1);
++count;
}
+#if __CYGWIN__
+ /* if file i.e. foo.exe is executable, see if "foo" matches the glob
*/
+ else if (strmatch ("*.exe", convfn, mflags) != FNM_NOMATCH)
+ {
+ /* if sanity checks pass, assume this is the cygwin .exe hack at
work. */
+ struct stat finfo;
+
+ /* ".exe" matches *.exe so lets rule that out rather than match
'\0' */
+ if (!(convfn[0] == '.' && convfn[1] == 'e' && convfn[2] == 'x' &&
+ convfn[3] == 'e' && convfn[4] == '\0'))
+ {
+ subdir = sh_makepath (dir, dp->d_name, pflags);
+ if (!subdir)
+ {
+ lose = 1;
+ break;
+ }
+ if (stat (subdir, &finfo) == 0 &&
+ ((S_ISREG (finfo.st_mode) || S_ISLNK (finfo.st_mode)) &&
+ (finfo.st_mode & (S_IXUSR|S_IXGRP|S_IXOTH
+ {
+ size_t dnamlen = D_NAMLEN (dp) - 4; /* length of ".exe" */
+ /* We can kind-of abuse nextname here -- that's where it's
+going, anyhow, if everything checks out OK */
+ nextname = (char *) malloc (dnamlen + 1);
+ if (!nextname)
+ {
+ lose = 1;
+ break;
+ }
+ bcopy (dp->d_name, nextname, dnamlen);
+ *(nextname + dnamlen) = '\0';
+ convfn = fnx_fromfs (nextname, dnamlen);
+ /* So, it's executable and ends in .exe -- does it match
the
+pattern, now that we have stripped the ".exe" off the
end? */
+ if (strmatch (pat, convfn, mflags) != FNM_NOMATCH)
+ {
+ /* Great, it matches, but does it actually exist, and
is it executable?
+Probably, yes. This protects against some future
cygwin that made
+the .exe hack optional or removed it, and against
the possibility that
+I've failed to capture the conditions that trigger
the .exe hack in
+general. A better test might be to check if they
have the same inode */
+ free(subdir);
+ subdir = sh_makepath (dir, convfn, pflags);
+ if (!subdir)
+ {
+ lose = 1;
+ break;
+ }
+ /* My tests indicate that we can stat() the
executable bit of a valid
+symlink in cygwin, expecting to get the same
result as we would get
+stat()ing the link-target. The .exe hack does
apply to such links!
+I haven't tested various wierd corner cases.
Guessing incorrectly
+whether the .exe hack is operating will result in
missed globs, or
+(if we inject but then encounter the real file)
duplicate matches */
+ if (stat (subdir, &finfo) == 0 &&
+ ((S_ISREG (finfo.st_mode) || S_ISLNK
(finfo.st_mode)) &&
+ (finfo.st_mode & (S_IXUSR|S_IXGRP|S_IXOTH
+ {
+ /* All signs point to cygwin .exe hack. Add it,
it's a "match." */
+ if (nalloca < ALLOCA_MAX)
+ {
+ nextlink = (struct globval *) alloca (sizeof
(struct globval));
+ nalloca += sizeof (struct globval);
+ }
+ else
+ {
+
