Re: Cygwin windows won't close
Am 09.10.2018 um 19:22 schrieb Ziegelmiller, Lyle(AWF) via cygwin: Then I don't see much of the cause for such a behavior from Cygwin side. May be other software interfering. Do you have a particularly zealous "antivirus", pehaps? We're using "Symantec Endpoint Protection", Version 14. I could see an anti-virus program preventing the execution of a Cygwin window, but not the closing of one. I have seen Symantec in the past creating such problems. Probably they inject something in the call sequence. PS: can you please use a sane mail program ? Your reply to Andrey has no proper indentation, and it is difficult to split your reply from Andrey's message. --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: Cygwin windows won't close
On 10/9/2018 1:22 PM, Ziegelmiller, Lyle(AWF) via cygwin wrote: > > We're using "Symantec Endpoint Protection", Version 14. > > I could see an anti-virus program preventing the execution of a Cygwin > window, but not the closing of one. > If you wait for a few minutes is the result different? If you have a different experience based on time expended then the likelihood of an interfering AV program is greater. -- 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: Zstandard support for setup
Jon Turney writes:
> On 02/09/2018 09:29, Achim Gratz wrote:
>> Jon Turney writes:
>>> This should check for ztd in configure.ac using PKG_CHECK_MODULES,
>>> rather than just assuming -lzstd is going to work.
>>
>> Sure. Waiting for your patch to actually use pkg_config to rebase it
>> onto.
>
> This is applied now.
Thanks. I'll see to get a round tuit soon-ish.
>>> The setup executables are cross-built on Fedora, so a
>>> mingw{32,64}-zstd-static package will need to become available.
>>
>> I don't have any contacts into the Fedora community, so I'd appreciate
>> if maybe Yaakov could help? I have not yet found a distro that already
>> has packages for MinGW.
>
> https://github.com/jon-turney/mingw-zstd-rpm
> https://copr.fedorainfracloud.org/coprs/jturney/mingw-zstd/
\o/
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: Zstandard support for setup
Jon Turney writes: > On 02/09/2018 18:02, Achim Gratz wrote: >> What an unholy mess… Here's that patch, only lightly tested: >> http://repo.or.cz/cygwin-setup/local.git/patch/e9802f50304f66984f6aad5544def465e9f8033b > > Yeah. Thanks, and sorry for the delay. No sweat and thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: setup and 'provides:'
cyg Simple writes: > I assumed that this was the case. But the symlink is a conflict and I > assume that if one exists already the package management system would > not recreate one or would ask the user if it should be overwritten. The symlink to the actual executable is not a conflict since it isn't packaged. It is created / altered via alternatives in a postinstall script (and potentially altered and/or removed by a pre-remove script). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: setup and 'provides:'
Ken Brown writes: >>> So we'd need to bolt on a feature space in setup as well. > > I'm not sure what you mean by this. setup doesn't need to know whether a > requirement is a feature or a package. It simply passes the dependencies > (and > the provides) to libsolv, which handles them just fine. If we have features, then setup would need to show them somewhere and it would be awkward if that info was empty for most packages. Then people will want to install features instead of packages anyway, so that is another nudge into "featurizing" the whole distribution. In other words, once we start using "provides:" in that way, I think it should become mandatory. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: vim yellow lines problem
On 10/9/2018 4:33, James Darnley wrote: On 2018-10-09 10:49, Tapas Mishra wrote: I had a C program which I copy pasted and there were line numbers in code. So I replaced line numbers in vi by following command :%s/\d*. (<-- last of * is a dot) Now I am opening vim in cygwin then all typed lines are coming yellow. https://i.stack.imgur.com/Dxd8h.jpg How do I fix this problem, :noh or :nohlsearch It looks like it is highlighting the matches of the last search you made which was "digit class, 0 or more, and any char". I would not expect Vim to highlight on opening a new file though, only when you tell it to search. 1. Vim remembers your last search and acts accordingly, even on a new file. 2. What you are searching for is 'zero or more matches of a digit followed by any character', i.e. 'anything', so it gets highlighted. My usual trick to accomplish this is to type /aseldkfja/, where "aseldkfja" is any short burst of random typing, and then hit return. Your screen should return to normal. -- 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 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 and 'provides:'
On 10/9/2018 11:10 AM, cyg Simple wrote: > On 10/8/2018 12:24 PM, Ken Brown wrote: >> On 10/8/2018 11:17 AM, cyg Simple wrote: >>> On 10/8/2018 11:05 AM, Ken Brown wrote: Here's an example (modeled on what Fedora does): Cygwin has four packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and emacs-w32. Users can install any or all of these if they want to be able to run emacs. The differences are in the UI. These packages don't conflict with one another. >>> >>> How do they overcome the conflict? >> >> They use different names for the emacs binaries: emacs-nox.exe, >> emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe. The "alternatives" >> system then creates a symlink /usr/bin/emacs that resolves to whichever >> binary the user wants to use by default. It's been this way for many >> years, with no problems. >> > > I assumed that this was the case. But the symlink is a conflict and I > assume that if one exists already the package management system would > not recreate one or would ask the user if it should be overwritten. No, that's not how it works. The symlink is created and managed by the alternatives system via commands in postinstall/preremove scripts and in user-callable scripts /usr/bin/set-emacs-default-*. There is no conflict. The various emacs packages can happily coexist. If some other package requires an emacs binary, I would like it to be able to require "emacs-bin". [This plays the role of "foo" in my test case.] Then I would like to be able to say that all four emacs packages above provide "emacs-bin". >>> >>> That's fine but how do an installation of multiple emacs-bin not create >>> a conflict? >> >> "emacs-bin" is not a thing that can be installed. It's simply a name >> for a requirement, and that requirement can be met by installing any >> package that declares that it provides "emacs-bin". At least that's my >> understanding of how it works in package managers like rpm. As I said >> at the very beginning, it's quite possible that I'm misunderstanding how >> 'provides:' is supposed to work. > > And I understand that emacs-bin is a pseudo name identifying a class of > product the package provides. The RPM system allows for defining > Requires, Provides, Conflicts and Obsoletes. So does Cygwin's setup. > The Arch Linux pacman > allows for depends, makedepends, checkdepends, optdepends, provides, > replaces and conflicts. As you can see other package managers see > *conflicts* as an important item because of the global namespace issue. I agree that it can be useful, and I'm glad setup supports it. Ken
RE: Cygwin windows won't close
-Original Message- From: Andrey Repin Sent: Tuesday, October 9, 2018 4:47 AM To: Ziegelmiller, Lyle(AWF) ; cygwin@cygwin.com Subject: Re: Cygwin windows won't close Greetings, Ziegelmiller, Lyle(AWF)! > Greetings. When I click on the X at the upper-right hand corner of the window, it just hangs. When I click on the X again, the title bar displays, "(Not Responding)". Prior to attempting to close the window, everything works fine. > >>> I mean the Cygwin command-window terminal, invoked by this shortcut: > >>> C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - > >> Does it happen if you try to close the terminal immediately after starting? > Yes, as well as any time after that. >> Did you run any specific applications for it to happen? > No. Even if I just open the window, and then attempt to close it, it does > this. >> Any alterations to shell startup scripts? > In .bashrc, I have at the end, after all the commented out stuff: > set -o vi > set tabcomplete > alias path="echo $PATH | perl -pe 's/:/\n/g'" > alias cdpath="echo $CDPATH | perl -pe 's/:/\n/g'" > export FIGNORE=.o:.java~:.class:.bak > alias wpwd='cygpath --windows `pwd`' > if [ -z "$RANPROFILE" ]; then > PATH="/usr/local/bin:/usr/bin:/bin:$PATH" > Fi > That's about all I've done to it. Then I don't see much of the cause for such a behavior from Cygwin side. May be other software interfering. Do you have a particularly zealous "antivirus", pehaps? We're using "Symantec Endpoint Protection", Version 14. I could see an anti-virus program preventing the execution of a Cygwin window, but not the closing of one. -- With best regards, Andrey Repin Tuesday, October 9, 2018 14:45:17 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: Fun with cp -R error when both foo and foo.exe exist
Right. My thinking was that the auto-suffix probing makes sense when running or checking for a program, but not when creating a program. (I could be wrong, and I imagine if I actually compiled and tested the hack I'd find out pretty quickly if it was at least obviously wrong.) O_BINARY doesn't need to be there, but I included it as an additional filter because cp uses it. Can leave it out. I misremembered suffices as a britishism, sorry. - Dan -- 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: Fun with cp -R error when both foo and foo.exe exist
On 10/9/18 11:21 AM, Dan Kegel wrote:
On Tue, Oct 9, 2018 at 5:03 AM Eric Blake wrote:
whether someone patches the cygwin dll or cp, it seems like some rather
hairy code for what is normally a rare corner case, so it probably won't
happen unless someone actually contributes a patch.
Right. Here's a completely untested guess patch:
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1363,7 +1363,15 @@ open (const char *unix_path, int flags, ...)
opt |= PC_CTTY;
}
- if (!(fh = build_fh_name (unix_path, opt, stat_suffixes)))
+ suffix_info *suffices = stat_suffixes;
suffices is a completely different word; did you mean suffixes?
+ if ((opt & (O_WRONLY|O_BINARY)) == (O_WRONLY|O_BINARY))
O_WRONLY need not be a bitmask; it's better to use O_ACCMODE for the
bitmask, as in
opt & (O_ACCMODE|O_BINARY) == O_WRONLY|O_BINARY
+{
+ /* Hack so 'cp foo bar' doesn't abort with
+ 'cp: cannot create regular file bar: File exists'
+if bar.exe already exists */
+ suffices = NULL;
+ }
+ if (!(fh = build_fh_name (unix_path, opt, suffices)))
So, with mistakes corrected, your hack is that cygwin doing auto-suffix
probing should be suppressed in the case of opening a file O_WRONLY? Why
does O_BINARY have to fit in the equation?
__leave;/* errno already set */
if ((flags & O_NOFOLLOW) && fh->issymlink ())
{
Feel free to throw rotten fruit :-)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--
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: Fun with cp -R error when both foo and foo.exe exist
On Tue, Oct 9, 2018 at 5:03 AM Eric Blake wrote:
> whether someone patches the cygwin dll or cp, it seems like some rather
> hairy code for what is normally a rare corner case, so it probably won't
> happen unless someone actually contributes a patch.
Right. Here's a completely untested guess patch:
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1363,7 +1363,15 @@ open (const char *unix_path, int flags, ...)
opt |= PC_CTTY;
}
- if (!(fh = build_fh_name (unix_path, opt, stat_suffixes)))
+ suffix_info *suffices = stat_suffixes;
+ if ((opt & (O_WRONLY|O_BINARY)) == (O_WRONLY|O_BINARY))
+{
+ /* Hack so 'cp foo bar' doesn't abort with
+ 'cp: cannot create regular file bar: File exists'
+if bar.exe already exists */
+ suffices = NULL;
+ }
+ if (!(fh = build_fh_name (unix_path, opt, suffices)))
__leave;/* errno already set */
if ((flags & O_NOFOLLOW) && fh->issymlink ())
{
Feel free to throw rotten fruit :-)
- Dan
--
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 and 'provides:'
On 10/8/2018 12:24 PM, Ken Brown wrote: > On 10/8/2018 11:17 AM, cyg Simple wrote: >> On 10/8/2018 11:05 AM, Ken Brown wrote: >>> Here's an example (modeled on what Fedora does): Cygwin has four >>> packages that provide emacs binaries: emacs, emacs-X11, emacs-lucid, and >>> emacs-w32. Users can install any or all of these if they want to be >>> able to run emacs. The differences are in the UI. These packages don't >>> conflict with one another. >>> >> >> How do they overcome the conflict? > > They use different names for the emacs binaries: emacs-nox.exe, > emacs-X11.exe, emacs-lucid.exe, and emacs-w32.exe. The "alternatives" > system then creates a symlink /usr/bin/emacs that resolves to whichever > binary the user wants to use by default. It's been this way for many > years, with no problems. > I assumed that this was the case. But the symlink is a conflict and I assume that if one exists already the package management system would not recreate one or would ask the user if it should be overwritten. >>> If some other package requires an emacs binary, I would like it to be >>> able to require "emacs-bin". [This plays the role of "foo" in my test >>> case.] Then I would like to be able to say that all four emacs packages >>> above provide "emacs-bin". >>> >> >> That's fine but how do an installation of multiple emacs-bin not create >> a conflict? > > "emacs-bin" is not a thing that can be installed. It's simply a name > for a requirement, and that requirement can be met by installing any > package that declares that it provides "emacs-bin". At least that's my > understanding of how it works in package managers like rpm. As I said > at the very beginning, it's quite possible that I'm misunderstanding how > 'provides:' is supposed to work. And I understand that emacs-bin is a pseudo name identifying a class of product the package provides. The RPM system allows for defining Requires, Provides, Conflicts and Obsoletes. The Arch Linux pacman allows for depends, makedepends, checkdepends, optdepends, provides, replaces and conflicts. As you can see other package managers see *conflicts* as an important item because of the global namespace issue. -- cyg Simple
Glass Tec 2018
Hi, Hope you are doing great! I see that your company will be exhibiting at the Glass Tec 2018. So I am reaching out to you to check if you'd be interested in acquiring a list of 40,200 visitors who will be attending the show to increase your customer base? If you feel this might bring some changes in your business growth, we will be happy to send you the pricing detail for your review. I look forward to hearing from you. Regards, Florence Mason Marketing Manager Santa Clara, CA, -- 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: Fun with cp -R error when both foo and foo.exe exist
On 10/9/18 1:22 AM, Marco Atzeri wrote: Am 08.10.2018 um 23:24 schrieb Dan Kegel: A nice workaround might be for the cygwin version of cp could arrange to wait to create .exe files until after any potential non-suffixed file has been processed... not sure how easy that would be. Apologies if this has already been discussed. - Dan it is not cp handling the magic, but the cygwin dll. Mostly the cygwin dll, but cp itself DOES have some cygwin-specific downstream patches to try and behave smarter. At any rate, POSIX requires cp to handle command line arguments in the order given, but does not require recursion to copy in any specific order for files within a directory. But the order that makes the most sense is the order that readdir() returns things, because any other order requires sorting the files (and thus the memory to track the files) and a longer window for races to occur with anything else changing directory contents in parallel. Perhaps you could even argue that readdir() should visit 'foo' and 'foo.exe' in a particular order, no matter whether the native ordering would display them in the opposite order. But in general, whether someone patches the cygwin dll or cp, it seems like some rather hairy code for what is normally a rare corner case, so it probably won't happen unless someone actually contributes a patch. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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: Cygwin windows won't close
Greetings, Ziegelmiller, Lyle(AWF)! > Greetings. When I click on the X at the upper-right hand corner of the window, it just hangs. When I click on the X again, the title bar displays, "(Not Responding)". Prior to attempting to close the window, everything works fine. > >>> I mean the Cygwin command-window terminal, invoked by this shortcut: > >>> C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - > >> Does it happen if you try to close the terminal immediately after starting? > Yes, as well as any time after that. >> Did you run any specific applications for it to happen? > No. Even if I just open the window, and then attempt to close it, it does > this. >> Any alterations to shell startup scripts? > In .bashrc, I have at the end, after all the commented out stuff: > set -o vi > set tabcomplete > alias path="echo $PATH | perl -pe 's/:/\n/g'" > alias cdpath="echo $CDPATH | perl -pe 's/:/\n/g'" > export FIGNORE=.o:.java~:.class:.bak > alias wpwd='cygpath --windows `pwd`' > if [ -z "$RANPROFILE" ]; then > PATH="/usr/local/bin:/usr/bin:/bin:$PATH" > Fi > That's about all I've done to it. Then I don't see much of the cause for such a behavior from Cygwin side. May be other software interfering. Do you have a particularly zealous "antivirus", pehaps? -- With best regards, Andrey Repin Tuesday, October 9, 2018 14:45:17 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: vim yellow lines problem
On 2018-10-09 10:49, Tapas Mishra wrote: > I had a C program which I copy pasted and there were line numbers in code. > So I replaced line numbers in vi by following command > :%s/\d*. (<-- last of * is a dot) > > Now I am opening vim in cygwin then all typed lines are coming yellow. > https://i.stack.imgur.com/Dxd8h.jpg > > How do I fix this problem, :noh or :nohlsearch It looks like it is highlighting the matches of the last search you made which was "digit class, 0 or more, and any char". I would not expect Vim to highlight on opening a new file though, only when you tell it to search. -- 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: Unable to compile clamav
Am 09.10.2018 um 11:19 schrieb Stephen Grant Brown: Hi There. I have compiled and installed the source code for zlib-1.2.11-1.src. When compiling clamav I get the following error. configure: error: The installed zlib version may contain a security bug. Please upgrade to 1.2.2 or later: http://www.zlib.net. You can omit this check with --disable-zlib-vcheck but DO NOT REPORT any stability issues then! *** ERROR: configure failed What am i doing wrong in compiling clamav? Yours Sincerely Stephen Brown why do you need to compile zlib and you are not using the available packages ? $ cygcheck -cd| grep zlib zlib1.2.11-1 zlib-devel 1.2.11-1 zlib0 1.2.11-1 Is it possible that the version check in clamav is wrong, but you need to check the config.log for details. Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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
Unable to compile clamav
Hi There. I have compiled and installed the source code for zlib-1.2.11-1.src. When compiling clamav I get the following error. configure: error: The installed zlib version may contain a security bug. Please upgrade to 1.2.2 or later: http://www.zlib.net. You can omit this check with --disable-zlib-vcheck but DO NOT REPORT any stability issues then! *** ERROR: configure failed What am i doing wrong in compiling clamav? Yours Sincerely Stephen Brown -- 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
vim yellow lines problem
I had a C program which I copy pasted and there were line numbers in code. So I replaced line numbers in vi by following command :%s/\d*. (<-- last of * is a dot) Now I am opening vim in cygwin then all typed lines are coming yellow. https://i.stack.imgur.com/Dxd8h.jpg How do I fix this problem, 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: Fun with cp -R error when both foo and foo.exe exist
Am 08.10.2018 um 23:24 schrieb Dan Kegel: A nice workaround might be for the cygwin version of cp could arrange to wait to create .exe files until after any potential non-suffixed file has been processed... not sure how easy that would be. Apologies if this has already been discussed. - Dan it is not cp handling the magic, but the cygwin dll. Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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
