Re: Help Me Plase
Your previous message implies that you are not using an up-to-date version of cygwin, so we probably can't help you with that. Additionally, there seems to be a language barrier problem here. Ask a friend to translate. On 26/04/2019 20:26, Sancar kırkpınar wrote: > rar file has put the password and the Turkish character error gives if I > save you if I want to pay > > Unicode: ortak\MUHASEBE\KASA\2013 KASA\HAZ▒RAN\29 HAZ▒RAN.xlsx > > -- > 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: Report
Had you pasted the message like a normal human being, you would have a reply by now since there's a bot for that. And an faq entry: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings And you could just throw the whole thing into google and it'll probably lead you to the faq entry On 28/03/2019 19:34, Jirka wrote: > Screen: https://ctrlv.cz/Kdic > -- > 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: [ANNOUNCEMENT] Updated: mintty 2.9.9
On 27/03/2019 23:59, Yaakov Selkowitz wrote: > On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote: >> I used to use tar rather than cygport package to generate the packages. >> One reason was that I didn’t want my local user/group to appear in them. > They won't show up like that once installed. Sorry for commenting from the peanut gallery, but his problem may be that he doesn't want to disclose his user name to anyone nosy enough to snoop around in the package files. -- 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: hey
https://github.com/hbatmit/ns2.35 I'm guessing it's this? GitHub says it was last updated 6 years ago and the readme suggests it was hosted on a CVS back in 2000 Seriously old stuff. I'm sure they will handle his request promptly :) On 02/02/2019 10:02, Marco Atzeri wrote: > Am 02.02.2019 um 09:26 schrieb Mesfin Amezene: >> i install ns2.35 windows version but happen bash problem that is >> couldn`t >> compute FAST_cwd pointer >> what i do to solve this problems >> > > https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings > > update cygwin or ask whoever is distributing ns2.35 to update > the cygwin1.dll > > nothing we can do from our side as we are not involved in > "ns" distribution > > 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 > > -- 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: windows exit codes truncated to 1 Byte
Am 31.03.2016 um 15:01 schrieb Cristian: > I noted that exit codes returned by CMD and other apps (msiexec) are > truncated to 1 byte (0 .. 255). > > Steps to reproduce: > > 1) Create a batch with this content: > $ cat ./test.bat > @echo off > rem > echo Test exit code 266 > exit /B 266 > rem > > 2) run the batch file: > $ ./test.bat > Test exit code 266 > > 3) check exit code > $ echo $? > 10 > > > I would expect 266 but I got 10 instead. I checked for other codes and the > result is the same. > Windows exit codes are represented using 32 bits, so is this limitation > intentional? POSIX specifies that the lower 8 bits of the exit status be made available to the caller of wait/waitpid: http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html "WEXITSTATUS(stat_val) - If the value of WIFEXITED(stat_val) is non-zero, this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main()." Maybe there's another way to get the entire status value, but this looks like a POSIX limitation to me. Cygwin is conformant here. The more interesting problem is what happens if you do "exit /B 256" in your batch. In that case, bash would show a return status of zero. That's what the WIFEXITED macro is used for. Not sure how you'd get that from bash, though. > > > Best regards, > Cristi > > -- > 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
ctrl-c doesn't reliably kill applications
I couldn't replicate it either, but the question I started this thread with is unrelated to either of the ping tools. Here it is again: The ctrl-c shortcut doesn't reliably kill applications (anymore?). It has been that way for at least a year now. One example is the ruby "rerun" tool (at least when used with a sinatra app). The problem can be reproduced using these steps: 1. Default cygwin install 2. Install rubygems package 3. gem install rerun sinatra 4. Make sure the rerun tool is in PATH (or specify the path to it explicitly). I think rubygems installs executables from gems to ~/bin by default 5. rerun "ruby -e 'require(\"sinatra\")'" 6. ctrl-c 7. tasklist /fi "IMAGENAME eq ruby.exe" * Expected: No process * Actual: process is still running You might have to repeat steps 5 to 7 a few times for the issue to occur. Another problem is that Q sometimes doesn't exit rerun but only the app running inside, but that might be a problem with rerun itself or with the shutdown detection they use. Another example is Vagrant. Although that is not a cygwin application, I usually recommend coworkers to use it with cygwin, because it benefits from mintty's better console. The problem there occurs when you invoke a long-running vagrant command (vagrant provision, for instance) and then cancel it with ctrl-c. If you do that, you're back at the bash prompt, but the provisioning run still goes on and spams the console, making it unusable. Under Kubuntu Linux 14.04/kde/konsole/bash, neither of these problems exist. What the two examples seem to have in common is that they're both one application invoking another: * rerun invokes sh -c "$1" (I think) * vagrant provision invokes (its bundled?) ssh I think this is a bug and should be fixed. Is the bug with Cygwin or should I report it elsewhere? - Björn Stabel aka. TomyLobo Am 16.03.2016 um 14:24 schrieb Marco Atzeri: > > > On 15/03/2016 01:45, Frank Farance wrote: >> I have been having this problem with "ping". If I "ping" a location >> that doesn't exist, then "ping" just hangs and cannot be killed via >> "kill -KILL [pid]". >> >> >> Back to the problem, so when I type >> >> $ ping some.unknown.host >> > > I do not succeed to replicate. > CTRL-C works fine for me > > $ type ping > ping is hashed (/usr/bin/ping) > > $ ping 172.21.1.254 > PING 172.21.1.254 (172.21.1.254): 56 data bytes > > 172.21.1.254 PING Statistics > 4 packets transmitted, 0 packets received, 100.0% packet loss > > or I have not a biased DNS answer. > >> according to "ping", the hostname resolves to 90.242.140.21 (as per the >> explanation above), but I cannot kill "ping". I tried "ping" with a >> limited packet size and count so, in theory, "ping" would die on its own >> after 10 packets, such as: >> >> $ ping some.unknown.host 50 10 >> >> but it still hangs rather than timing out. If I ping to some actual IP >> address that is unresponsive (route-able to the last subnet, but dies on >> the floor at the end), then I can kill via ctrl-c. My only solution to >> the hanging "ping" is to kill the terminal window. >> >> Any suggestions on: >> >> - Why "ping" behaves this way? >> - How to avoid this problem? >> >> Thanks, in advance. > > cygwin ping is based on very old source from a time where people was not > cheating on protocol answer. > > http://ftp.arl.mil/mike/ping.html > (the author passed away 16 years ago..) > > can you send me a strace to see where the program is stacking ? > No promise to find a solution but I will look on it. > > 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 > > -- 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
ctrl-c doesn't reliably kill applications
The ctrl-c shortcut doesn't reliably kill applications (anymore?). It has been that way for at least a year now. One example is the ruby "rerun" tool (at least when used with a sinatra app). The problem can be reproduced using these steps: 1. Default cygwin install 2. Install rubygems package 3. gem install rerun sinatra 4. Make sure the rerun tool is in PATH (or specify the path to it explicitly). I think rubygems installs executables from gems to ~/bin by default 5. rerun "ruby -e 'require(\"sinatra\")'" 6. ctrl-c 7. tasklist /fi "IMAGENAME eq ruby.exe" * Expected: No process * Actual: process is still running You might have to repeat steps 5 to 7 a few times for the issue to occur. Another problem is that Q sometimes doesn't exit rerun but only the app running inside, but that might be a problem with rerun itself or with the shutdown detection they use. Another example is Vagrant. Although that is not a cygwin application, I usually recommend coworkers to use it with cygwin, because it benefits from mintty's better console. The problem there occurs when you invoke a long-running vagrant command (vagrant provision, for instance) and then cancel it with ctrl-c. If you do that, you're back at the bash prompt, but the provisioning run still goes on and spams the console, making it unusable. Under Kubuntu Linux 14.04/kde/konsole/bash, neither of these problems exist. What the two examples seem to have in common is that they're both one application invoking another: * rerun invokes sh -c "$1" (I think) * vagrant provision invokes (its bundled?) ssh I think this is a bug and should be fixed. Is the bug with Cygwin or should I report it elsewhere? - Björn Stabel aka. TomyLobo -- 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
