Re: configure fails on checking ino_t
On 6/9/2017 7:22 PM, Lloyd Wood wrote: Hi Ken, thanks for this - both 32-bit and 64-bit Geomview from your repository work as expected. I was able to run SaVi (http://savi.sf.net/) under both, with OpenGL and piping between Geomview and SaVi working so that SaVi could control Geomview. Hi Lloyd, Thanks for testing. However, Geomview's supplied modules aren't listed in the right panel of its main window, suggesting it hasn't been configured and built with xforms and with Tcl/Tk, which its modules need. I have some notes with hints on this at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/running-under-Windows/ It looks like this has changed. There's no longer a --with-xforms configure option, and the modules requiring xforms or Tcl/Tk are now packaged separately. (See the top-level README.) I'll think about how to best package these modules. On a related note, as you're associated with Cornell Math you know of DsTool. Patrick Worfolk worked on the v3 Tk version of that before he did SaVi, which I maintain, and it can also work with Geomview. DsTool can be made to work on 32-bit Cygwin with Tcl/Tk 8.5 (not 64-bit or 8.6 - seems to be reaching end of life as is) and could, with a bit of updating, be made current as another optional Geomview module that can also run standalone without Geomview, just like SaVi. I have some notes on DsTool at http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/DsTool/ and there's some recent discussion of DsTool on the geomview-users mailing list. Thanks, I'll take a look. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Babel trouble with latest cygwin package
On 6/9/2017 5:58 PM, Harvey Stein wrote:
I'm using cygwin on Windows 7, setup.exe version 2.879 (64 bit).
I updated my packages yesterday, and now Babel in LaTeX is having
trouble. The line:
\usepackage[USenglish]{babel}
is eliciting the following error message:
! Package babel Error: Unknown option `USenglish'. Either you misspelled it
(babel)or the language definition file USenglish.ldf was not fo
und.
See the babel package documentation for explanation.
Type H for immediate help.
...
l.393 \ProcessOptions*
?
This is the correct parameter for the babel package and works on other
platforms and worked before the package update >
When I change the line to:
\usepackage[usenglish]{babel}
the error goes away.
Is there an issue with how latex was packaged?
No, this is a known bug in the upstream babel-english package:
http://tug.org/pipermail/tex-live/2017-June/040243.html
It looks like a fix was just committed a few days ago. I'll update
texlive-collection-latex within the next few days.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure fails on checking ino_t
Hi Ken, thanks for this - both 32-bit and 64-bit Geomview from your repository work as expected. I was able to run SaVi (http://savi.sf.net/) under both, with OpenGL and piping between Geomview and SaVi working so that SaVi could control Geomview. (64-bit working with SaVi was a pleasant surprise - I had not been able to get piping between Geomview and remote control apps working previously in 64-bit, when compiling Geomview myself. And 64-bit OpenGL is good to finally see working, too.) However, Geomview's supplied modules aren't listed in the right panel of its main window, suggesting it hasn't been configured and built with xforms and with Tcl/Tk, which its modules need. I have some notes with hints on this at: http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/running-under-Windows/ Add in the Geomview modules in a -2, and I think both 32- and 64-bit Geomview will be more than good to include in Cygwin distributions, which would be worthwhile since building Geomview can be very tricky.(*) On a related note, as you're associated with Cornell Math you know of DsTool. Patrick Worfolk worked on the v3 Tk version of that before he did SaVi, which I maintain, and it can also work with Geomview. DsTool can be made to work on 32-bit Cygwin with Tcl/Tk 8.5 (not 64-bit or 8.6 - seems to be reaching end of life as is) and could, with a bit of updating, be made current as another optional Geomview module that can also run standalone without Geomview, just like SaVi. I have some notes on DsTool at http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/DsTool/ and there's some recent discussion of DsTool on the geomview-users mailing list. (*) Okay, I'm now aware of the BLODA issue, which likely explains why configure tests fail in my building Geomview, suggests that anything needing autotools to build may be best off as an installable package, and also helps explain why Cygwin is slow, particularly in disk accesses, on an i5 machine, and why my typing in cygwin occasionally does things like: $ whhhi geeomview bash: whhhi: command not found regards Lloyd Wood lloyd.w...@yahoo.co.uk http://about.me/lloydwood From: Ken Brown To: cygwin@cygwin.com Cc: Lloyd Wood Sent: Saturday, 10 June 2017, 6:39 Subject: Re: configure fails on checking ino_t On 6/7/2017 2:21 AM, Lloyd Wood via cygwin wrote: > download geomview 1.9.5 from http://www.geomview.org > this used to build on cygwin 32-bit. I've just build geomview-1.9.5 on both 32-bit and 64-bit Cygwin, using the attached cygport file and patches. If it works well, I'll propose it for inclusion in the Cygwin distribution. I have no experience with geomview, so I can't really test it adequately. Would you be willing to try out my build and tell me if it seems OK? If so, you can get it from my personal Cygwin repository: http://sanibeltranquility.com/cygwin/ There are instructions at that site. Note: I have other packages there that you probably don't want to install, so be careful to just choose geomview (and let setup install its dependencies). Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On Fri, Jun 9, 2017 at 11:28 PM, Soegtrop, Michael wrote: > Dear Hans-Bernhard, > >> You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a >> _native_ toolchain. That begs the question: why are you doing a cross build >> in >> the first place? > > I simply couldn't find another way to build 50 configure / make style > libraries and tools on Windows. If there is a method I haven't heard of, > please let me know. MSYS and MSYS2 couldn't build a single of these libraries > or tools without huge patches while doing the same on cygwin used to work out > of the box. Sorry to go a little off-topic, can you give me a list of some of these libraries and tools that can be built for a mingw-w64 host but which don't build on MSYS2 without huge patches? The stuff you are describing is the raison d'être for MSYS2 (and MSYS but I don't care about MSYS). Feel free to take this off-list. > >> So you shouldn't even be getting to any place where the output of a cross- >> target (i.e. MinGW) executable is run on the build host, and its output piped >> into a build platform (i.e. Cygwin) tool. > > I think it is quite common to build MinGW tools on cygwin and then run these > MinGW tools from cygwin, e.g. for regression testing and to process their > output in cygwin e.g. to get a test verdict. > >> That means what you're trying to argue here is that an evident short-coming >> of >> some build setups should be fixed by breaking Cygwin pipes' mode of operation >> for everyone. Sorry, but I don't see that happening. > > I think that arguing that one should not run MinGW programs from cygwin > because they are entirely different operating systems and that a build system > which does this has inherent short-comings is somehow neglecting reality. Why > shouldn’t one do this is the only problem are CRs? > > I also didn't ask to mess up Cygwin's pipe system. All I ask for is that > tools which are documented as text processing tools like sed have an > environment option to be MinGW friendly. I think people who are using sed for > binary files should use the -b option - if only to document that they are > doing this intentionally. > >> > I don't see another way than having sed strip away the CRs. It doesn't >> > make sense to build programs intended to be run under plain Windows >> > such that they do not produce CRs. >> >> I believe it makes much more sense than you think. Hardly any Windows tool >> worth using actually _needs_ those CRs in the first place. > > That is true - just, as I said many times, all these tools are out of my > control and I do not want to tell people to open streams used for text output > with "wb" just to get around pure Windows artefacts. Many people on this list > said that the maintainers of such SW have every right to reject such change > requests and I agree. Please think about what you are asking me here to do: > filing 200 fairly useless change requests against 50 Linux centric tool and > libraries. Sorry, I am not going to do this. I rather beg here to be MinGW > friendly. > > Best regards, > > Michael > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
I just had to debug & fix a problem from the sed behavior change that has little to do with MinGW. I'm running a native version of Emacs and have makefiles, lots of scripts, and various commands in my makefiles for extracting dependencies. The commands use sed, gawk, ..., and started creating bad dependency files because of carriage returns showing up in the last field when filtering with sed & gawk. It took a while to track down, especially because the command was working properly when run directly in a cygwin terminal running bash, but gave different behavior when make ran the command from inside of Emacs. I could imagine this causing all sorts of trouble for people in general. On Fri, Jun 9, 2017 at 6:28 PM, Soegtrop, Michael wrote: > Dear Hans-Bernhard, > >> You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a >> _native_ toolchain. That begs the question: why are you doing a cross build >> in >> the first place? > > I simply couldn't find another way to build 50 configure / make style > libraries and tools on Windows. If there is a method I haven't heard of, > please let me know. MSYS and MSYS2 couldn't build a single of these libraries > or tools without huge patches while doing the same on cygwin used to work out > of the box. > >> So you shouldn't even be getting to any place where the output of a cross- >> target (i.e. MinGW) executable is run on the build host, and its output piped >> into a build platform (i.e. Cygwin) tool. > > I think it is quite common to build MinGW tools on cygwin and then run these > MinGW tools from cygwin, e.g. for regression testing and to process their > output in cygwin e.g. to get a test verdict. > >> That means what you're trying to argue here is that an evident short-coming >> of >> some build setups should be fixed by breaking Cygwin pipes' mode of operation >> for everyone. Sorry, but I don't see that happening. > > I think that arguing that one should not run MinGW programs from cygwin > because they are entirely different operating systems and that a build system > which does this has inherent short-comings is somehow neglecting reality. Why > shouldn’t one do this is the only problem are CRs? > > I also didn't ask to mess up Cygwin's pipe system. All I ask for is that > tools which are documented as text processing tools like sed have an > environment option to be MinGW friendly. I think people who are using sed for > binary files should use the -b option - if only to document that they are > doing this intentionally. > >> > I don't see another way than having sed strip away the CRs. It doesn't >> > make sense to build programs intended to be run under plain Windows >> > such that they do not produce CRs. >> >> I believe it makes much more sense than you think. Hardly any Windows tool >> worth using actually _needs_ those CRs in the first place. > > That is true - just, as I said many times, all these tools are out of my > control and I do not want to tell people to open streams used for text output > with "wb" just to get around pure Windows artefacts. Many people on this list > said that the maintainers of such SW have every right to reject such change > requests and I agree. Please think about what you are asking me here to do: > filing 200 fairly useless change requests against 50 Linux centric tool and > libraries. Sorry, I am not going to do this. I rather beg here to be MinGW > friendly. > > Best regards, > > Michael > > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 -- Harvey J. Stein hjst...@gmail.com http://www.linkedin.com/in/harveyjstein Selected papers and presentations available at: http://ssrn.com/author=732372 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear Hans-Bernhard, > You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a > _native_ toolchain. That begs the question: why are you doing a cross build > in > the first place? I simply couldn't find another way to build 50 configure / make style libraries and tools on Windows. If there is a method I haven't heard of, please let me know. MSYS and MSYS2 couldn't build a single of these libraries or tools without huge patches while doing the same on cygwin used to work out of the box. > So you shouldn't even be getting to any place where the output of a cross- > target (i.e. MinGW) executable is run on the build host, and its output piped > into a build platform (i.e. Cygwin) tool. I think it is quite common to build MinGW tools on cygwin and then run these MinGW tools from cygwin, e.g. for regression testing and to process their output in cygwin e.g. to get a test verdict. > That means what you're trying to argue here is that an evident short-coming of > some build setups should be fixed by breaking Cygwin pipes' mode of operation > for everyone. Sorry, but I don't see that happening. I think that arguing that one should not run MinGW programs from cygwin because they are entirely different operating systems and that a build system which does this has inherent short-comings is somehow neglecting reality. Why shouldn’t one do this is the only problem are CRs? I also didn't ask to mess up Cygwin's pipe system. All I ask for is that tools which are documented as text processing tools like sed have an environment option to be MinGW friendly. I think people who are using sed for binary files should use the -b option - if only to document that they are doing this intentionally. > > I don't see another way than having sed strip away the CRs. It doesn't > > make sense to build programs intended to be run under plain Windows > > such that they do not produce CRs. > > I believe it makes much more sense than you think. Hardly any Windows tool > worth using actually _needs_ those CRs in the first place. That is true - just, as I said many times, all these tools are out of my control and I do not want to tell people to open streams used for text output with "wb" just to get around pure Windows artefacts. Many people on this list said that the maintainers of such SW have every right to reject such change requests and I agree. Please think about what you are asking me here to do: filing 200 fairly useless change requests against 50 Linux centric tool and libraries. Sorry, I am not going to do this. I rather beg here to be MinGW friendly. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Babel trouble with latest cygwin package
I'm using cygwin on Windows 7, setup.exe version 2.879 (64 bit).
I updated my packages yesterday, and now Babel in LaTeX is having
trouble. The line:
\usepackage[USenglish]{babel}
is eliciting the following error message:
! Package babel Error: Unknown option `USenglish'. Either you misspelled it
(babel)or the language definition file USenglish.ldf was not fo
und.
See the babel package documentation for explanation.
Type H for immediate help.
...
l.393 \ProcessOptions*
?
This is the correct parameter for the babel package and works on other
platforms and worked before the package update.
When I change the line to:
\usepackage[usenglish]{babel}
the error goes away.
Is there an issue with how latex was packaged?
Thanks.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: configure fails on checking ino_t
On 6/7/2017 2:21 AM, Lloyd Wood via cygwin wrote:
download geomview 1.9.5 from http://www.geomview.org
this used to build on cygwin 32-bit.
I've just build geomview-1.9.5 on both 32-bit and 64-bit Cygwin, using
the attached cygport file and patches.
If it works well, I'll propose it for inclusion in the Cygwin
distribution. I have no experience with geomview, so I can't really
test it adequately. Would you be willing to try out my build and tell
me if it seems OK?
If so, you can get it from my personal Cygwin repository:
http://sanibeltranquility.com/cygwin/
There are instructions at that site. Note: I have other packages there
that you probably don't want to install, so be careful to just choose
geomview (and let setup install its dependencies).
Ken
NAME="geomview"
VERSION=1.9.5
RELEASE=1
SRC_URI="https://sourceforge.net/projects/geomview/files/geomview/${PV}/${P}.tar.xz";
PATCH_URI="no_undefined.patch"
PATCH_URI+=" weak_symbols.patch"
HOMEPAGE="http://www.geomview.org/";
SUMMARY="An interactive 3D viewing program"
DESCRIPTION="Geomview lets you view and manipulate three-dimensional objects:
you
use the mouse to rotate, translate, zoom in and out, and so on.
Geomview can be used as a standalone viewer for static objects or as a
display engine for other programs which produce dynamically changing
geometry. Geomview can display objects described in a variety of file
formats. Geomview comes with a wide selection of example objects, and
you can create your own objects too."
PKG_NAMES="${PN}
lib${PN}_${PV}
lib${PN}-devel
"
geomview_CATEGORY="Math"
libgeomview_1_9_5_CATEGORY="Math Libs"
libgeomview_devel_CATEGORY="Math Devel"
geomview_CONTENTS="
usr/bin/*.exe
usr/bin/geomview
usr/bin/hvectext
usr/bin/remotegv
usr/libexec
usr/share
"
libgeomview_1_9_5_CONTENTS="usr/bin/cyg*-1-9-5.dll"
libgeomview_devel_CONTENTS="
usr/include
usr/lib
"
CYGCONF_ARGS="--with-htmlbrowser=cygstart"
DEPEND="libXm-devel libGL-devel libGLU-devel"
--- origsrc/geomview-1.9.5/src/lib/Makefile.am 2014-03-12 12:51:13.0
-0400
+++ src/geomview-1.9.5/src/lib/Makefile.am 2017-06-08 17:07:53.078591900
-0400
@@ -11,4 +11,4 @@ libgeomview_la_SOURCES =
libgeomview_la_LIBADD = \
$(OOGLLIBS) $(OPENGLLIBS) $(SOCKETLIBS) $(XLIBS) $(ZLIB_LIB)
libgeomview_la_DEPENDENCIES = $(OOGLLIBS) Makefile.am
-libgeomview_la_LDFLAGS = -release @PACKAGE_VERSION@
+libgeomview_la_LDFLAGS = -no-undefined -release @PACKAGE_VERSION@
--- origsrc/geomview-1.9.5/src/lib/mg/opengl/mgopenglshade.c2014-03-12
12:51:13.0 -0400
+++ src/geomview-1.9.5/src/lib/mg/opengl/mgopenglshade.c2017-06-09
10:25:41.647550600 -0400
@@ -413,10 +413,15 @@ mgopengl_lightmodeldef(int lightmodel, L
* supports it;
* - or, if we're on a system that claims to support it at compile time,
* we'll just hope that that system also supports it at run time.
+ * But Cygwin does not support weak symbols, and the use of "#pragma
+ * weak" causes "undefined symbol" errors when linking on x86_64
+ * Cygwin.
*/
+#ifndef __CYGWIN__
# pragma weak glBindTextureEXT
# pragma weak glDeleteTexturesEXT
+#endif
# ifndef GL_EXT_texture_object
/* If doesn't know about glBindTextureEXT etc., declare here. */
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] texlive 20170520-2
The following packages have been uploaded to the Cygwin distribution: * texlive-20170520-2 * libkpathsea6-20170520-2 * libkpathsea-devel-20170520-2 * libptexenc1-20170520-2 * libptexenc-devel-20170520-2 * libsynctex1-20170520-2 * libsynctex-devel-20170520-2 * libtexlua52_5-20170520-2 * libtexlua52-devel-20170520-2 * libtexluajit2-20170520-2 * libtexluajit-devel-20170520-2 TeX Live provides a comprehensive, cross-platform TeX system. It includes all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world. This release is a rebuild of the TeX Live 2017 binaries and supporting libraries, patched to fix an upstream luatex bug. See http://tug.org/pipermail/tlbuild/2017q2/003843.html for details. Ken Brown Cygwin's TeX Live maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On Fri, Jun 9, 2017 at 2:42 PM, Hans-Bernhard Bröker wrote: >> I don't see another way than having sed strip away the CRs. It >> doesn't make sense to build programs intended to be run under plain >> Windows such that they do not produce CRs. > > > I believe it makes much more sense than you think. Hardly any Windows tool > worth using actually _needs_ those CRs in the first place. I agree heartily with this; the only Windows tool I use that is actually dependent on CR is notepad, and usually that is only for a lazy verification that CR is/isn't present Everything I've written for dealing with Windows CR infested outputs in *nix environments I strip all CRs as my first step, and do not put CRs in my output; so far no complaints from end users about the missing CRs. -- Erik -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Am 09.06.2017 um 18:56 schrieb Soegtrop, Michael: Maybe my situation gets clear when I describe what my use case is: I maintain the scripts which build the Windows installers for Coq - a proof assistant with a GTK based UI. This starts building a MinGW OCaml compiler from sources. You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a _native_ toolchain. That begs the question: why are you doing a cross build in the first place? Cross building generally means that _no_ programs built for the target host may ever be run by the build scripts, because they simply won't work. Any attempt to do so is either a severe bug in the existing build setup, or the consequence of trying to coerce a build script that just cannot handle cross-building into doing it anyway. So you shouldn't even be getting to any place where the output of a cross-target (i.e. MinGW) executable is run on the build host, and its output piped into a build platform (i.e. Cygwin) tool. That means what you're trying to argue here is that an evident short-coming of some build setups should be fixed by breaking Cygwin pipes' mode of operation for everyone. Sorry, but I don't see that happening. Cross building on Linux would be much more complicated, because on Linux I would no matter what need 3 OCaml variants but also 2 Coq variants, because I need to compile the Coq libraries, so I need to run Coq on the build host as well. With cygwin I can call the MinGW variants. Indeed. That is a lucky _exception_ to what you can do in a cross build. But you have to pay a price for this unprecedented luxury. The price is that you have to massage the output of those MinGW programs to follow Cygwin rules, or change the way those MinGW programs are built to make them follow the rules by themselves. I don't see another way than having sed strip away the CRs. It doesn't make sense to build programs intended to be run under plain Windows such that they do not produce CRs. I believe it makes much more sense than you think. Hardly any Windows tool worth using actually _needs_ those CRs in the first place. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear Eric, > Building mingw apps may be one use of cygwin, but it is not the "intended use > case". I said "an" intended use case, not "the". I also use cygwin for a lot of other things. > If you are writing a Linux app that processes data produced on a windows > machine, then YOU must strip CR from that data (Linux sed will NOT strip it). > So now cygwin sed does the same thing. Maybe my situation gets clear when I describe what my use case is: I maintain the scripts which build the Windows installers for Coq - a proof assistant with a GTK based UI. This starts building a MinGW OCaml compiler from sources. I could also build a host=cygwin target=MinGW OCaml compiler, to get around the issue that messages it produces contain CRs, but OCaml doesn't support host!=target very well, and many of the tools it produces I also have to run under cygwin. So I would need 3 OCaml compilers, one build=cygwin, host=cygwin, target=cygwin to build the tools I run under cygwin during the build, then one build=cygwin, host=cygwin, target=MinGW to build the tools I finally need for plain Windows. But since Coq also needs OCaml at run time I also would have to build a build=cygwin, host=MinGW, target=MinGW variant. Many of the tools and libs I need have similar issues. I admit I am lazy and build only one OCaml compiler, the build=cygwin, host=MinGW, target=MinGW variant, because I will need this eventually anyway. The only issue this results in is that its text messages (like version or lib path info) contain carriage returns. All the OCaml and Coq build scripts (and the build scripts for the libraries and tools I need) themselves are not maintained by me. I just maintain the wrapper which sets up a fresh cygwin, gets all the sources, builds the whole stuff and finally produces a Windows installer for others to use. I call many scripts and tools which are originally designed to run on Linux and are maintained by Linux centric people and I do not want to bother them with such issues. Cross building on Linux would be much more complicated, because on Linux I would no matter what need 3 OCaml variants but also 2 Coq variants, because I need to compile the Coq libraries, so I need to run Coq on the build host as well. With cygwin I can call the MinGW variants. All this did work remarkably well on cygwin, because cygwin had support to call MinGW programs and to process their text oriented output. I don't see another way than having sed strip away the CRs. It doesn't make sense to build programs intended to be run under plain Windows such that they do not produce CRs. It doesn't make sense to hack around in build scripts and source code of Linux centric tools just to get this Windows build done. The true way would be to support host!=target in OCaml and to make 2..3 host/target build variants of everything. But it would take ages, waste a lot of energy (think of the CI test severs), slow down development, ... and all this just to get rid of maybe 200 carriage return characters in strings communicated in a build process. For me, cygwin is a pragmatic tool to get the job done. And it does, perfectly and better than I expected when I started this, except that current cygwin's text tools can't process text produced by MinGW tools out of the box any more. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear Dan, > One could try making a wrapper shell script where sed usually lives that adds > those options and calls the real sed... I tried to do exactly this, but I tried to pipe a dos2unix command in between. It got a bit complicated because I had to parse the sed command line arguments. The solution of adding an extra command with -e is much more elegant. And you are right, replacing sed with a shell script is better than using an alias. But the -e method won't work for grep and for awk not in all cases. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash not work with new_console (Win10 16199Insider)
On Thu, Jun 8, 2017 at 7:39 PM, yyjdelete wrote: > Tested with: > cygwin: 2.8.0-1 > bash: 4.4.12-3 > win: 10 16199(Insider) > > When you type `1234567890(Enter)(Enter)(Enter)`, the bash only get `1470`, > and nothing is shown before the third Enter is press. > > It work well after switch to legacy console. > > [new_console](https://technet.microsoft.com/library/mt427362.aspx) > > Also found here: https://github.com/Alexpux/Cygwin/issues/36 I reported a similar problem a few weeks back. It works on the *released* version of Windows 10 (Creators Update), but broke in one of the Insider builds. I was hoping to test with Insider build #16215, but it won't install on my desktop. A lot of people are apparently having this problem. I did file a Feedback request with Microsoft about the problem, never heard anything back. -- Jim Reisert AD1C, , http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On 06/09/2017 10:31 AM, Andrey Repin wrote: > Greetings, Soegtrop, Michael! > >>> alias sed='sed -b -e '\''s/\r$//'\''' > >> thanks, an interesting idea! Putting this into something like .bashrc might >> have a similar effect as having a special sed build with CR stripping built >> in. > > Except it may not work in makefiles, since make calls sed directly. Then make it a script that you put first on your $PATH. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On 06/09/2017 10:01 AM, Soegtrop, Michael wrote: > Dear cyg Simple, > >> but it would be most beneficial if you caused the stdio of your >> Windows applications to be in binary format instead of text format. Then the >> CR wouldn't be an issue during the pipe process. Why does your applications >> stdio need to be in text format instead of binary format? > > it is not my application I have issues with. I am building many open source > tools and libraries which are maintained by others, and as you said, these > others have every right to deny implementing windows specific workarounds in > their tools or build scripts. Why should anybody use "wb" mode to open a file > in a Linux centric app Using "wb" is GOOD practice in programs like tar, that WANT to produce their output as binary no matter what. But you are mixing things up. "wb" is binary mode, but manipulating CRs is only done in text mode. Text mode is only possible with "wt" (a Cygwin extension that doesn't work elsewhere), or with "w" (depending on the underlying mount - on Cygwin, "w" is text on text mode mounts, and binary on pipelines and binary mode mounts) (on other platforms, "w" is always text mode, but indistinguishable from "wb" binary mode). > or mess around with the input of sed to remove CRs in a build script for such > an app? If you are writing a Linux app that processes data produced on a windows machine, then YOU must strip CR from that data (Linux sed will NOT strip it). So now cygwin sed does the same thing. > Of cause the same is true for cygwin, except that I think building MinGW apps > is an intended use case for cygwin. Building mingw apps may be one use of cygwin, but it is not the "intended use case". The intended use case of cygwin is to emulate as much as possible of a linux environment. If building for mingw on Linux requires you to explicitly strip CR when dealing with data from Windows, then so should building for mingw on Cygwin. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On Fri, Jun 9, 2017 at 8:31 AM, Andrey Repin wrote: > Greetings, Soegtrop, Michael! > >>> alias sed='sed -b -e '\''s/\r$//'\''' > >> thanks, an interesting idea! Putting this into something like .bashrc might >> have a similar effect as having a special sed build with CR stripping built >> in. > > Except it may not work in makefiles, since make calls sed directly. One could try making a wrapper shell script where sed usually lives that adds those options and calls the real sed... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Greetings, Soegtrop, Michael! >> alias sed='sed -b -e '\''s/\r$//'\''' > thanks, an interesting idea! Putting this into something like .bashrc might > have a similar effect as having a special sed build with CR stripping built > in. Except it may not work in makefiles, since make calls sed directly. -- With best regards, Andrey Repin Friday, June 9, 2017 18:31:11 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Greetings, Soegtrop, Michael! > Why should anybody use "wb" mode to open a file in a Linux centric app Because it removes ambiguity. Everybody should use binary IO unless they explicitly want text behavior. Not just because they don't care. -- With best regards, Andrey Repin Friday, June 9, 2017 18:29:10 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear Brian, > alias sed='sed -b -e '\''s/\r$//'\''' thanks, an interesting idea! Putting this into something like .bashrc might have a similar effect as having a special sed build with CR stripping built in. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear cyg Simple, > but it would be most beneficial if you caused the stdio of your > Windows applications to be in binary format instead of text format. Then the > CR wouldn't be an issue during the pipe process. Why does your applications > stdio need to be in text format instead of binary format? it is not my application I have issues with. I am building many open source tools and libraries which are maintained by others, and as you said, these others have every right to deny implementing windows specific workarounds in their tools or build scripts. Why should anybody use "wb" mode to open a file in a Linux centric app or mess around with the input of sed to remove CRs in a build script for such an app? Of cause the same is true for cygwin, except that I think building MinGW apps is an intended use case for cygwin. But then it needs to have ways to deal with MinGW programs which behave like MinGW programs should, and this means ending lines with cr-lf. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On 6/9/2017 4:06 AM, Soegtrop, Michael wrote: > Dear Blake, > >> External products were being lazy by relying on cygwin to strip CR when they >> should have stripped it themselves. But 'sed -b' does NOT strip CR (it is >> the >> exact opposite, of keeping CR unstripped). > > I think that there are more people who use sed for text processing in a MinGW > cygwin cross environment than there are people using sed for binary data - > but looking at the mailing list this might be a subjective view. The > maintainers of the Linux centric SW could insert dos2unix in all stuff piped > into sed, but this would only be required in this very specific build > configuration, and Linux SW maintainers frequently argue why they should care > about Windows at all. It can take all sorts of philosophical discussions to > get such a change in. And I cannot blame them for a "we are free SW people, > if you Windowers can make use of our SW without bothering us - go ahead, but > please don't drag us into your mud" attitude. In the end one usually gets it > done, but the effort is not negligible. > They have every right and I would most likely do the same if I were in their positions. As already explained by Erik the CR needs to be preserved during the pipe and redirect of data. Otherwise you corrupt the data being used. > I think that sed, grep and awk are in the end text processing tools, and that > they should at least have an environment option to behave like text > processing tools in a mixed cygwin MinGW environment. With sed I have several > 100 issues building a single application, with grep it was just one in my > scripts which I fixed. awk no issues so far. > They may have been derived by the need to process text but they were also derived as *nix software where the CR wasn't an issue. Dealing with the data is the end users responsibility and if the data contains a character that isn't required then the end user needs to remove it with other tools. This isn't anything new, dealing with Windows produced files in any *nix environment requires the conversion from and to Windows formats. > Btw.: I don't think that it will be easy or even possible to build detection > for MinGW generated output into the cygwin dll as you suggested in a previous > post. How should the receiving part of a pipe know what kind of DLLs the > sending part has loaded? One could have obscure heuristics to detect "text > with cr-lf line endings", but this sounds more like a night mare than a > solution. The only entity who could detect this is the shell, but then you > have more than one shell (and more philosophers). As I said, I think on > cygwin sed, grep and awk should have an environment option to be MinGW > friendly text processors (as they used to be). Other less text centric SW > should be unaffected. > No, there should be no such option. > Honestly my solution to the problem is to build sed from sources with CR > stripping. I thought about it a day and came to the conclusion that > everything else is a waste of time. > That is your choice, you could even build sed as a Windows binary instead of a Cygwin binary; but it would be most beneficial if you caused the stdio of your Windows applications to be in binary format instead of text format. Then the CR wouldn't be an issue during the pipe process. Why does your applications stdio need to be in text format instead of binary format? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
On 2017-06-08 02:50, Soegtrop, Michael wrote:
>> No, the documented behavior is that CR-LF is converted to LF only
>> for text- mounted files; but pipelines are default binary-mounted.
>> If you want to strip CR from a pipeline, then make it explicit.
>>> var=$( prog | sed .)
>> Rewrite that to var=$( prog | tr -d '\r' | sed .)
For compatibility var=$( prog | sed -b -e 's/\r$//' ...)
> I have two problems with this:
>
> 1.) I build many (~ 50) unix libs and tools MinGW cross on cygwin
> from sources and this breaks many of the configure and other scripts.
> Feeding back the fixes to the individual lib/tool maintainers will
> take quite some time and also results in lengthy discussion why they
> should care about crappy DOS artefacts at all. A compatibility option
> via environment variable would have been nice.
If your makefiles configured SED you could use:
export SED='sed -b -e '\''s/\r$$//'\'''
and that is probably the best approach: change sed to SED in makefiles,
and configure SED=sed if not set.
Alternatives:
alias sed='sed -b -e '\''s/\r$//'\'''
sed(){ /bin/sed -b -e 's/\r$//' "$@"; }
sed -i 's|\|& -b e '\''s/\r$//'\''|g' ... to patch files - double
the "$" to patch makefiles,
or build and use a Mingw(-compatible) sed that converts \r\n to \n on
input and \n to \r\n on output?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug? wcsxfrm causing memory corruption
On Tue, Jun 6, 2017 at 9:22 PM, Corinna Vinschen wrote: > On Jun 6 17:57, Corinna Vinschen wrote: >> > > On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote: >> > >> [...] >> > >> The attached test demonstrates the bug. Given an output buffer of N >> > >> wide characters, wcsxfrm will cause bytes beyond the destination size >> > >> to be reversed. I believe it might actually be a bug in the underlying >> > >> LCMapStringW workhorse (this is on Windows 10; have not tested other >> > >> versions). >> > >> >> > >> According to its docs [1], the cchDest argument (size of the >> > >> destination buffer) is treated as a *byte* count when using >> > >> LCMAP_SORTKEY. However, for the purposes of applying the >> > >> LCMAP_BYTEREV transformation it seems to be treating the output size >> > >> (in bytes) as character count. So in the example I give, where the >> > >> output sort key is 7 bytes (including the null terminator), it swaps >> > >> *14* bytes--the bytes including the sort key as well as the next 7 >> > >> adjacent bytes. This is obviously a problem if the destination buffer >> > >> is allocated out of some larger memory pool. >> > >> >> > >> This definitely has to be a bug, right? Or at least very poorly >> > >> documented on MS's part. A workaround would either be to not use >> > >> LCMAP_BYTEREV and just swap the bytes manually, or in a second call to >> > >> LCMapStringW with LCMAP_BYTEREV and the correct character count... >> > >> [...] >> Incredible piece of detective work. Yeah, this looks very much like a >> bug in LCMapStringW, embarrassingly one I didn't notice at the time of >> writing the code. I just tested this on W7 and the problem was already >> present. >> >> I don't know if this could be fixed by documentation. There's just no >> safe way to combine LCMAP_SORTKEY with LCMAP_BYTEREV it seems, unless >> you always allocate a buffer at least twice as big as actually required >> for the sort key. >> >> So, yeah, I think manual swaping after calling LCMapStringW without >> LCMAP_BYTEREV is the way to go. I'll prepare a fix. >> >> >> Thanks for tracking down and the testcase, >> Corinna > > Latest snapshot from https://cygwin.com/snapshots/ has the patch applied. > Please try. I had a look at the fix and it looks good to me; thanks! Erik -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Switching the user context -- SeAssignPrimaryTokenPrivilege required
On Fri, 9 Jun 2017 11:00:36, Corinna Vinschen wrote: [snip] > You're not supposed to do that. setuid() is a privileged call, so it's > supposed to be called by a privileged process only. Do not add these > permissions to a normal user account unless you exactly know what you're > doing security-wise. No, indeed, one is not supposed to do that (permanently assign this privilege to a regular user account). Definitely. Absolutely ... I only intended to demonstrate the essence (gist?) of the subparagraph: user context switch => CreateProcessAsUser() Without the invocation of CreateProcessAsUser() there is no context switch. Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Starting a xterm window
>> /usr/bin/xterm: Xt error: Can't open display: :0.0 >> /usr/bin/xterm: DISPLAY is not set Thanks for all suggestions. Both the following fragments seem to work flawlessly. Both incorporate a waiting time for XWin to gain traction before xterm is called: 1. Starting a xterm console from a .cmd file in a Windows Command Prompt box: include the lines bin\run bin\XWin -clipboard -nolock -multiwindow 2>nul timeout 2 > nul 2> nul bin\xterm -display :0.0 2. Starting a xterm console from a script in a bash (or mintty) shell: include the lines run XWin -clipboard -nolock -multiwindow 2>/dev/null & sleep 2 /bin/xterm -display :0.0 You can vary the pause e.g. timeout 3 or sleep 4. Maybe as brief a fuse as timeout 1 or sleep 1 will be adequate; but that would make me nervy about getting the same failure as in >> at the top of this post. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.880 release candidate - please test
Greetings, Garber, Dave (GE Oil & Gas, Non-GE)! > Looks good. I did fond one other behavior that I believe should be > changed. When you are typing in the search box, if you press the enter key, > it's the same as pressing the Next button and starts the install. My $.02 > is that Enter should be ignored when focus is in the search box. Not ignored, but set focus to the list. P.S. Please don't top-post in this list. -- With best regards, Andrey Repin Friday, June 9, 2017 12:20:49 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Switching the user context -- SeAssignPrimaryTokenPrivilege required Re: Installing sshd on W7 reveals errors in CSIH_SCRIPT -- patch file against master
On Jun 8 16:46, Houder wrote:
> Hi Corinna,
>
> Maybe you are still around ... otherwise it will be for the next round.
>
> During my exercise with sshd I was "forced" :-) to study the User Guide, as I
> am not "well informed" :-P about the security model of Windows.
>
> I am referring to this paragraph:
>
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
> (switching the user context)
>
> To get a bit more acquainted with the stuff, I decided to try your example at
> the beginning of this paragraph - i.e. the example in subparagraph "Switching
> the user context WITH password authentication".
>
> (I modified the example in order to make a bit more "exciting" -- see below)
>
> 64-@@# uname -a
> CYGWIN_NT-6.1 Seven 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> 64-@@# editrights -u Henri -l
> SeLockMemoryPrivilege < no special? privileges ...
>
> 64-@@# ./setuid
> Password:
> BEFORE uid = 1000, gid = 513
> BEFORE euid = 1000, egid = 513
> AFTER uid = 1004, gid = 513
> AFTER euid = 1004, egid = 513
> Surprise: execl() failed: : Operation not permitted
> retval = -1
> Should not be reached ...
> 64-@@#
>
> First I tried adding SeTcbPrivilege ("extremely powerful", according to what I
> read at MSDN). Logoff/Logon ...
>
> That did not help. Got the same result. So, NOT that powerful ...
>
> Secondly I tried adding SeAssignPrimaryTokenPrivilege ... Logoff/Logon ...
>
> 64-@@# ./setuid
> Password:
> BEFORE uid = 1000, gid = 513
> BEFORE euid = 1000, egid = 513
> AFTER uid = 1004, gid = 513
> AFTER euid = 1004, egid = 513
> sh-4.4$ id
> uid=1004(jvdwater) gid=513(None) groups=513(None),545(Users),11(Authenticated
> Users)
> sh-4.4$ exit
> 64-@@#
>
> It might be ?obvious? to an expert on Windows (after having searched through
> MSDN?), that this privilege (SeAssignPrimaryTokenPrivilege) is required ...
>
> That is, when one is going to invoke CreateProcessAsUser() ...
>
> However, someone without that knowledge ...
> Perhaps a small note to that effect (special privilege required!) in
> "Switching
> the user context with password authentication" might help the 'innocent'
> reader.
You're not supposed to do that. setuid() is a privileged call, so it's
supposed to be called by a privileged process only. Do not add these
permissions to a normal user account unless you exactly know what you're
doing security-wise.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
RE: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
Dear Blake, > External products were being lazy by relying on cygwin to strip CR when they > should have stripped it themselves. But 'sed -b' does NOT strip CR (it is the > exact opposite, of keeping CR unstripped). I think that there are more people who use sed for text processing in a MinGW cygwin cross environment than there are people using sed for binary data - but looking at the mailing list this might be a subjective view. The maintainers of the Linux centric SW could insert dos2unix in all stuff piped into sed, but this would only be required in this very specific build configuration, and Linux SW maintainers frequently argue why they should care about Windows at all. It can take all sorts of philosophical discussions to get such a change in. And I cannot blame them for a "we are free SW people, if you Windowers can make use of our SW without bothering us - go ahead, but please don't drag us into your mud" attitude. In the end one usually gets it done, but the effort is not negligible. I think that sed, grep and awk are in the end text processing tools, and that they should at least have an environment option to behave like text processing tools in a mixed cygwin MinGW environment. With sed I have several 100 issues building a single application, with grep it was just one in my scripts which I fixed. awk no issues so far. Btw.: I don't think that it will be easy or even possible to build detection for MinGW generated output into the cygwin dll as you suggested in a previous post. How should the receiving part of a pipe know what kind of DLLs the sending part has loaded? One could have obscure heuristics to detect "text with cr-lf line endings", but this sounds more like a night mare than a solution. The only entity who could detect this is the shell, but then you have more than one shell (and more philosophers). As I said, I think on cygwin sed, grep and awk should have an environment option to be MinGW friendly text processors (as they used to be). Other less text centric SW should be unaffected. Honestly my solution to the problem is to build sed from sources with CR stripping. I thought about it a day and came to the conclusion that everything else is a waste of time. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
