Re: Windows Subsystem For Linux
On 30.08.2016 23:26, Erik Soderquist wrote: On Tue, Aug 30, 2016 at 4:45 PM, Andrey Repin wrote: Now try to pipe something from a native application to your UFW build, and then the results from it to something else native. I'm eagerly awaiting reports of your success. Done it already, using netcat and a few localhost ports, using ssh Now write a generic script that runs on every box, without interfering others. and using files on the filesystem as flags and I/O sources/destinations. That reminds me on scripting with .bat files back in MS DOS 6.22. Both are workarounds that take your time managing them, not state of the art computing. Herbert -- 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: [ANNOUNCEMENT] boost 1.60.0-1
Hi Yaakov, Thanks for your message. I downloaded your files from cygwinports/boost and tried to apply the patches to boost 1.60.0 and got errors like this one: # the first one runs fine: $ patch -p1 --dry-run < ../cygport/fedora/boost-1.50.0-fix-non-utf8-files.patch checking file libs/units/example/autoprefixes.cpp # the second one gives this error: $ patch -p1 --dry-run < ../cygport/fedora/boost-1.58.0-pool.patch can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Index: boost/pool/pool.hpp |=== |--- boost/pool/pool.hpp(revision 78317) |+++ boost/pool/pool.hpp(revision 78326) -- File to patch: How do you deal with those errors? Do you just skip patches that do not work anymore? Thanks, Frédéric -- 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: igncr shell option breaks my PS1 prompt
On 2 September 2016 at 16:32, Eric Blake wrote: > On 09/02/2016 06:52 AM, Gene Pavlovsky wrote: >> Dear Eric Blake, >> >> Basically, I don't want to set `igncr` as system-wide shell option >> (e.g. through SHELLOPTS). > > Don't use it, then. I highly recommend avoiding 'igncr', because it > exists only as a crutch. The real solution is to fix your environment > to be binary-clean, at which point you no longer need igncr. But I also > understand that fixing an environment to be binary-clean can be > expensive, so 'igncr' remains as the crutch. Exactly, so I would really prefer to avoid crutches. >> So, how do I keep an existing bash script, that uses `read` piped from >> the output of a Windows console program that uses CRLF as newlines, >> working, without modifying the script? I don't see how it's possible >> with the current situation. > By piping the output of the Windows program through d2u before handing > it to 'read'. The script in question (at the moment) is [AutoMySQLBackup](https://sourceforge.net/projects/automysqlbackup/). I didn't make it, I might want to update it when a new version comes out. Having to add either "set -o igncr" or "| d2u" to the script creates a maintainability problem - if I ever update it, I should remember that I did that to this script, and do it again after an update. I could make a wrapper for mysql.exe, that pipes it's output through d2u - which sounds like a bad crutch as well. Worst thing is, I should spend time investigating why some (other) script is failing in a non-obvious fashion. Looking through the code to find out which Windows program it uses that should be piped through d2u. No matter how you look it at, the recent change to `read` might have broken many scripts that were functioning before. The solution you suggested means broken scripts should first be found, then investigated, then some Cygwin-specific code added to them. That sounds like a lot of work, and if the scripts in question are third-party, a maintainability problem. At the moment, I'm forced to use an older version of bash due to this particular issue. Do you see a better solution here? Regards, --Gene -- 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: [ANNOUNCEMENT] boost 1.60.0-1
On 04/09/2016 11:07, Frédéric Bron wrote: Hi Yaakov, Thanks for your message. I downloaded your files from cygwinports/boost and tried to apply the patches to boost 1.60.0 and got errors like this one: # the first one runs fine: $ patch -p1 --dry-run < ../cygport/fedora/boost-1.50.0-fix-non-utf8-files.patch checking file libs/units/example/autoprefixes.cpp # the second one gives this error: $ patch -p1 --dry-run < ../cygport/fedora/boost-1.58.0-pool.patch can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |Index: boost/pool/pool.hpp |=== |--- boost/pool/pool.hpp(revision 78317) |+++ boost/pool/pool.hpp(revision 78326) -- File to patch: How do you deal with those errors? Do you just skip patches that do not work anymore? Thanks, Frédéric try cygport boost.cygport prep It will prepare the directory and applies all the patches in PATCH_URI If one of the patch fails the build stops, so I assume all should apply. Regards Marco -- 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: Script broken after updating bash to 4.3.46-7?
This issue never affected me personally, but it sounds like a serious bug and I'm as glad as anybody that it's finally fixed. However, having existing scripts suddenly breaking is not great. I'd like to remind that I'm not the author of the script in question, [AutoMySQLBackup](http://sourceforge.net/projects/automysqlbackup/). If I put "| d2u" there I'll have to remember it and do it every time automysqlbackup is updated - or create and maintain a Cygwin package for this script. And who knows how many other scripts might be broken, I just didn't find it yet? Having a `read`-specific shell option telling read to treat `\r\n` (and only `\r\n`, not \r followed by something else) same as `\n` would be bad things to have? For me, this kind of option would be more useful than the `igncr` crutch Let me say it another way - in OOP programming, one of good practices is Single Responsibility Principle - a class should be responsible for only one feature/function, and that feature/function should be totally encapsulated in that class. Similar to that, an option should be responsible for one behavior. With this change to `read`, the `igncr` shell option is starting to look like a kitchen sink... split it into separate options, please! I think making UNIX scripts work on Cygwin with no or minimum modifications (or bug-hunting) should be one of high priorities, no? If some scripts erroneously have CRLF line endings, it's easy to find and `d2u` them, rather than using the `igncr` crutch, but with the recent change to `read`, countless scripts might be broken in a non-obvious way. Fixing them would require finding out they're broken, in the first place. Imagine if I didn't set up my cron to e-mail me the cron jobs output? My backup script would just stop working silently, and some time later when I needed a recent backup, I would find out there aren't any. There might be something else lurking that I haven't found yet. Once a script, broken by this change to `read`, is found, it must be checked thoroughly to find out where exactly is the problem, where to put '| d2u', or maybe 'set -o igncr'. These fixes must also be applied anytime a 3rd party script is updated. Quite a lot of work! Hope you will consider my point. Regards, Gene. On 30 August 2016 at 23:57, cyg Simple wrote: > On 8/30/2016 1:38 PM, Eric Blake wrote: >> On 08/30/2016 12:04 PM, cyg Simple wrote: >>> On 8/29/2016 2:30 PM, Eric Blake wrote: Simplest fix: read ... < <(mysql ... | dos2unix) >>> >>> This will break when the data returned by mysql is supposed to contain \r. >>> There. Now you aren't feeding \r to read in the first place. >>> >>> But you might want to feed \r to read. It isn't a fix, it is a >>> potential work around dependent on the data set results. If a read that >>> is supposed to be reading binary data doesn't pass all of the data to >>> the routine then it is broken. >> >> Now we're talking past each other. >> >> That's what the recent bash fixed. 'read' in bash 3.2.42-4 was broken - >> it corrupted binary data, with no recourse, by eating \r (and worse, by >> sometimes eating the byte after \r). 'read' in bash 3.2.46-7 is fixed - >> by default it is strictly binary (all bytes are read as-is, including >> \r), but can also be switched to text mode (using 'igncr', all \r are >> ignored). If you want to preserve mid-line \r but treat line endings of >> \r\n as a single byte, then leave binary mode on and strip the line >> endings via a separate tool like d2u (note, however, that it is very >> rare to have data where mid-line \r is important but line-ending \r\n >> should be treated as plain \n). >> >> I strongly think that using igncr is a crutch, and you normally >> shouldn't use it; particularly not if you want to be portable to other >> platforms. Instead, massaging your data through d2u is a great way to >> be portable. But sometimes the ease of ignoring ALL \r is easier than >> worrying about portability, so I keep the 'igncr' code in Cygwin. >> >> And it is only because the OP tried using 'igncr' in the first place >> (whether or not it was actually needed) that we have now flushed out the >> existence of a latent bug in the 'igncr' implementation that interacts >> weirdly with $()\n in PS1. On that front, I'm still hoping to find time >> to debug and/or for someone to post a patch. But whether PS1 behaves >> weirdly under 'igncr' is orthogonal to my suggestion above - using >> 'mysql|d2u' is a great way to avoid the need to worry about 'igncr'. >> > > Thank you for the retort Eric. Happy to know that it is fixed which in > the back of my mind I knew already. I can imagine data such as full > message email or a small document data containing \r\n as valid data in > the database field and if you use a line ending conversion utility you > might loose that data. > > -- > cyg Simple > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated/Test: base-files-4.3-1
Achim Gratz wrote:
4.3-1 (feature release)
* Cygwin.bat: Add to base-files. This version is independent of
the actual install path, see:
cygwin.com/ml/cygwin/2016-08/msg00617.html
Thanks for accepting the patch.
Unfortunately I missed a detail: The postinstall script does not
preserve the x-permission of Cygwin.bat. This is required if run from
explorer or with 'cygstart /Cygwin.bat'.
Possible fix attached. Alternatively remove the 'touch' command and the
x-permission from etc/defaults/etc/profile.
Thanks,
Christian
--- base-files-profile.sh.orig 2016-09-03 13:37:59.0 +0200
+++ base-files-profile.sh 2016-09-04 12:42:40.805222900 +0200
@@ -18,7 +18,7 @@
if [ ! -e ${fDest} -a ! -L ${fDest} ]; then
echo "Using the default version of ${fDest} (${fSrc})"
/usr/bin/mkdir -p $(dirname ${fDest})
-/usr/bin/touch ${fDest}
+test "${fDest}" = "/Cygwin.bat" || /usr/bin/touch ${fDest}
/usr/bin/cp ${fSrc} ${fDest}
else
echo "${fDest} is already in existence, not overwriting."
--
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: [ANNOUNCEMENT] Updated/Test: base-files-4.3-1
Christian Franke writes:
> --- base-files-profile.sh.orig2016-09-03 13:37:59.0 +0200
> +++ base-files-profile.sh 2016-09-04 12:42:40.805222900 +0200
> @@ -18,7 +18,7 @@
>if [ ! -e ${fDest} -a ! -L ${fDest} ]; then
> echo "Using the default version of ${fDest} (${fSrc})"
> /usr/bin/mkdir -p $(dirname ${fDest})
> -/usr/bin/touch ${fDest}
> +test "${fDest}" = "/Cygwin.bat" || /usr/bin/touch ${fDest}
> /usr/bin/cp ${fSrc} ${fDest}
>else
> echo "${fDest} is already in existence, not overwriting."
I have no idea why it's touching the file first, but I'd rather use
cp --preserve=mode
and fix the mode bits in /etc/defaults if necessary.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
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: /etc/profile: avoid multiple /usr/bin in PATH
Helmut Karlowski writes: > I set C:/cygwin/usr/bin in my windows-environment. Now /etc/profile > always adds /usr/bin to PATH resulting in /usr/bin being twice in my > cygwin-PATH. > > The attached patch fixes this. I've added the option to just use the already set-up PATH variable from Windows for this use case. Set CYGWIN_USEWINPATH before starting up. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: [ANNOUNCEMENT] Updated/Test: base-files-4.3-1
Achim Gratz wrote:
Christian Franke writes:
--- base-files-profile.sh.orig 2016-09-03 13:37:59.0 +0200
+++ base-files-profile.sh 2016-09-04 12:42:40.805222900 +0200
@@ -18,7 +18,7 @@
if [ ! -e ${fDest} -a ! -L ${fDest} ]; then
echo "Using the default version of ${fDest} (${fSrc})"
/usr/bin/mkdir -p $(dirname ${fDest})
-/usr/bin/touch ${fDest}
+test "${fDest}" = "/Cygwin.bat" || /usr/bin/touch ${fDest}
/usr/bin/cp ${fSrc} ${fDest}
else
echo "${fDest} is already in existence, not overwriting."
I have no idea why it's touching the file first, but I'd rather use
cp --preserve=mode
and fix the mode bits in /etc/defaults if necessary.
I guess the touch command is from the early days to ensure that all
files get same default permissions regardless of source file permissions.
Removing the touch command would be sufficient. A 'cp' without options
uses the permission mask from source file when a new file is created
(POSIX requirement). Cygport's make_etc_defaults also generates plain
/usr/bin/cp commands.
"cp --preserve" would also copy owner and timestamps.
Regards,
Christian
--
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
Problem with Python programs with binary components, who to blame?
Hi, Before writing any formal bug report I thought I might ask first whether the problem I am seeing is something that can be even fixed from Cygwin's side. The issue has to do with the compilation of Python binary packages for Python inside Cygwin (Python installed as a Cygwin package as opposed to Python for Windows). The problem starts to show as gcc warnings: "[…] redeclared without dllimport attribute: previous dllimport ignored", and ends with linkers errors such as: "relocation truncated to fit [...] against undefined symbol". I am guessing the problem might actually lie within the Python sources itself but I am not entirely sure. So is this some issue that is even worth further research and filing a bug report 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
Re: [ANNOUNCEMENT] Updated/Test: base-files-4.3-1
Christian Franke writes: > Removing the touch command would be sufficient. A 'cp' without options > uses the permission mask from source file when a new file is created > (POSIX requirement). Cygport's make_etc_defaults also generates plain > /usr/bin/cp commands. > > "cp --preserve" would also copy owner and timestamps. No, a 'cp -p" would do. I've explicitly told it to just copy the mode bits. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Problem with Python programs with binary components, who to blame?
On 04/09/2016 16:34, Patrick Pief wrote: Hi, Before writing any formal bug report I thought I might ask first whether the problem I am seeing is something that can be even fixed from Cygwin's side. The issue has to do with the compilation of Python binary packages for Python inside Cygwin (Python installed as a Cygwin package as opposed to Python for Windows). The problem starts to show as gcc warnings: "[…] redeclared without dllimport attribute: previous dllimport ignored", and ends with linkers errors such as: "relocation truncated to fit [...] against undefined symbol". I am guessing the problem might actually lie within the Python sources itself but I am not entirely sure. So is this some issue that is even worth further research and filing a bug report here? On windows all symbols must be available at linking time. Cygwin programs/libraries have the same constrain. Can you report the full command that produce : ""relocation truncated to fit [...] against undefined symbol"." ? Are you building a specific program or it is your own development ? Regards Marco -- 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: [ANNOUNCEMENT] Updated/Test: base-files-4.3-1
Achim Gratz wrote: Christian Franke writes: Removing the touch command would be sufficient. A 'cp' without options uses the permission mask from source file when a new file is created (POSIX requirement). Cygport's make_etc_defaults also generates plain /usr/bin/cp commands. "cp --preserve" would also copy owner and timestamps. No, a 'cp -p" would do. I've explicitly told it to just copy the mode bits. Yes - sorry for the noise. Regards, Christian -- 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: updated vim broke arrow/delete keys
Erik, The motive: http://learnvimscriptthehardway.stevelosh.com/chapters/10.html The idea is to force yourself to use a faster escape key. Gary, the output of that command: timeoutlen=1000 ttimeoutlen=-1 I guess the final answer is the one from Randy Morris: https://stackoverflow.com/questions/8488232/how-to-disable-esc-and-cursor-keys-in-vim "In conclusion, don't remap escape, I almost guarantee you will have unexpected consequences." It feels like and some other keys are a combination of other keys as Erik pointed out. I'm going to send an email to the author of vimscript to add a warning or something like that. Thanks for all the help again guys. Best, -- Felipe Martins Vieira Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D signature.asc Description: Digital signature
Re: Script broken after updating bash to 4.3.46-7?
On 9/4/16, Gene Pavlovsky wrote: > This issue never affected me personally, but it sounds like a serious > bug and I'm as glad as anybody that it's finally fixed. > However, having existing scripts suddenly breaking is not great. I'd > like to remind that I'm not the author of the script in question, > [AutoMySQLBackup](http://sourceforge.net/projects/automysqlbackup/). > If I put "| d2u" there I'll have to remember it and do it every time > automysqlbackup is updated ... Right - updating something like automysqlbackup to add "| d2u" after every dos program call is a non-starter. But would putting the dos program inside a script that converted dos -> unix line endings work? eg - have a mysql script that comes before the windows version of mysql in your path that does something like /path/to/windows/version/of/mysql $@ | dos2unix > - or create and maintain a Cygwin package for this script. It seems to me that it isn't the script that's broken - it's the whole idea of having a dos program transparently integrate into an environment that expects unix line endings that's broken. So until there's a bash option that automatically translates '\r\n' line endings into '\n' line endings you're stuck doing some kind of work-around or using a cygwin version of mysql. Lee > And who knows how many other scripts might be broken, > I just didn't find it yet? > > Having a `read`-specific shell option telling read to treat `\r\n` > (and only `\r\n`, not \r followed by something else) same as `\n` > would be bad things to have? For me, this kind of option would be more > useful than the `igncr` crutch > Let me say it another way - in OOP programming, one of good practices > is Single Responsibility Principle - a class should be responsible for > only one feature/function, and that feature/function should be totally > encapsulated in that class. Similar to that, an option should be > responsible for one behavior. With this change to `read`, the `igncr` > shell option is starting to look like a kitchen sink... split it into > separate options, please! > I think making UNIX scripts work on Cygwin with no or minimum > modifications (or bug-hunting) should be one of high priorities, no? > If some scripts erroneously have CRLF line endings, it's easy to find > and `d2u` them, rather than using the `igncr` crutch, but with the > recent change to `read`, countless scripts might be broken in a > non-obvious way. Fixing them would require finding out they're broken, > in the first place. Imagine if I didn't set up my cron to e-mail me > the cron jobs output? My backup script would just stop working > silently, and some time later when I needed a recent backup, I would > find out there aren't any. There might be something else lurking that > I haven't found yet. Once a script, broken by this change to `read`, > is found, it must be checked thoroughly to find out where exactly is > the problem, where to put '| d2u', or maybe 'set -o igncr'. These > fixes must also be applied anytime a 3rd party script is updated. > Quite a lot of work! > Hope you will consider my point. > Regards, > Gene. > > On 30 August 2016 at 23:57, cyg Simple wrote: >> On 8/30/2016 1:38 PM, Eric Blake wrote: >>> On 08/30/2016 12:04 PM, cyg Simple wrote: On 8/29/2016 2:30 PM, Eric Blake wrote: > > Simplest fix: > > read ... < <(mysql ... | dos2unix) > This will break when the data returned by mysql is supposed to contain \r. > There. Now you aren't feeding \r to read in the first place. > But you might want to feed \r to read. It isn't a fix, it is a potential work around dependent on the data set results. If a read that is supposed to be reading binary data doesn't pass all of the data to the routine then it is broken. >>> >>> Now we're talking past each other. >>> >>> That's what the recent bash fixed. 'read' in bash 3.2.42-4 was broken - >>> it corrupted binary data, with no recourse, by eating \r (and worse, by >>> sometimes eating the byte after \r). 'read' in bash 3.2.46-7 is fixed - >>> by default it is strictly binary (all bytes are read as-is, including >>> \r), but can also be switched to text mode (using 'igncr', all \r are >>> ignored). If you want to preserve mid-line \r but treat line endings of >>> \r\n as a single byte, then leave binary mode on and strip the line >>> endings via a separate tool like d2u (note, however, that it is very >>> rare to have data where mid-line \r is important but line-ending \r\n >>> should be treated as plain \n). >>> >>> I strongly think that using igncr is a crutch, and you normally >>> shouldn't use it; particularly not if you want to be portable to other >>> platforms. Instead, massaging your data through d2u is a great way to >>> be portable. But sometimes the ease of ignoring ALL \r is easier than >>> worrying about portability, so I keep the 'igncr' code in Cygwin. >>> >>> And it is only because the OP tried using 'i
[ANNOUNCEMENT] Updated: perl-Text-CSV_XS-1.25-1
The following package has been updated in the Cygwin distribution: * perl-Text-CSV_XS-1.25-1 Text::CSV_XS provides facilities for the composition and decomposition of comma-separated values. An instance of the Text::CSV_XS class will combine fields into a CSV string and parse a CSV string into fields. This is an update to the latest upstream release. Dave -- 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] Updated: poco-1.7.3-2
The following packages have been updated in the Cygwin distribution: * libpoco-devel-1.7.3-2 * libpoco43-1.7.3-2 * poco-1.7.3-2 * poco-doc-1.7.3-2 The POCO C++ Libraries are open source C++ class libraries that simplify and accelerate the development of network-centric, portable applications in C++. This build reinstates the Data/MySQL, Data/ODBC and MongoDB components. These components are no longer built by default and so were omitted from the previous build. Note that users of the 'Poco::UTF32String' class should compile using the '-frepo' g++ compiler switch. Details here: https://cygwin.com/ml/cygwin/2015-04/msg00130.html Dave. -- 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] Updated: mkvtoolnix-9.4.0-1
The following packages have been updated in the Cygwin distribution: * mkvtoolnix-9.4.0-1 * mkvtoolnix-gui-9.4.0-1 MKVToolNix is a set of tools to create, alter and inspect Matroska files (*.mkv, *.mka). This is an update to the latest upstream release. Dave. -- 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: [ANNOUNCEMENT] boost 1.60.0-1
> try > cygport boost.cygport prep that works. I will try to find why. Thanks, Frédéric -- 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: Problem with Python programs with binary components, who to blame?
On 9/4/2016 10:43 AM, Marco Atzeri wrote: On 04/09/2016 16:34, Patrick Pief wrote: Hi, Before writing any formal bug report I thought I might ask first whether the problem I am seeing is something that can be even fixed from Cygwin's side. The issue has to do with the compilation of Python binary packages for Python inside Cygwin (Python installed as a Cygwin package as opposed to Python for Windows). The problem starts to show as gcc warnings: "[…] redeclared without dllimport attribute: previous dllimport ignored", and ends with linkers errors such as: "relocation truncated to fit [...] against undefined symbol". I am guessing the problem might actually lie within the Python sources itself but I am not entirely sure. So is this some issue that is even worth further research and filing a bug report here? On windows all symbols must be available at linking time. Cygwin programs/libraries have the same constrain. Can you report the full command that produce : ""relocation truncated to fit [...] against undefined symbol"." ? Are you building a specific program or it is your own development ? I also wonder about: - 32-bit versus 64-bit Cygwin, whether it may be an issue - Such a build would need to be treated as a Posix build, not a Windows build, and probably should not be trying to access Windows libraries (as opposed to Cygwin libraries) dllimport is meaningful for Windows, not for Posix, I believe. So I wonder if you're actually running Cygwin's gcc ... Anyway, some things to check into ... Eliot Moss -- 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: Problem with Python programs with binary components, who to blame?
On 2016-09-04 08:34, Patrick Pief wrote: Before writing any formal bug report I thought I might ask first whether the problem I am seeing is something that can be even fixed from Cygwin's side. The issue has to do with the compilation of Python binary packages for Python inside Cygwin (Python installed as a Cygwin package as opposed to Python for Windows). The problem starts to show as gcc warnings: "[…] redeclared without dllimport attribute: previous dllimport ignored", and ends with linkers errors such as: "relocation truncated to fit [...] against undefined symbol". I am guessing the problem might actually lie within the Python sources itself but I am not entirely sure. So is this some issue that is even worth further research and filing a bug report here? Hi Patrick, Read about cygwin dll exports and imports at https://cygwin.com/cygwin-ug-net/dll.html You may want to find a similar Cygwin Python module and look at the source package (something called python-...-v.n-p-src) to see how it is built using cygport, which takes care of some Cygwin specific differences in builds. If you still have issues, please provide all the information requested by: https://cygwin.com/problems.html which includes attaching cygcheck and build output logs. -- 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: updated vim broke arrow/delete keys
On 2016-09-04 09:19, Felipe M. Vieira wrote: The motive: http://learnvimscriptthehardway.stevelosh.com/chapters/10.html If the title alone does not put you off, it should be a warning, and the author warns it is not a tutorial, it is one way to learn how to customize vim, and I would add, should be done in a sandbox: a separate account from your working account, and only after reading the whole article from start to finish before trying anything, as the impact of the changes is nowhere clearly explained, just what the immediate effect is and whay that is considered desirable by the author. The idea is to force yourself to use a faster escape key. the output of that command: timeoutlen=1000 ttimeoutlen=-1 I guess the final answer is the one from Randy Morris: https://stackoverflow.com/questions/8488232/how-to-disable-esc-and-cursor-keys-in-vim "In conclusion, don't remap escape, I almost guarantee you will have unexpected consequences." It feels like and some other keys are a combination of other keys as Erik pointed out. I'm going to send an email to the author of vimscript to add a warning or something like that. Send the email to the author of the article Steve Losh, and suggest his article could be improved by discussing the impact of his changes, and not just the immediate effect; I suspect the author of vim and its scripting language Bram Moolenaar would be unlikely to suggest remapping ! -- 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: /etc/profile: avoid multiple /usr/bin in PATH
On 4 September 2016 at 05:32, Achim Gratz wrote: > Helmut Karlowski writes: >> I set C:/cygwin/usr/bin in my windows-environment. Now /etc/profile >> always adds /usr/bin to PATH resulting in /usr/bin being twice in my >> cygwin-PATH. >> >> The attached patch fixes this. > > I've added the option to just use the already set-up PATH variable from > Windows for this use case. Set CYGWIN_USEWINPATH before starting up. > Please make sure that this version of cygwin.bat will work correctly when CYGWIN_NOWINPATH=1 is set in the windows environment. I use this to isolate my cygwin environment from random windows stuff. When I need to execute windows executables, I wrap the call in a script or alias that makes just enough of the window's path available to let it work. This makes it much safer when running multiple cygwins, intentionally for 32bit and 64bit, or unintentionally as when running windows apps that include a cygwin.dll, e.g. GitHub for Windows. Also it avoids accidentally running non-cygwin versions of *nix programs such as can happen when you have Gnu for Windows or MSYS in your windows path. Note that CYGWIN_NOWINPATH is still undocumented, except in the email archives. See, e.g. https://www.google.ca/search?q=CYGWIN_NOWINPATH+site:cygwin.com CYGWIN_USEWINPATH is also undocumented, except in a non-cygwin.com email archive. Thanks, Doug -- Doug Henderson, 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: Problem with Python programs with binary components, who to blame?
On 4 September 2016 at 08:34, Patrick Pief wrote: > Hi, > > Before writing any formal bug report I thought I might ask first whether the > problem I am seeing is something that can be even fixed from Cygwin's side. > > The issue has to do with the compilation of Python binary packages for Python > inside Cygwin (Python installed as a Cygwin package as opposed to Python for > Windows). > The problem starts to show as gcc warnings: "[…] redeclared without dllimport > attribute: previous dllimport ignored", and ends with linkers errors such as: > "relocation truncated to fit [...] against undefined symbol". > > I am guessing the problem might actually lie within the Python sources itself > but I am not entirely sure. > > So is this some issue that is even worth further research and filing a bug > report here? Often the setup.py for the package will use windows build commands when trying to build an extension for a python that runs under cygwin. The setup.py needs to be changed so it uses the build instructions for a *nix or Posix system to build the extension under cygwin. Typically these kind of extensions may need to import cygwin DLLs that are installed by another package. The change may be as simple as adding a relation to an existing if statement to recognize cygwin as distinct from windows. If you have an extension that also needs to load windows DLL files, you may need to add a section to the setup.py to support that kind of hybrid situation. An example of this is cx_Oracle, which must use windows DLL(s) supplied by Oracle. This is often easier t do with the cooperation of the extension developer. HTH Doug -- Doug Henderson, 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
