Re: Signature files missing
I found them missing too, eg: https://mirrors.sonic.net/cygwin/x86_64/ Did they all lose the signature files because the upstream server lost them? On 3/8/24 16:32, dave--- via Cygwin wrote: .sig files seem to have gone missing from (at least some) mirrors. e.g. https://mirrors.kernel.org/sourceware/cygwin/x86_64 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Previously-functional Octave software routine now mysteriously failing - Please help!
Hello. I just tried performing a correlation matrix calculation with Cygwin's Octave software (having successfully performed this calculation previously on other similar data sets) using the following commands within Cygwin: *(start of commands)* [vansc@LAPTOP-OHN2RCVM ~/PKG_domB_CHESCA_analysis_-_apo-cG-cA-RpcG-RpcA_4_Rp-ligs_manu_-_Jul_2023]$ octave GNU Octave, version 5.2.0 Copyright (C) 2020 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type 'warranty'. Octave was configured for "x86_64-pc-cygwin". Additional information about Octave is available at https://www.octave.org. Please contribute if you find this software useful. For more information, visit https://www.octave.org/get-involved.html Read https://www.octave.org/bugs.html to learn how to submit bug reports. For information about changes from previous versions, type 'news'. octave:1> load dm octave:2> cdmt = cor(dm.') octave:3> save dm.octave *(end of commands)* However, when I tried executing the "cdmt = cor(dm.')" command, I got the following error message: octave:2> cdmt = cor(dm.') error: 'cor' undefined near line 1 column 8 octave:2> For reference, I have attached a copy of the input "dm" matrix data file that I was trying to use in the calculations within Octave (see attached file). Do you have any idea what is going on here, and if there is a way to fix it (or work around it)?? dm Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
mintty 3.5.1-1: -p center no longer works
mintty 3.5.1-1: -p center no longer works. Reverted to 3.5.0, which is fine.: -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Error encountered in Octave software - Please help!!
Hello. I just tried performing an analysis in the Octave software (GNU Octave, version 5.2.0), using the attached "dm" input file, and the following commands: load dm cdmt = cor(dm.') However, I encountered the following error message: error: 'cor' undefined near line 1 column 8 What is going on here?? dm Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Previously-functional gawk script now failing to execute - PLEASE HELP!!!
Hello. I just tried executing an old, previously-functional awk script using a version of gawk that I had downloaded last year, and a command of the following format (as recommended in a previous communication with the Cygwin mailing list): gawk -vRS="\r\n" -f data_collect_e_-_FF_4-state.awk but this time, the script failed to execute!! Upon closer examination, the script appears to be failing after successfully reading the first line of data from the input data file, even though the input file has NOT been modified since it was last used. (I should point out that while the files were copied over from my old computer, another awk script execution that I had attempted recently with older files worked fine!) (For reference, I have attached copies of the script and input files.) What the heck is going on with this software, and is there a way to fix it?! 224 0.595851431 0.09369783 225 0.889062608 0.033480286 226 0.835640914 0.024667245 228 0.926425963 0.100830335 229 1.647598528 0.053075286 230 1.342667163 0.049740591 231 1.23487811 0.303661798 232 0.918372444 0.201229278 233 1.073620187 0.038863171 234 1.282736478 0.092083566 237 1.198194998 0.061451225 238 1.517388582 0.183405758 239 0.777250185 0.042951855 240 1.442106405 0.071534566 242 1.127683833 0.180393161 243 0.75826546 0.10362625 244 0.806582369 0.053810549 245 0.782472863 0.089712654 246 0.7665594 0.063004719 247 1.133027476 0.116433654 248 0.228653463 0.054674445 250 1.03832007 0.057555951 251 0.207643515 0.045497989 252 0.89097942 0.065711892 253 1.382205043 0.041019712 254 1.624161735 0.097996896 255 0.102011133 0.017824426 257 0.243916847 0.030898216 258 1.401842211 0.167043419 259 1.367403732 0.089365097 260 1.011543148 0.241393784 261 0.331122492 0.084430871 262 1.247481409 0.012064997 263 0.164144595 0.015874666 264 0.29124209 0.023159954 265 1.155980147 0.007664518 267 1.327231572 0.088667225 269 1.630417096 0.091432252 272 0.837876582 0.088357396 276 0.126347248 0.021352854 278 0.281248041 0.04460507 279 1.507370692 0.055864662 280 0.099307529 0.023337928 282 0.078283134 0.015679097 285 1.396978738 0.041014414 286 1.639489181 0.021233884 287 1.358795349 0.166693354 290 1.034468946 0.071941536 291 1.042912979 0.161347016 292 1.243638613 0.186114384 294 1.465291389 0.080129079 295 1.498983157 0.261019123 297 1.020960822 0.039127181 298 1.014076358 0.055905146 299 0.10474365 0.025701761 300 1.164509327 0.06490821 301 1.581053193 0.117554464 302 1.198070393 0.279390802 304 1.030638676 0.098787267 306 1.892887325 0.148397402 307 1.180718504 0.269259715 308 1.250687158 0.220505404 309 1.389652687 0.061317639 310 1.071337559 0.071155291 311 0.655741784 0.083834781 312 0.757954775 0.06606795 315 1.861485087 0.302438971 316 1.543650517 0.131453064 317 0.590790541 0.17252546 318 1.360237347 0.017090096 319 0.092471202 0.03160355 322 0.160293668 0.018528699 323 1.498177719 0.063140897 324 1.33747325 0.077138118 325 1.135054625 0.14033561 326 0.106286087 0.010054509 327 0.172350731 0.062090642 332 1.599736857 0.07364121 333 0.719466407 0.104815196 334 0.95050495 0.042289463 335 0.950136142 0.102065088 337 0.930073299 0.164582827 338 0.931813131 0.083700864 339 0.797003512 0.019929439 340 0.948011214 0.025551098 341 1.158923159 0.115968704 342 1.151928768 0.090588751 343 1.558238511 0.070125811 345 1.78478822 0.203931487 346 1.184805052 0.015907815 347 0.918694163 0.016359047 348 0.334625526 0.081083201 349 1.330240541 0.108204132 350 1.23117168 0.128820577 353 0.822391221 0.060853522 354 0.84578441 0.133596858 data_collect_e_-_FF_4-state.awk Description: Binary data 224 0.509749968 0.177160603 225 0.558302662 0.133600275 226 0.691840552 0.051067741 227 1.233597604 0.283456681 228 0.421856797 0.148593149 229 0.718569048 0.172281526 230 0.873414173 0.141360943 232 0.814583694 0.116116109 233 0.545530204 0.10546754 234 0.99700609 0.169893273 237 1.147039778 0.248435675 238 1.212524735 0.136625425 239 0.815957312 0.154361412 240 1.002183096 0.097622672 242 0.685532137 0.195614404 243 0.690542903 0.177536237 244 1.067802596 0.299976054 245 0.611368407 0.087569393 246 1.294782866 0.320160689 247 1.355992615 0.162978753 249 0.992940868 0.202092716 250 0.837372727 0.104691616 251 0.545193505 0.129523309 252 0.751120079 0.141558128 258 1.596453745 0.293675409 259 0.790301838 0.126762602 260 0.968986106 0.098652785 261 0.842054028 0.073642471 262 1.152477734 0.101408622 265 1.139992142 0.098671518 266 1.338325639 0.216312478 267 1.463659157 0.236418172 268 0.927751272 0.123255266 270 0.86399925 0.138745433 272 0.520219938 0.170853123 278 0.704652944 0.09522493 279 1.890656381 0.499643642 280 0.398963117 0.118476991 284 0.122517329 0.049364492 285 1.134970966 0.106429413 286 1.176698565 0.201348106 287 1.07703454 0.157882271 288 0.969053608 0.147946755 290 0.634496025 0.186587724 291 0.990315215 0.116076617 294 1.315796916 0.222188321 295 1.241466428 0.161521586 296 1.060798921 0.087565525 297 1.331018926 0.110648457 298 1.213718667 0.335101144 300 1.0742
Previously-functional gawk script now failing to execute - PLEASE HELP!!!
Hello. I just tried executing an old, previously-functional awk script using a version of gawk that I had downloaded last year, and a command of the following format (as recommended in a previous communication with the Cygwin mailing list): gawk -vRS="\r\n" -f data_collect_e_-_FF_4-state.awk but this time, the script failed to execute!! Upon closer examination, the script appears to be failing after successfully reading the first line of data from the input data file, even though the input file has NOT been modified since it was last used. (I should point out that while the files were copied over from my old computer, another awk script execution that I had attempted recently with older files worked fine!) WHAT THE HECK IS GOING ON WITH THIS SOFTWARE?! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Problem with output from gawk software in recent Cygwin installation
Just out of curiosity: Could this "" issue be something new for Windows 10? I ask because I don't recall having this issue with my old Windows 7 computer. Bryan On Tue, Jul 28, 2020 at 12:06 AM Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > On 2020-07-27 15:58, Bryan VanSchouwen wrote: > > On Mon, Jul 27, 2020 at 4:20 PM Brian Inglis wrote: > >> On 2020-07-27 11:50, Michel LaBarre wrote: > >>> On July 27, 2020 12:52 PM, Eliot Moss wrote: > >>>> On 7/27/2020 11:47 AM, Bryan VanSchouwen wrote: > >>>>> I just tried executing an awk script using the most recent version > >>>>> of gawk, but the output did not turn out the way that it was supposed > >>>>> to. > >>>>> This script uses the following command to print the output data to > >>>>> the output file: > >>>>> print(cai[i], rpi[i], i) > > >>>>> "Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat" > >>>>> and previously, this command always printed the values of the three > >>>>> variables on a single line, separated by spaces; however, now the > >>>>> gawk software is automatically adding hard-returns between the > >>>>> values, resulting in the three values being printed on separate lines > >>>>> within the data file. > >>>>> What is going on here, and how do I permanently make it stop?? > > >>> Here's a wondering: Could it have to do with line endings? If Windows > >>> CRLF is getting in there, then the variables might get a CR in them, > >>> which might do weird things. This assumes those are string variables, > >>> not numeric. > > >> Better yet, how about an example using manifest constants in a one line > >> sample to eliminate impact of arrays or changes in input data as in: > gawk > >> 'BEGIN {print(1,2,3)}' or gawk 'BEGIN {print(1,2,3) > "xxx.txt"}'> > > No problem with awk or gawk: > > $ for ((i = 0; i < 10; ++i)) > > do > > printf "%d %d %d %d\n" $((i+1)) $((i+2)) $((i+3)) $((i+4)) > > done > test.txt > > $ awk '{print($1, $2, $3)}' test.txt > > 1 2 3 > > 2 3 4 > > 3 4 5 > > 4 5 6 > > 5 6 7 > > 6 7 8 > > 7 8 9 > > 8 9 10 > > 9 10 11 > > 10 11 12 > > So the issue appears to be with your command line, script, or input data > > file: please show the command line used to execute the script, attach > the > > complete awk script, and input data file for diagnosis, or selections of > the > > latter piped through or output using cat -A to show control characters. > > Here they are (attached). The script was executed with the following > > command:> gawk -f peak_intensity_correln_plot_compile.awk > Input files have \r\n line terminators and those > are > carried thru at the ends of the string fields: > > $ gawk -f peak_intensity_correln_plot_compile.awk > $ file *cPuMP*.dat > 2NH2-cPuMP_nh_-_pk_Fit_Height_data.dat:ASCII text, with CRLF > line > terminators > cPuMP_nh_-_pk_Fit_Height_data.dat: ASCII text, with CRLF > line > terminators > Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat: ASCII text, with CR, LF > line > terminators > $ cat -A Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat | head > 1571697^M 1716833^M 224$ > 2672863^M 2894992^M 225$ > 2184902^M 9710015^M 226$ > 4393362^M 4095908^M 227$ > 3828609^M 4218978^M 229$ > 6285045^M 4008320^M 233$ > 3936959^M 4104667^M 234$ > 1698322^M 1942553^M 237$ > 4144791^M 4346435^M 238$ > 2546328^M 2804338^M 239$ > > You could change your input line terminators to "\r\n" e.g. option > -vRS="\r\n", > insert '{ sub( /\r$/, ""); before each 'split(x, s, " ")', convert your > input > fields from strings to numbers by adding zero i.e. cai[i] += 0; rpi[i] += > 0; or > use belts, braces, and suspenders with all three, e.g. > > $ gawk -vRS="\r\n" -f peak_intensity_correln_plot_compile.awk > $ file *cPuMP*.dat > 2NH2-cPuMP_nh_-_pk_Fit_Height_data.dat:ASCII text, with CRLF > line > terminators > cPuMP_nh_-_pk_Fit_Height_data.dat: ASCII text, with CRLF > line > terminators > Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat: ASCII text > $ cat -A Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat | head > 1571697 1716833 224$ > 2672863 2894992 225$ > 2184902 9710015 226$ > 4393362 4095908 227$
Problem with output from gawk software in recent Cygwin installation
Hello. I just tried executing an awk script using the most recent version of gawk, but the output did not turn out the way that it was supposed to. This script uses the following command to print the output data to the output file: print(cai[i], rpi[i], i) > "Fit_Height_correln_plot_-_cPuMP_vs_2NH2-cPuMP.dat" and previously, this command always printed the values of the three variables on a single line, separated by spaces; however, now the gawk software is automatically adding hard-returns between the values, resulting in the three values being printed on separate lines within the data file. What is going on here, and how do I permanently make it stop?? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Problem with "xmgrace" graphing software in recent Cygwin installation
Hello. I recently installed a copy of the Cygwin software package on my new Windows 10 laptop. However, whenever I try to access the "xmgrace" graphing software (by entering the command "xmgrace &" in the xterm command shell, as I did on my old Windows 7 laptop), I get the following error message: [vansc@LAPTOP-OHN2RCVM ~]$ xmgrace & [1] 1183 [vansc@LAPTOP-OHN2RCVM ~]$ --> Broken or incomplete installation - read the FAQ! [1]Exit 1xmgrace [vansc@LAPTOP-OHN2RCVM ~]$ I tried reading the FAQ, but it was unhelpful for this particular issue. Does anyone have any ideas about why this might be happening?? Also, if it is an incomplete installation, then does anyone know what set of Cygwin utilities I need to install to obtain a fully-functioning copy of the "xmgrace" graphing software? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: setup (2.898)
On Wed, Jan 1, 2020 at 11:22 AM Jon Turney wrote: > > > I've built setup with a patch which attempts to address this: > > https://cygwin.com/setup/setup-2.899.x86_64.exe > https://cygwin.com/setup/setup-2.899.x86.exe > > Perhaps you could try that and see if it improves things for you? Yes, it appears to be working as expected with this new build. 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: [ANNOUNCEMENT] Updated: setup (2.898)
On Sat, Dec 28, 2019 at 8:40 AM Jon Turney wrote: > > > A new version of Setup (2.898) has been uploaded to: > >https://cygwin.com/setup-x86_64.exe (64 bit version) >https://cygwin.com/setup-x86.exe (32 bit version) Something definitely busted in this version for me. I've been using the same command line to download an offline, partial mirror for more than 5 years: setup-x86_64.exe --disable-buggy-antivirus --download --no-desktop --root "%CD%\Temp" --quiet-mode --categories All --remove-categories Debug --local-package-dir "%CD%" --site "%MIRROR%" On a clean directory structure, this now stops executing without downloading anything: Starting cygwin install, version 2.898 User has backup/restore rights io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory Current Directory: V:\Installers\Cygwin\x64 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. Selected local directory: V:\Installers\Cygwin\x64 net: Preconfig site: http://mirrors.koehn.com/cygwin/cygwin-ftp/ HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst.sig HTTP status 404 fetching http://mirrors.koehn.com/cygwin/cygwin-ftp/x86_64/setup.zst io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or directory solving: 11308 tasks, update: no, use test packages: no -- 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 Report: Regression in Cygwin 2.11.0-1
> As for the bug in question: I pushed a patch which should fix this > issue. I created new developer snapshots and uploaded them to > https://cygwin.com/snapshots/. Please give them a try. Thank you Corinna for the quick fix and investigation! I set up an environment to test it out: https://github.com/bryphe/test-ocaml-build and ran a build against the patched dll. It looks like the patch fixes our scenario - the build is green with the patched dll: https://ci.appveyor.com/project/bryphe/test-ocaml-build, so the patch fixes our problem. > On the other hand, those that will find problems, the people building packages, will only do that on "official" releases. I'm pretty new to the Cygwin ecosystem - we could certainly create nightly builds that test against cygwin releases, if that helps (and adjust our CLI script to grab the nightly / latest test release of Cygwin). I wonder if, for a change like this, we could add a test case that exercises it - looking through the source, it looks like cygload.cc has a few test cases around pathing - perhaps it would be helpful to add a regression test for the minimal repro? Thanks again for the help and investigation! Bryan -- 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
Bug Report: Regression in Cygwin 2.11.0-1
Hello, Thank you for all the work on Cygwin! I've been using it to spin up an environment to build the OCaml compiler / toolchain, and it was working great. However, today, all our CI builds mysteriously started failing - at first, I suspected it was a problem with AppVeyor, but I also failures with VSTS. We use an NPM package (`esy-bash`) to spin up a Cygwin environment, and then use that to build the OCaml toolchain. The error message we started receiving today is: OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe" ../byterun/ocamlrun ../ocamlc -g -nostdlib -I ../utils -I ../parsing -I ../stdlib -I ../compilerlibs -strict-sequence -safe-string -strict-formats -w +a-4-9-41-42-44-45-48 -warn-error A -custom ocamlcommon.cma -o ocamltest.exe run_win32.o run_stubs.o ocamltest_config.cmo testlib.cmo run_command.cmo filetype.cmo filecompare.cmo backends.cmo variables.cmo environments.cmo builtin_variables.cmo builtin_modifiers.cmo actions.cmo builtin_actions.cmo tests.cmo builtin_tests.cmo tsl_ast.cmo tsl_parser.cmo tsl_lexer.cmo tsl_semantics.cmo options.cmo main.cmo x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file or directory The complete build log is here: https://gist.github.com/bryphe/58603ab752ecd988f78ee383fa9c9e78 After some investigation, I was able to isolate the issue - environments with the 2.10.0-1 version of Cygwin built successfully, whereas newer environments with the 2.11.0-1 version exhibit this failure. The remaining packages are in parity - importantly, all the mingw packages we install are at the same version. Results of cygcheck -c on both environments: - Working environment: https://gist.github.com/bryphe/b11f72f60d9d7c04a8e709e6a8eb20ff - Failing environment: https://gist.github.com/bryphe/7cf4e6216030781eb273ac45d36590cd I'll continue to look around for a more minimal repro, but I suspect there may be other manifestations of it. It looks like there were a few path-related patches that came in to 2.11.0-1, so perhaps this scenario was impacted. In the meantime - is there a way we can pin the cygwin package to the 2.10.0-1 version, to unblock our builds? Thank you! Bryan Sent from Outlook<http://aka.ms/weboutlook> -- 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 stopped working
I have been following this thread closely as I have a similar problem. It only differs in that mintty, which I use to start bash, fails completely. It tells me that it cannot fork, that the problem could be that I have more than 1 cygwin1.dll, that I should run rebaseall or rebase --help. Unfortunately all cygwin processes have the same problem. Even a fresh, clean re-installation of all of cygwin left me with the same problem. On Mon, Feb 12, 2018 at 10:58 PM, Andreas Schiffler wrote: > Found the workaround (read: not really a solution as it leaves the system > vulnerable, but it unblocks cygwin) > - Go to Windows Defender Security Center - Exploit protection settings > - Disable System Settings - Force randomization for images (Mandatory > ASLR) and Randomize memory allocations (Bottom-up ASLR) from "On by > default" to "Off by default" > > Now setup.exe works and can rebase everything; after that Cygwin Terminal > starts as a working shell without problems. > > @cygwin dev's - It seems one of the windows updates (system is on 1709 > build 16299.214) might have changed my ASLR settings to "system wide > mandatory" (i.e. see https://blogs.technet.microsof > t.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/ for info) > so that the cygwin DLLs don't work correctly anymore (i.e. see old thread > about this topic here https://www.cygwin.com/ml/cygw > in/2013-06/msg00092.html). This change might have made it into the system > as part of the security update for Meltdown+Spectre (I am speculating), but > that could explain why my cygwin installation that worked fine before (i.e. > mid-2017) stopped working suddenly (beginning 2018). It would be good to > device a test for the setup.exe that checks the registry (likely > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session > Manager\kernel]) for this state and alerts the user. > @jostein - rebase as part of setup.exe had failed as well (see above). > @Achim - that didn't work or do anything (see above). > > > On 2/12/2018 8:49 AM, Jostein Berntsen wrote: > >> On 11.02.18,17:16, Andreas Schiffler wrote: >> >>> Thanks for the tip, but that didn't seem to have helped. >>> >>> The registry setting CYGWIN_NOWINPATH=1 did not seem to affect the >>> environment as seen in bash. >>> >>> The variable seems to be set: >>> >>> bash-4.4$ set >>> ...snip... >>> COMSPEC='C:\WINDOWS\system32\cmd.exe' >>> CYGWIN_NOWINPATH=1 >>> ...snip >>> >>> but the path variable contains still all the common system locations: >>> >>> bash-4.4$ echo $PATH >>> /cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files >>> (x86)/iis express/PHP/v5.3:/cygdrive/c/Program Files/Common Files/Mic >>> rosoft Shared/Windows Live:/cygdrive/c/Program Files (x86)/Common >>> Files/Microsoft Shared/Windows Live:/cygdrive/c/Program Files >>> (x86)/Intel/ >>> iCLS Client:/cygdrive/c/Program Files/Intel/iCLS >>> Client:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:...snip... >>> >>> Manually overriding the PATH variable in bash did not help (presumably >>> because the offending DLL is already loaded): >>> >>> bash-4.4$ export PATH=/usr/local/bin:/usr/bin:/bin >>> bash-4.4$ echo $PATH >>> /usr/local/bin:/usr/bin:/bin >>> bash-4.4$ >>> bash-4.4$ >>> bash-4.4$ ls >>>0 [main] bash (11276) C:\Cygwin\bin\bash.exe: *** fatal error - >>> cygheap base mismatch detected - 0x3C52410/0x36F2410. >>> This problem is probably due to using incompatible versions of the cygwin >>> DLL. >>> Search for cygwin1.dll using the Windows Start->Find/Search facility >>> and delete all but the most recent version. The most recent version >>> *should* >>> reside in x:\cygwin\bin, where 'x' is the drive on which you have >>> installed the cygwin distribution. Rebooting is also suggested if you >>> are unable to find another cygwin DLL. >>> >>> >>> On 2/11/2018 2:42 AM, Doug Henderson wrote: >>> On 11 February 2018 at 01:18, Andreas Schiffler wrote: > Terminal (bash) fails with: > > Error: Could not fork child process: Resource temporarily unavailable > (-1). > DLL rebasing may be required; see 'rebaseall / rebase --help'. > > {snip} > bash-4.4$ ls > 1 [main] bash (6316) C:\Cygwin\bin\bash.exe: *** fatal error - > cygheap > base mismatch detected - 0x3922410/0x3962410. > This problem is probably due to using incompatible versions of the > cygwin > DLL. > {snip} > I do have another version of the cygwin dll file on the system (Plex > installation) but that never caused any issues in the past. > {snip} Run setup.exe for Cugwin once again and let it rebase. Then reboot and >> see if that works. >> >> Jostein >> >> >> >> -- >> 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 r
How to repeat a bash shell script until success
I have a shell script, originally created for Mac OS X. that waits for an external drive to be mounted (by testing an “ls” of the volume’s root directory for success) then runs an “rsync” command. How do I get the script to be run repeatedly until successful exit under Cygwin? Here is the unmodified Mac OS version of the script: #!/bin/bash if ls /Volumes/Shared >/dev/null 2>/dev/null then rsync -avz --compress-level=9 --delete-during --partial --exclude 'cache/' aleph.gutenberg.org::gutenberg /Volumes/Shared/Project-Gutenberg exit 0 else exit 1 fi -- 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: xterm 327-1 to 329-1 needs font dependency
On 06/21/2017 01:22 AM, Thomas Dickey wrote: > - Original Message - > | From: "Bryan Dongray" > | To: cygwin@cygwin.com > | Sent: Tuesday, June 20, 2017 6:52:38 PM > | Subject: xterm 327-1 to 329-1 needs font dependency > | > | On an upgrade of xterm from 327-1 to 329-1 starting an xterm now > | complains: > | $ xterm > | /usr/bin/xterm: cannot load font > | "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-60-ISO8859-1" > | /usr/bin/xterm: cannot load font > | "-Misc-Fixed-medium-R-*-*-10-100-75-75-C-120-ISO10646-1" > | /usr/bin/xterm: cannot load font > | "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-120-ISO10646-1" > | > | When I downgrade to 327-1 these messages do not show, so I assume the > | latest version requires specific fonts. > | > | I installed all the X11 fonts which were described as "core font" > | (surprisingly a reinstall of "xinit" did not install these), > | but still I get the above messages. However I assume xterm falls back > | on > | some other font, as everything displays ok (as far as I checked). > | > | Q1. Can someone point me at which font I need to install to not get > | these > | warnings (I tried a few, but no luck, and there are hundreds to > | try)? > | > | Q2. Shouldn't these fonts be a dependency of xterm? > > see > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219800 Thank you for replying but I'm unsure how that discussion answers my question? It is related, but looks like they are talking about the width of bold fonts causing an issue with zsh and vim (and others), not about xterm complaining about missing fonts when it starts up. My issue is not about bold fonts causing an issue, maybe they do. I get complaints when starting xterm that it needs a font(s). So what font package do I need to install to stop these complaints? However, maybe I missed it (in the above bugs freebsd org discussion) on which font I need to install, because there is so much discussion about zsh, vim, bold widths, etc. So if anyone can point out the comment there which tells me that, that'd be great, or just tell me directly the name of the font package I need to download - thanks. I guess I could be super-lazy and install EVERY font, but that sounds like just a brute force solution, and I might miss it anyway since not all fonts seems to have the word "font" in the package name. But suppose I do install the font is needed, this leads onto my second question that surely required fonts for xterm should be set as dependencies for xterm. Yes? So is that something that should be in the cygwin setup configuration? -- 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
xterm 327-1 to 329-1 needs font dependency
On an upgrade of xterm from 327-1 to 329-1 starting an xterm now complains: $ xterm /usr/bin/xterm: cannot load font "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-60-ISO8859-1" /usr/bin/xterm: cannot load font "-Misc-Fixed-medium-R-*-*-10-100-75-75-C-120-ISO10646-1" /usr/bin/xterm: cannot load font "-Misc-Fixed-bold-R-*-*-10-100-75-75-C-120-ISO10646-1" When I downgrade to 327-1 these messages do not show, so I assume the latest version requires specific fonts. I installed all the X11 fonts which were described as "core font" (surprisingly a reinstall of "xinit" did not install these), but still I get the above messages. However I assume xterm falls back on some other font, as everything displays ok (as far as I checked). Q1. Can someone point me at which font I need to install to not get these warnings (I tried a few, but no luck, and there are hundreds to try)? Q2. Shouldn't these fonts be a dependency of xterm? -- 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: Repairing permissions after windows reinstall
> In fact I see _two_ raw SIDs when I look at the security tab for any > directory in the old cygwin tree: one has Full control, and the other > just Read & execute. > If everyone else's posts don't get you where you want, I have a recently-written program that can do a search/replace on a SID (or named account) on an entire directory directory (addresses DACL/SACL group SID, owner SID). Message me directly if you're interested. -- 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: Question about tar v1.28
> Could be an accidental regression in my cygwin-specific patches betweenthe > two versions. But I don't normally use or test on text-mounts, so > I'll need confirmation that you are indeed experiencing the problem only > For what it's worth, I recently had the similar issues with Cygwin tar on text-mounted volumes in the last year. We had users moving between Cygwin tar and Redhat tar and there were issues extracting the tar files. I instructed them to create a binary mount for tar-related purposes and that addressed the issue. We need to use text-mounts, in general, for other reasons. It would be great if tar could be adjusted to operate properly in these scenarios. -- 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: Question about incorrect System path from cygpath with case-sensitivity enabled
Hi Corinna, Sorry for the delay getting back to you. I tested out the cygpath binary from the latest snapshot and confirmed that it fixes my issue. Thank for you making the change! [~/Downloads/cygwin-inst-20160109]$ cygpath -W -u /C/Windows [~/Downloads/cygwin-inst-20160109]$ cygpath-old -W -u /C/WINDOWS - Bryan > On Jan 7, 2016, at 3:19:38 PM, Corinna Vinschen > wrote: > > On Jan 2 18:33, Andrey Repin wrote: >> Greetings, Bryan Henry! >> >>> I enabled (some time ago, not recently) case sensitivity on my Windows 8.1 >>> system by setting the registry key mentioned in the FAQ here: >>> https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive >> >>> Today, I updated Cygwin and noticed a message about a failed postinstall >>> script at the end. Here's the excerpt from setup.log.full showing >>> /etc/postinstall/base-files-mketc.sh exiting early: >> >>> 2016/01/01 15:45:32 running: C:\cygwin\bin\bash.exe --norc --noprofile >>> "/etc/postinstall/base-files-mketc.sh" >>> Directory /C/WINDOWS/System32/drivers/etc does not exist; exiting >>> If directory name is garbage you need to update your cygwin package >>> 2016/01/01 15:45:32 abnormal exit: exit code=1 >> >>> Since this was an existing installation, that postinstall script failing >>> isn't a big deal since the symlinks that it would normally create already >>> exist, but I wanted to dig into why it's failing in the first place in case >>> it is a symptom of something bigger. Taking a look at that script and trying >>> "/usr/bin/cygpath -S -u" for myself, I see now why it failed: >> >>> [~]$ cygpath -S -u >>> /C/WINDOWS/System32 >>> [~]$ file `cygpath -S -u` >>> /C/WINDOWS/System32: cannot open `/C/WINDOWS/System32' (No such file or >>> directory) >>> [~]$ file /C/Windows/System32 >>> /C/Windows/System32: directory >> >>> I get similar results from "cygpath -W". It seems that cygpath has not >>> picked up on the fact that the directory is really "Windows" and not >>> "WINDOWS", >> >> cygpath uses system calls to return the directories you're asking for. > > ...and those system calls return information which does not honor > case-sensitivity, unfortunately. > >> If a system call return wrong case, cygpath can't do anything to amend it. > > It can and it will, at least if the path is a local path. I just > applied a patch to cygpath to call another OS function to correct the > case of the path returned by GetSystemDirectory and friends. > >> You have to fix your system first, then it will just work. > > This is nonsense. It's not the user's fault that the OS returns paths > without honoring the case. Cygwin tries to support case-sensitivity > (https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive) > and so it makes a lot of sense if cygpath tries to return system paths > using the correct case. > > I just uploaded new developer snapshots to https://cygwin.com/snapshots/ > Please give cygpath from those snapshots a try. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- 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
Question about incorrect System path from cygpath with case-sensitivity enabled
I enabled (some time ago, not recently) case sensitivity on my Windows 8.1 system by setting the registry key mentioned in the FAQ here: https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive Today, I updated Cygwin and noticed a message about a failed postinstall script at the end. Here's the excerpt from setup.log.full showing /etc/postinstall/base-files-mketc.sh exiting early: 2016/01/01 15:45:32 running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/base-files-mketc.sh" Directory /C/WINDOWS/System32/drivers/etc does not exist; exiting If directory name is garbage you need to update your cygwin package 2016/01/01 15:45:32 abnormal exit: exit code=1 Since this was an existing installation, that postinstall script failing isn't a big deal since the symlinks that it would normally create already exist, but I wanted to dig into why it's failing in the first place in case it is a symptom of something bigger. Taking a look at that script and trying "/usr/bin/cygpath -S -u" for myself, I see now why it failed: [~]$ cygpath -S -u /C/WINDOWS/System32 [~]$ file `cygpath -S -u` /C/WINDOWS/System32: cannot open `/C/WINDOWS/System32' (No such file or directory) [~]$ file /C/Windows/System32 /C/Windows/System32: directory I get similar results from "cygpath -W". It seems that cygpath has not picked up on the fact that the directory is really "Windows" and not "WINDOWS", which is of course important in my case with case sensitivity enabled. I'm not sure if this is a failure of cygpath directly or perhaps a piece of configuration elsewhere that needs to get updated in addition to the registry key change mentioned in the FAQ. Can anyone offer any recommendations to fix the Windows path returned by cygpath, or is this a bug? Thanks, Bryan Henry cygcheck.out Description: Binary data -- 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: Mintty Crash on Exit after SSH on Windows 10
Hello, I wanted to do one last follow up here. This issue has cleared up on all of my computers. The only environmental change was Windows update. Thus, my conclusion is that this was a Microsoft bug rather than a Mintty / Cygwin one and it has been cleared up with the latest updates. Thanks for the help guys! On Tue, Sep 29, 2015 at 11:21 PM, Bryan Tong wrote: > Sorry for the extra replies. > > I am going to try to do some more research on the issue. After letting > a mintty window sit open and typing absolutely nothing inside it and > then closing it about 5 minutes later it hangs on exit. > > Very strange behavior. Im not seeing it so bad on my other computers > but still intermittent on them. > > On Tue, Sep 29, 2015 at 11:15 PM, Bryan Tong wrote: >> Okay, >> >> The plot thickens. After I renamed my home folder so Cygwin would make >> a new one. The problem seems to be gone. >> >> I will continue to test and see if it comes back. Maybe something in >> my home folder is making it unhappy. >> >> >> On Tue, Sep 29, 2015 at 11:10 PM, Bryan Tong wrote: >>> I wasnt able to get any of the replies however I saw them on the mailing >>> list. >>> >>> First of all, yes the problems continue if I type "exit" into each windows. >>> >>> Also happens if I just press the "X" on the window. >>> >>> Enter, doesnt do anything on the window. I have to either wait about >>> 60 seconds for the window to exit after claiming to not respond or I >>> have to use the task manager to kill it. >>> >>> I am trying the others now and will let you know. >>> >>> What I can tell you is that I just did a fresh install of cygwin >>> 32bit. I install nano, vim, ssh, ping as well was the base package >>> set. >>> >>> The problem continues on that installation as well. >>> >>> On Thu, Sep 17, 2015 at 2:10 AM, Bryan Tong wrote: >>>> Hello, >>>> >>>> I recently upgraded to Windows 10 and ever since I have I am getting a >>>> hang every time I try to exit a Mintty window after using SSH. >>>> >>>> What makes this issue more interesting is that I cant always reproduce >>>> it. It only happens after I have long standing SSH sessions. >>>> >>>> After I press "CTL + a + d" the final time when I am back at the >>>> cygwin login prompt. The window hangs and my cursor disappears when I >>>> try to mouse into the window (this includes the title bar, an exit >>>> buttons). At this point the only option is killing from the task >>>> manager or waiting about a minute until the window dies. >>>> >>>> I am thinking this has to do with unclosed sockets after I have done a >>>> bunch of googling on what might be causing this. >>>> >>>> There is one mailing thread pertaining to a similar issue but it >>>> doesnt match up exactly. >>>> >>>> It definitely started directly after the upgrade to Windows 10. I did >>>> not upgrade cygwin until after I ran into this problem. However the >>>> issue still persists after the upgrade. I believe I am running the >>>> latest versions. >>>> >>>> I have attached my cygcheck to help. >>>> >>>> Best way to reproduce >>>> >>>> 1) Open mintty >>>> 2) ssh to a host >>>> 3) idle on this host for say 5 minutes >>>> 4) press "ctl + a + d" to disconnect from the host >>>> 5) press "ctl + a + d" to disconnect from the Mintty window >>>> >>>> I can almost always reproduce this after working on remote servers. >>>> However when I try to do it on command it happen every time. >>>> >>>> I want to point out that I am also using this SSH option. >>>> >>>> ServerAliveInterval 30 >>>> >>>> I am starting to wonder if maybe that option is causing SSH to keep >>>> the window open as it tries to keep the server alive. It seems that >>>> the 30 second window is close to how long I am seeing these windows >>>> hang open. >>>> >>>> I am not even sure where to look for more debugging. I am more curious >>>> if anyone else is experiencing this? >>>> >>>> Please note that I upgraded my Desktops from Windows 7 -> Windows 10 >>>> and they both see the problem. On the other hand my laptop I upgraded >>>> from Windows 8 -> Windows 10 and it continues to work normally. >>>> >>>> Any help would be appreciated I am stumped on this one. >>>> >>>> Thanks >>>> >>>> -- >>>> eSited LLC >>>> (701) 390-9638 >>> >>> >>> >>> -- >>> eSited LLC >>> (701) 390-9638 >> >> >> >> -- >> eSited LLC >> (701) 390-9638 > > > > -- > eSited LLC > (701) 390-9638 -- eSited LLC (701) 390-9638 -- 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: Mintty Crash on Exit after SSH on Windows 10
Sorry for the extra replies. I am going to try to do some more research on the issue. After letting a mintty window sit open and typing absolutely nothing inside it and then closing it about 5 minutes later it hangs on exit. Very strange behavior. Im not seeing it so bad on my other computers but still intermittent on them. On Tue, Sep 29, 2015 at 11:15 PM, Bryan Tong wrote: > Okay, > > The plot thickens. After I renamed my home folder so Cygwin would make > a new one. The problem seems to be gone. > > I will continue to test and see if it comes back. Maybe something in > my home folder is making it unhappy. > > > On Tue, Sep 29, 2015 at 11:10 PM, Bryan Tong wrote: >> I wasnt able to get any of the replies however I saw them on the mailing >> list. >> >> First of all, yes the problems continue if I type "exit" into each windows. >> >> Also happens if I just press the "X" on the window. >> >> Enter, doesnt do anything on the window. I have to either wait about >> 60 seconds for the window to exit after claiming to not respond or I >> have to use the task manager to kill it. >> >> I am trying the others now and will let you know. >> >> What I can tell you is that I just did a fresh install of cygwin >> 32bit. I install nano, vim, ssh, ping as well was the base package >> set. >> >> The problem continues on that installation as well. >> >> On Thu, Sep 17, 2015 at 2:10 AM, Bryan Tong wrote: >>> Hello, >>> >>> I recently upgraded to Windows 10 and ever since I have I am getting a >>> hang every time I try to exit a Mintty window after using SSH. >>> >>> What makes this issue more interesting is that I cant always reproduce >>> it. It only happens after I have long standing SSH sessions. >>> >>> After I press "CTL + a + d" the final time when I am back at the >>> cygwin login prompt. The window hangs and my cursor disappears when I >>> try to mouse into the window (this includes the title bar, an exit >>> buttons). At this point the only option is killing from the task >>> manager or waiting about a minute until the window dies. >>> >>> I am thinking this has to do with unclosed sockets after I have done a >>> bunch of googling on what might be causing this. >>> >>> There is one mailing thread pertaining to a similar issue but it >>> doesnt match up exactly. >>> >>> It definitely started directly after the upgrade to Windows 10. I did >>> not upgrade cygwin until after I ran into this problem. However the >>> issue still persists after the upgrade. I believe I am running the >>> latest versions. >>> >>> I have attached my cygcheck to help. >>> >>> Best way to reproduce >>> >>> 1) Open mintty >>> 2) ssh to a host >>> 3) idle on this host for say 5 minutes >>> 4) press "ctl + a + d" to disconnect from the host >>> 5) press "ctl + a + d" to disconnect from the Mintty window >>> >>> I can almost always reproduce this after working on remote servers. >>> However when I try to do it on command it happen every time. >>> >>> I want to point out that I am also using this SSH option. >>> >>> ServerAliveInterval 30 >>> >>> I am starting to wonder if maybe that option is causing SSH to keep >>> the window open as it tries to keep the server alive. It seems that >>> the 30 second window is close to how long I am seeing these windows >>> hang open. >>> >>> I am not even sure where to look for more debugging. I am more curious >>> if anyone else is experiencing this? >>> >>> Please note that I upgraded my Desktops from Windows 7 -> Windows 10 >>> and they both see the problem. On the other hand my laptop I upgraded >>> from Windows 8 -> Windows 10 and it continues to work normally. >>> >>> Any help would be appreciated I am stumped on this one. >>> >>> Thanks >>> >>> -- >>> eSited LLC >>> (701) 390-9638 >> >> >> >> -- >> eSited LLC >> (701) 390-9638 > > > > -- > eSited LLC > (701) 390-9638 -- eSited LLC (701) 390-9638 -- 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: Mintty Crash on Exit after SSH on Windows 10
Okay, The plot thickens. After I renamed my home folder so Cygwin would make a new one. The problem seems to be gone. I will continue to test and see if it comes back. Maybe something in my home folder is making it unhappy. On Tue, Sep 29, 2015 at 11:10 PM, Bryan Tong wrote: > I wasnt able to get any of the replies however I saw them on the mailing list. > > First of all, yes the problems continue if I type "exit" into each windows. > > Also happens if I just press the "X" on the window. > > Enter, doesnt do anything on the window. I have to either wait about > 60 seconds for the window to exit after claiming to not respond or I > have to use the task manager to kill it. > > I am trying the others now and will let you know. > > What I can tell you is that I just did a fresh install of cygwin > 32bit. I install nano, vim, ssh, ping as well was the base package > set. > > The problem continues on that installation as well. > > On Thu, Sep 17, 2015 at 2:10 AM, Bryan Tong wrote: >> Hello, >> >> I recently upgraded to Windows 10 and ever since I have I am getting a >> hang every time I try to exit a Mintty window after using SSH. >> >> What makes this issue more interesting is that I cant always reproduce >> it. It only happens after I have long standing SSH sessions. >> >> After I press "CTL + a + d" the final time when I am back at the >> cygwin login prompt. The window hangs and my cursor disappears when I >> try to mouse into the window (this includes the title bar, an exit >> buttons). At this point the only option is killing from the task >> manager or waiting about a minute until the window dies. >> >> I am thinking this has to do with unclosed sockets after I have done a >> bunch of googling on what might be causing this. >> >> There is one mailing thread pertaining to a similar issue but it >> doesnt match up exactly. >> >> It definitely started directly after the upgrade to Windows 10. I did >> not upgrade cygwin until after I ran into this problem. However the >> issue still persists after the upgrade. I believe I am running the >> latest versions. >> >> I have attached my cygcheck to help. >> >> Best way to reproduce >> >> 1) Open mintty >> 2) ssh to a host >> 3) idle on this host for say 5 minutes >> 4) press "ctl + a + d" to disconnect from the host >> 5) press "ctl + a + d" to disconnect from the Mintty window >> >> I can almost always reproduce this after working on remote servers. >> However when I try to do it on command it happen every time. >> >> I want to point out that I am also using this SSH option. >> >> ServerAliveInterval 30 >> >> I am starting to wonder if maybe that option is causing SSH to keep >> the window open as it tries to keep the server alive. It seems that >> the 30 second window is close to how long I am seeing these windows >> hang open. >> >> I am not even sure where to look for more debugging. I am more curious >> if anyone else is experiencing this? >> >> Please note that I upgraded my Desktops from Windows 7 -> Windows 10 >> and they both see the problem. On the other hand my laptop I upgraded >> from Windows 8 -> Windows 10 and it continues to work normally. >> >> Any help would be appreciated I am stumped on this one. >> >> Thanks >> >> -- >> eSited LLC >> (701) 390-9638 > > > > -- > eSited LLC > (701) 390-9638 -- eSited LLC (701) 390-9638 -- 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: Mintty Crash on Exit after SSH on Windows 10
I wasnt able to get any of the replies however I saw them on the mailing list. First of all, yes the problems continue if I type "exit" into each windows. Also happens if I just press the "X" on the window. Enter, doesnt do anything on the window. I have to either wait about 60 seconds for the window to exit after claiming to not respond or I have to use the task manager to kill it. I am trying the others now and will let you know. What I can tell you is that I just did a fresh install of cygwin 32bit. I install nano, vim, ssh, ping as well was the base package set. The problem continues on that installation as well. On Thu, Sep 17, 2015 at 2:10 AM, Bryan Tong wrote: > Hello, > > I recently upgraded to Windows 10 and ever since I have I am getting a > hang every time I try to exit a Mintty window after using SSH. > > What makes this issue more interesting is that I cant always reproduce > it. It only happens after I have long standing SSH sessions. > > After I press "CTL + a + d" the final time when I am back at the > cygwin login prompt. The window hangs and my cursor disappears when I > try to mouse into the window (this includes the title bar, an exit > buttons). At this point the only option is killing from the task > manager or waiting about a minute until the window dies. > > I am thinking this has to do with unclosed sockets after I have done a > bunch of googling on what might be causing this. > > There is one mailing thread pertaining to a similar issue but it > doesnt match up exactly. > > It definitely started directly after the upgrade to Windows 10. I did > not upgrade cygwin until after I ran into this problem. However the > issue still persists after the upgrade. I believe I am running the > latest versions. > > I have attached my cygcheck to help. > > Best way to reproduce > > 1) Open mintty > 2) ssh to a host > 3) idle on this host for say 5 minutes > 4) press "ctl + a + d" to disconnect from the host > 5) press "ctl + a + d" to disconnect from the Mintty window > > I can almost always reproduce this after working on remote servers. > However when I try to do it on command it happen every time. > > I want to point out that I am also using this SSH option. > > ServerAliveInterval 30 > > I am starting to wonder if maybe that option is causing SSH to keep > the window open as it tries to keep the server alive. It seems that > the 30 second window is close to how long I am seeing these windows > hang open. > > I am not even sure where to look for more debugging. I am more curious > if anyone else is experiencing this? > > Please note that I upgraded my Desktops from Windows 7 -> Windows 10 > and they both see the problem. On the other hand my laptop I upgraded > from Windows 8 -> Windows 10 and it continues to work normally. > > Any help would be appreciated I am stumped on this one. > > Thanks > > -- > eSited LLC > (701) 390-9638 -- eSited LLC (701) 390-9638 -- 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
Mintty Crash on Exit after SSH on Windows 10
Hello, I recently upgraded to Windows 10 and ever since I have I am getting a hang every time I try to exit a Mintty window after using SSH. What makes this issue more interesting is that I cant always reproduce it. It only happens after I have long standing SSH sessions. After I press "CTL + a + d" the final time when I am back at the cygwin login prompt. The window hangs and my cursor disappears when I try to mouse into the window (this includes the title bar, an exit buttons). At this point the only option is killing from the task manager or waiting about a minute until the window dies. I am thinking this has to do with unclosed sockets after I have done a bunch of googling on what might be causing this. There is one mailing thread pertaining to a similar issue but it doesnt match up exactly. It definitely started directly after the upgrade to Windows 10. I did not upgrade cygwin until after I ran into this problem. However the issue still persists after the upgrade. I believe I am running the latest versions. I have attached my cygcheck to help. Best way to reproduce 1) Open mintty 2) ssh to a host 3) idle on this host for say 5 minutes 4) press "ctl + a + d" to disconnect from the host 5) press "ctl + a + d" to disconnect from the Mintty window I can almost always reproduce this after working on remote servers. However when I try to do it on command it happen every time. I want to point out that I am also using this SSH option. ServerAliveInterval 30 I am starting to wonder if maybe that option is causing SSH to keep the window open as it tries to keep the server alive. It seems that the 30 second window is close to how long I am seeing these windows hang open. I am not even sure where to look for more debugging. I am more curious if anyone else is experiencing this? Please note that I upgraded my Desktops from Windows 7 -> Windows 10 and they both see the problem. On the other hand my laptop I upgraded from Windows 8 -> Windows 10 and it continues to work normally. Any help would be appreciated I am stumped on this one. Thanks -- eSited LLC (701) 390-9638 cygcheck.out Description: Binary data -- 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: Restrict active directory logins
On Mon, Aug 31, 2015 at 11:39 PM, E. Winston wrote: > Hi all, > > I am running cygwin 2.2.1(0.289/5/3) and OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul > 2015 on a domain joined Windows 2012 R2 server. I am not using /etc/passwd or > /etc/group and I would prefer not to use theses files as I anticipate a large > number of accounts needing to be configured. As part of our group policy, NT > AUTHORITY\Authenticated Users and NT AUTHORITY\Interactive are both part of > the local Users group. The group policy also places NT > AUTHORITY\Authenticated Users into "Log on Locally" security policy. My > primary purpose is to use this as an SFTP server. I have been able to deny > SSH logins and limit access to on SFTP. > > What I would like to know is with this setup, is if there is a way to prevent > any user in our domain from logging into the server? > > Currently I have directory permissions set so they cannot see anything, but > I'd rather not allow them to login at all. > > I have a local group created with only the domain accounts I want to be able > to explicitly login but thus far I have not been able to determine how to > limit logins to just the members of this group. > > Thanks in advance, > > -Ed > -- > 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 > Ed, I have a similar arrangement. Short of reprogramming Cygwin to *not* do an interactive logon (i.e. do a network logon instead), I think you're out of luck. A network logon would work for what an SFTP server needs to do, but probably isn't right for other purposes such as a full SSH terminal session -- and unfortunately both authentication process goes through the same function in Cygwin. I thought about proposing some configurable setting in Cygwin on the mailing list, but the need is really too nuanced to merit implementation (in my opinion). If the users don't have access to the console, just make sure that you're not also allowing "Allow log on through Remote Desktop Services" -- that should prevent a user from being logged into via Remote Desktop. That said, the problem may actually be worse than you think. If you have roaming profiles enabled, they may be getting synced every time a user logs in via SFTP. If this isn't desired, you'll want to enable user profile cleanup and disable roaming profiles to that system, in general. It'll slow down the login in addition to bloat the profile directory. -- 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] Early Deprecation Notice: Windows XP and Server 2003 support
On Wed, Aug 26, 2015 at 8:23 AM, Andrey Repin wrote: > Greetings, Corinna Vinschen! > >> On Aug 26 12:56, Helmut Karlowski wrote: >>> > > Guess that's better than to stick with the kludges, migration to 10 is >>> > > on the way. >>> > From what I've seen and heard W10, while mostly stable, still coerces >>> > users >>> > towards the software as (an expensive) service model and follows the >>> > dictum >>> > that Microsoft knows more about what you want than you do (default saves >>> > to >>> > microsoft cloud storage, grabs your pictures for background slide show >>> > without asking, etc.). >>> >>> I hope I can customize it to behave like XP (only the goodies of >>> course). > >> http://classicshell.net > > That doesn't solve the hotkeys bound at driver levels, unfortunately. > Half of my keyboard dead now thanks to the move to Win7. > > Anyway, on the topic: All I could ask is to give us a notice when the final > build for XP is available, so that we could prepare own mirrors. If you're passionate about it and you have any programming experience, keyboard filter drivers are quite easy to write. Only annoying thing is you need a signing certificate that is authorized for kernel code signing -- which is only available to companies and some slightly more expensive issuing authorities for individuals. -- 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 run excel via cron
On Tue, Jun 16, 2015 at 9:27 AM, Kertz, Denis (D)** CTR ** wrote: > We need to run some Excel programs via cron and are using vbscript to do > this. We have this running on a WinXP machine but are having trouble running > on a Win7 machine, but we don't think it is a Win7 problem. > > Here's the script to run a simple test excel program: > > Dim xlApp > Dim xlWb > Set xlApp = CreateObject("Excel.application") > xlApp.Visible = True > Set xlWb = xlApp.workbooks.Open("c:\Shared\Prospect\Bin\TestExcel.xls") > xlApp.Quit > Set xlWb = Nothing > Set xlApp = Nothing > What bitness of Excel and Cygwin are you running? CreateObject("Excel.application") will attempt to create a 32-bit instance of Excel when launched through the 32-bit version of wscript.exe or a 64-bit instance of Excel when launched through the 64-bit version of Excel. Which bitness of WScript.exe ends up being run will depend on the bitness of the parent program (which may be different in a command prompt vice Cygwin). Try changing it to run Wscript.exe in SysWow64 instead of System32 (which is subject to automatic redirection) and see if changes the behavior. If you're not running a 64-bit OS, then just ignore everything I said. -- 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: startxwin - xinit unable to connect to X server
On Wed, May 13, 2015 at 2:40 PM, Kunz, Christopher L wrote: > After updating to the latest Cygwin distribution, I can no longer connect to > X server. When I run startxwin (on a fresh Cygwin install), I get the > following errors: > > xinit: giving up > xinit: unable to connect to X server: Connection refused > xinit: server error > > The XWin.#.log looks okay, I think (see attached). I've set DISPLAY to :0.0. > > Thanks. When's the last time you had updated the xinit package? Try launching as startxwin as startxwin -- -listen tcp -- 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] TEST RELEASE: Cygwin 2.0.0-0.8
Did the fix for my Unknown user/group caching make it over from 2.0.0-0.7 (previous change note below)? - Fix a bug in SID handling which may result in broken SID info in passwd/group entries of unknown accounts. -- 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: Running tasklist /m in cygwin hangs
On Wed, Apr 15, 2015 at 1:52 PM, Saurabh T wrote: > Hi, > Running > "tasklist /m file.dll" hangs in Cygwin even though it works perfectly > fine in the cmd window. Is there any reason for this? I am using a > somewhat older cygwin (1.7.25) on a Windows 7 box, and do not want to > upgrade unless newer cygwin doesnt show the problem. Thank you. > -- > 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 > It doesn't hang for me, but it is significantly slower. I'm running the latest development release. Tasklist appears to be WMI heavy. I ran Process Monitor and it appears that when running tasklist /m under bash, WMI is significantly more active. WMI actually opens tzres.dll (Time Zone Resources) about 150,000 times vice a mere 800 times when executing through a standard command prompt. Moreover, WMI really doesn't appear to be doing much of anything with tzres.dll... just open/close/open/close/open/close. Very curious indeed. -- 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] TEST RELEASE: Cygwin 2.0.0-5
On Fri, Apr 17, 2015 at 6:07 AM, Corinna Vinschen wrote: > On Apr 17 10:16, Corinna Vinschen wrote: >> On Apr 16 12:53, Bryan Berns wrote: >> > On Thu, Apr 16, 2015 at 10:17 AM, Jim Reisert AD1C >> > wrote: >> > > I am unable to start Cywin/X X-server 1.17.1 with this version. >> > > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for >> > > the time being. >> > > >> > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch >> > > Tuesday" updates from Microsoft. I don't know if the two are related. >> > > Windows 7 Home Premium, 64-bit >> > > >> > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A >> > > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= >> > > edi=0028C790 >> > > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, >> > > thread main >> > > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B >> > > Stack trace: >> > > Frame Function Args >> > > 0028C608 77C50F8A (, 612D2648, , 612D67B0) >> > > 0028C738 610CDA1F (43FF, , , 80012428) >> > > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) >> > > 0028C7F8 610F629D (0001, , , 75623912) >> > > >> > > -- >> > > Jim Reisert AD1C, , http://www.ad1c.us >> > >> > I've actually had problem building Cygwin (1.7.35 or 2.x source) on >> > Cygwin 2.x using Windows. The make errors out with a "permissions >> > denied" when setting permissions (chmod +x) on config.status in >> > /etc. I was able to produce it on three different, freshly >> > built copies of Windows (no BLODA at all). Only had Cygwin plus the >> > build essentials (gcc, ming, xmlto, diffutils, textinfo, cocom) >> > installed. Only tried with 32-bit. >> > >> > The super wacky thing is that if I rearrange the unrelated contents of >> > the make file that fuels the whole process, the problem goes away. If >> > I "downgrade" the core back to 1.7.35, the problem goes away. It >> > almost seems like there might an uninitialized memory issue in the >> > code path executed in chmod(). I apologize for the lack of debugging >> > on my part, but I just wanted to throw this out there in case a) it >> > could be related to this issue or b) anyone else has seen this. >> >> This is more in line with what Ismail reported in >> https://cygwin.com/ml/cygwin/2015-04/msg00365.html >> >> And I finally managed to reproduce it. It works on the command line and >> only fails during `make' for me. Investigating now... > > I think I found the culprit. I'll uploade a -0.7 test release in > the next hour or so. > > > Thanks for testing, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat On my way to work now and probably will be offline most of the day, but just wanted to let you know that I did a quick rip of the DLL file from cygwin-2.0.0-0.7.tar.xz on the sourceware.org mirror and make / chmod seems happier now. Nice! :-) -- 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] TEST RELEASE: Cygwin 2.0.0-5
On Thu, Apr 16, 2015 at 10:17 AM, Jim Reisert AD1C wrote: > I am unable to start Cywin/X X-server 1.17.1 with this version. > Previous releases of 2.0.0.x were OK. I had to revert to 1.7.35-1 for > the time being. > > Other than updating to 2.0.0.5, I also installed the April 2015 "Patch > Tuesday" updates from Microsoft. I don't know if the two are related. > Windows 7 Home Premium, 64-bit > > Exception: STATUS_ACCESS_VIOLATION at eip=77C50F8A > eax= ebx=612D67B0 ecx=1000 edx=612D2648 esi= edi=0028C790 > ebp=0028C608 esp=0028C604 program=C:\Cygwin\bin\XWin.exe, pid 1660, thread > main > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > Frame Function Args > 0028C608 77C50F8A (, 612D2648, , 612D67B0) > 0028C738 610CDA1F (43FF, , , 80012428) > 0028C7B8 61047198 (, 72483F24, 75604227, 0254) > 0028C7F8 610F629D (0001, , , 75623912) > > -- > Jim Reisert AD1C, , http://www.ad1c.us I've actually had problem building Cygwin (1.7.35 or 2.x source) on Cygwin 2.x using Windows. The make errors out with a "permissions denied" when setting permissions (chmod +x) on config.status in /etc. I was able to produce it on three different, freshly built copies of Windows (no BLODA at all). Only had Cygwin plus the build essentials (gcc, ming, xmlto, diffutils, textinfo, cocom) installed. Only tried with 32-bit. The super wacky thing is that if I rearrange the unrelated contents of the make file that fuels the whole process, the problem goes away. If I "downgrade" the core back to 1.7.35, the problem goes away. It almost seems like there might an uninitialized memory issue in the code path executed in chmod(). I apologize for the lack of debugging on my part, but I just wanted to throw this out there in case a) it could be related to this issue or b) anyone else has seen this. That said, I'm making progress in debugging my "Unknown Group" issue described in another chain; hope to report out on that this weekend when I have a little more time to play. -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Wed, Apr 15, 2015 at 3:29 AM, Corinna Vinschen wrote: > > Not off the top of my head. The mechanism doesn't check for the > content so it should cache the above line the same way as any other. > I'm puzzled about this behaviour myself. > > That requires some debugging but I have other stuff on my plate atm > so it will take a while(*). For the time being, use noacl mounts. > > > Corinna > > (*) Of course, I'd appreciate any other person debugging what happens > in Cygwin and Cygserver a lot. We can discuss questions on serious > debugging efforts on the cygwin-developers mailing list. I know C/C++ and IPC quite well so I'll try to take a look tomorrow night. Of course, I'm still a novice when it comes to the Cygwin internals so it may take a bit. Thanks Corinna! -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 2:23 PM, Corinna Vinschen wrote: > On Apr 14 12:44, Bryan Berns wrote: >> On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen >> wrote: >> > On Apr 14 07:24, Bryan Berns wrote: >> >> For example, I create a whole bunch of files (like 5000), I use >> >> icacls to append a new ACE. Then I do a 'time ls -l >> >> /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin >> >> session, I remove the local group (net localgroup testgroup /delete). >> >> I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. >> >> Subsequent runs in the also take 20 seconds. Since I'm able to >> >> continue to see the slowdown in the same session, cygserver wouldn't >> >> help right? >> >> >> >> Is the above expected? >> > >> > Yes. Without cygserver, caching only works from parent to child process. >> > One run of ls can't cache data for a parallel run of ls in trhe same >> > session. As, btw., explained in the documentation: >> > >> > https://cygwin.com/cygwin-ug-net/ntsec.html >> >> Alright, I'll give it a shot when I get back to my lab. I suspect it >> shouldn't take an additional 16 seconds to attempt to lookup account >> information (and fail) on my two node test network so I'm curious how >> much this will cut the time by. >> If I setup cygserver with all the --no options set (reference: >> https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't >> want any accidental cross-user information sharing, will that >> effectively only provide the SID caching functionality or is there >> other functionality to be wary of? > > You don't have to disable anything. Just don't set the debug option > to avoid logging passwd entries. > Finally tested with cygserver (temporarily with debug on so I can see what's going on). I can definitely see the one entry returned when I run 'ls -l' over my whole collection of files while my test group (LocalGroupTest) is still present. Sample log as follows: /home/corinna/src/cygwin/cygwin-2.0.0/prerelease/cygwin-2.0.0-0.4.i686/src/newlib-cygwin/winsup/cygserver/pwdgrp.cc, line 167: Request account information returns error 0 If I delete the group while cygserver is running, the results continue to be speedy. However, as soon as I delete the group and restart cygserver, things go south. Performance is even worse than without cygserver and there are entries for EVERY file that 'ls' is hitting even though they all have the same group in the ACL so it appears the 'Unknown' users/groups are not being cached. Sample log as follows (one of thousands of lines): Request account information returns error 0 Thoughts? -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 10:53 AM, Corinna Vinschen wrote: > On Apr 14 07:24, Bryan Berns wrote: >> On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen >> > >> > The problem is that Cygwin, or any other tool trying to resolve SIDs >> > doesn't know a SID won't resolve before it tried. And then it's an >> > OS function which takes its time. It's like checking for network >> > machines providing shares. Sometimes this test takes ages, but in >> > this case, fortunately, you see that it takes ages in Explorer as >> > well. >> > >> > As for ACLs, you can alleviate the problem somewhat by running cygserver >> > on the machine, which allows to cache SIDs for all processes. So only >> > the first process trying the SID will take time, followup processes will >> > get the cached results from cygserver. >> > >> > Other than that, except for ignoring ACLs entirely (noacl) I have >> > no idea how to solve this problem differently. >> >> Yes, I understand there's nothing Cygwin can do beforehand -- that >> means sense. I guess what I'm saying is that Cygwin doesn't appear to >> be caching SIDs in certain scenarios. >> >> For example, I create a whole bunch of files (like 5000), I use >> icacls to append a new ACE. Then I do a 'time ls -l >> /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin >> session, I remove the local group (net localgroup testgroup /delete). >> I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. >> Subsequent runs in the also take 20 seconds. Since I'm able to >> continue to see the slowdown in the same session, cygserver wouldn't >> help right? >> >> Is the above expected? > > Yes. Without cygserver, caching only works from parent to child process. > One run of ls can't cache data for a parallel run of ls in trhe same > session. As, btw., explained in the documentation: > > https://cygwin.com/cygwin-ug-net/ntsec.html Alright, I'll give it a shot when I get back to my lab. I suspect it shouldn't take an additional 16 seconds to attempt to lookup account information (and fail) on my two node test network so I'm curious how much this will cut the time by. If I setup cygserver with all the --no options set (reference: https://cygwin.com/cygwin-ug-net/using-cygserver.html) since I don't want any accidental cross-user information sharing, will that effectively only provide the SID caching functionality or is there other functionality to be wary of? Thanks for everything! Bryan -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen > > The problem is that Cygwin, or any other tool trying to resolve SIDs > doesn't know a SID won't resolve before it tried. And then it's an > OS function which takes its time. It's like checking for network > machines providing shares. Sometimes this test takes ages, but in > this case, fortunately, you see that it takes ages in Explorer as > well. > > As for ACLs, you can alleviate the problem somewhat by running cygserver > on the machine, which allows to cache SIDs for all processes. So only > the first process trying the SID will take time, followup processes will > get the cached results from cygserver. > > Other than that, except for ignoring ACLs entirely (noacl) I have > no idea how to solve this problem differently. Yes, I understand there's nothing Cygwin can do beforehand -- that means sense. I guess what I'm saying is that Cygwin doesn't appear to be caching SIDs in certain scenarios. For example, I create a whole bunch of files (like 5000), I use icacls to append a new ACE. Then I do a 'time ls -l /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin session, I remove the local group (net localgroup testgroup /delete). I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. Subsequent runs in the also take 20 seconds. Since I'm able to continue to see the slowdown in the same session, cygserver wouldn't help right? Is the above expected? If not and it's something you're willing to take a look at, I can certainly come up with a little script to demonstrate the issue. -- 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: Making Cygwin More Tolerant of Orphaned SIDs?
On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen wrote: > > Orphaned SIDs shouldn't happen. Disabling accounts, ok, but removing > them? I don't know. So the question is, if there's no account with > these SIDs anymore, why aren't these SIDs removed from the ACLs? > It's not only Cygwin. These SIDs also unnecessarily slow down each > single access check of the OS. > In principal, I agree 100%. Unfortunately, in some large enterprise environments removal of orphaned SIDs rarely happens on a regular basis. The best way to manage this is typically to only delegate access via groups and have those groups aligned to the file system structure in some way (which tends to change less in practice than company organizational structure). Still, when you've got dozens of people starting/leaving every week, per account permission are occasionally established enumerating more a petabyte of data across several sites to cleanup ACEs is certainly possible but not on the top list of things to do (and mass alteration of ACLs carries some liability to it). Don't get me wrong, my anal retentive nature makes me cringe when I see an orphaned SID; it's just the reality of the situation. That said, the origin of my question was actually not due to unresolvable SIDs to due to removed accounts --- it was just the easiest one to describe. The reason I noticed this is because we have some NTFS assignments via local groups on a remote computers (and those local groups then have nested Active Directory groups). So the ACE has REMOTECOMPUTER\Group vice DOMAIN\Group. When Cygwin attempts to retrieve information on these accounts, it seems to fail and causes delays. So with the newer versions of Cygwin, doing an 'ls -l' went from 2 seconds to more than 30 seconds on some particular file directories. As Achim alluded, 'noacl' may be be the way to go for us, but I was just asking the question in the even there was a configurable setting or a feature enhancement that could be integrated to deal with these scenarios. Of course, 'noacl' seems to mark group / other masks as readable so apps that do permissions checks on these files will return inaccurate results :-(. -- 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
Making Cygwin More Tolerant of Orphaned SIDs?
Based on some rudimentary performance tests, it would appear that Cygwin may repeatedly try to lookup information on a SID form an ACE if cannot find a corresponding account which will undoubtedly occur for orphaned SIDs. If the volume being read is remote, this can result in some massive slowdowns if there are many files in the directory. Is there any way to augment this behavior? -- 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] TEST RELEASE: Cygwin 2.0.0-3
> On Apr 12 17:19, Bryan Berns wrote: >> On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen >> wrote: >> >> V:\>icacls touch-from-3 >> touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO) >> DOMAIN\Domain Users:(R) >> Everyone:(R) >> BUILTIN\Administrators:(F) >> NT AUTHORITY\SYSTEM:(F) >> NT AUTHORITY\Authenticated Users:(M) >> BUILTIN\Users:(RX) > > I don't believe this is an ACL created by Cygwin 2.0.0 at all. > It's missing the NULL deny ACE. Now that I'm testing again, I think you're right; I had an older installation on my backup drive try that I think somehow tainted one of my sessions. I'll include version information in my output in the future. Sorry! -- 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] TEST RELEASE: Cygwin 2.0.0-3
On Sun, Apr 12, 2015 at 3:17 PM, Corinna Vinschen wrote: > Hi Cygwin friends and users, > > > New 2.0.0-0.3 test release. It's supposed to fix the pty chmod problem > reported in https://cygwin.com/ml/cygwin/2015-04/msg00240.html > Just a note: In 2.0.0-0.2, creating a file using touch on the root of one of my drives resulted in the with the Windows GUI Security tabs complaining about ACE order on the resultant file. In 2.0.0-0.3, Windows does not complain and the ACL looks quite a bit different (shown below). Not sure if this is a problem or not --- just wanted to report the difference in case your fix had an unintended side affect. Given my heart skips a beat when I see DENY ACEs, I like the new behavior behavior better. V:\>icacls v: v: BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) NT AUTHORITY\Authenticated Users:(OI)(CI)(M) BUILTIN\Users:(OI)(CI)(RX) Output from file created from 2.0.0-0.3: V:\>icacls touch-from-3 touch-from-3 DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(R) Everyone:(R) BUILTIN\Administrators:(F) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\Authenticated Users:(M) BUILTIN\Users:(RX) Successfully processed 1 files; Failed processing 0 files Output from file created from 2.0.0-0.2: V:\>icacls touch-from-2 touch-from-2 NULL SID:(DENY)(Rc,S,WEA,X,DC) DOMAIN\Administrator:(R,W,D,WDAC,WO) DOMAIN\Domain Users:(DENY)(S,X) NT AUTHORITY\Authenticated Users:(DENY)(S,X) BUILTIN\Users:(DENY)(S,X) DOMAIN\Domain Users:(RX) NT AUTHORITY\Authenticated Users:(RX,W) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) BUILTIN\Users:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 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: [TESTERS needed] New POSIX permission handling
>> > That means, even if SYSTEM or Administrators have full access to the >> > file, the POSIX permssion bits will not reflect that fact. And while >> > other users get access denied based on the mask value, SYSTEM and >> > Administrators will never get access denied based on the mask. >> >> If you want to put this to better use in larger settings it would seem >> preferrable if it was possible to define a list of users to treat this >> way in fstab. > > Nope, sorry, no configuration for this. Either it's handled without > any exception, or for SYSTEM only, or for SYSTEM+Admins. But either > way, we're doing it the same way on every system. Damn. I was about to reply with Achim's exact same thought --- like a file in /etc with a list of SIDs. I can empathize with Corinna's veto though -- having a hundred tweak-able settings in Cygwin is unmaintainable for the general populous. I may apply a local patch to extend this ability myself because Cygwin has become rather unusable for users with home's on our network drives (given all the programs that attempt to do sanity checks on group perms). That said, I appreciate what has been integrated --- it will help in several scenarios. I will test the release this weekend. Thanks for all the hard work! -- 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: Robocopy
On Thu, Apr 2, 2015 at 1:47 PM, Houder wrote: > 2015/04/02 19:13:56 ERROR 5 (0x0005) Copying File > E:\Cygwin\home\jvdwater\.bash_history > Access is denied. > Waiting 30 seconds... Retrying... > New File 689.bash_history ROBOCOPY is very reliable and it's actually what I use to have folks "install" Cygwin on our enterprise systems (i.e. I setup a master replica of the install and they ROBOCOPY it down to their machines). It works without fail unless they have a files in use. If you throw in /R:0, do you see any other files with access denied? Might be a good datapoint to confirm it's everything and not something specify about bash_history. -- 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: File Permissions - Yet Another Question / Clarification
Replying to myself on this topic in case anyone else is interested. > 2) how can I get SSH to believe the two "admin" groups on my > files are acceptable. I'm not optimistic I'm going to get SSH to > change it's behavior so I may need to recompile it to avoid the > check which is obviously not desirable from a maintainability > standpoint. The applicable check at work here is check_ntsec() and the several lines after within authfile.c in the openssh package. I confirmed there is no elegant way to avoid or externally augment these checks as it's currently programmed without patching and recompiling (or using something like Microsoft Detours to fake out the external call to pathconf() which is called by check_ntsec() -- very ugly). I completely agree with the general guidance that these are important checks as it prevents the user from accidentally exposing their private keys. In our environment, the check is returning a false positive given our home directory permissions are tightly controlled (immutable by end users, in fact) and some cross-domain administrative groups are used to delegate control of the directories to certain authorized personnel. Eliminating these groups from the DACL and granting these personnel Backup/Restore rights on the entire filer (hundreds of terabytes) is not a secure solution for us. I'm guessing others in a large corporate environment may find themselves in a similar scenario. I was able to modify the check to work for our scenario and recompile. Obviously this isn't the ideal solution, but it looks like it's our only path forward. I still have to figure out why file ownership isn't recorded properly --- if I figure that out, I'll let everyone know as well. -- 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: Should cygwin's setup*.exe be signed using Sign Tool?
> Has Cygwin considered signing the installer using Sign Tool? More info: > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx > > http://blog.didierstevens.com/2008/12/31/howto-add-a-digital-signature-to-executables/ > > I believe signing it this way would eliminate the "unknown publisher"; it > would also protect the many people who don't follow the current > signature-checking process. This would create a strong barrier against code > subversion after release. > > The signed executable could also be signed using the current process, so you > don't need to *eliminate* any capability. I can't provide a patch to do > this, obviously :-). > > --- David A. Wheeler Ultimately, this is probably a Corinna question since I believe she compiles the setup executable, but I'll provide my general input as an software developer. Firstly, the tools to sign an executable are certainly available as part of the Windows SDK which is freely downloadable -- so no problem there. However, we would have to determine which publicly trusted certificate to use (using a self-signed cert would likely produce the same message) and is signing the executable the *right* thing to do. Since the setup executable is responsible for running a whole bunch of community contributed post-install executables as part of the installation process, I'm not sure whether it'd be advisable to stamp a particular individual's name or company's name on the executive installer (e.g. Red Hat, for example). If a tainted executable was uploaded into the package repository and subsequently flagged, the certificate authority may have to revoke the certificate which is never good for publicity of the signer. For most pieces of software, the maintainer or the maintainers company's can very confidently vouch for the content of the installation package and executables within it. In the Cygwin world, this accountability is a little more distributed between the package maintainers and source code contributors. That said, I have the upmost respect for the package maintainers and I've never had any security problems with the Cygwin packages other than stupid antivirus false positives and some dirty limericks that got installed (my HR department didn't like that). So that's my two cents. For all I know the *real* reason it's not signed is "nobody had asked for it". - Bryan -- 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: File Permissions - Yet Another Question / Clarification
> He's talking about "Administrators" the SID (group). Interesting. Given the built-in Administrators group doesn't often [directly] play into permissions on remote systems or cross-system permission models, I'm not sure where he was going with that. Regardless, I'll consider it water under the bridge. > In any case, I'd start with a throwaway share (or save the permissions > with subinacl if I had to use a live one). Then remove the inherited / > default DACL from a subdirectory: > > mkdir sub > setfacl -k sub > setfacl -b sub > > Then check how this behaves w.r.t. POSIX permissions and file ownership. > Populate this directory with files and check those, too. The ~/.ssh > directory and their content shouldn't have any DACL on them in any case > if you c want to be sure it works the way sshd is wanting it to. > > > Regards, > Achim. Thanks for advice -- I will give it a shot and dive in deeper. I think I have two problems I'm interesting in understanding more / resolving: 1) why doesn't Cygwin think my user has permissions to the files and 2) how can I get SSH to believe the two "admin" groups on my files are acceptable. I'm not optimistic I'm going to get SSH to change it's behavior so I may need to recompile it to avoid the check which is obviously not desirable from a maintainability standpoint. Appreciatively, Bryan -- 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: File Permissions - Yet Another Question / Clarification
Andrey, >> In the particular case of SSH, is there any way to make SSH ignore >> these permissions? > Thanks, I laughed. Thanks for the less-than-helpful response. A "no" would have sufficed if that is indeed the case. >> and obviously >> causing us pain given the permission weirdness. Removing the >> administrative groups would be undesirable for us since they assist in >> our administrative team doing home directory moves across sites. > Administrators can access anything they want regardless of permissions, if > they really need to do it. > This is not a valid argument. In the real world in large corporations with focus on security, "Administrators" is typically a tiered or least privilege arrangement. All administrators are not created equally. Thanks, Bryan -- 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: File Permissions - Yet Another Question / Clarification
I'll try to reproduce the issue on a standard NTFS volume -- although I would image Cygwin is just decoding the same DACL that ICACLS is returning. The other oddity is why it's not recognizing *me* as having any permissions. In the particular case of SSH, is there any way to make SSH ignore these permissions? I understand the importance / value of the check it's doing, but in our situation, it's not necessary... and obviously causing us pain given the permission weirdness. Removing the administrative groups would be undesirable for us since they assist in our administrative team doing home directory moves across sites. -- 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: File Permissions - Yet Another Question / Clarification
Andrey, Sorry for not being more clear -- yes, I had read the FAQ on SSH. I was taking the problem up a level to the more obvious weirdness demonstrated by the resultant files on a simple "touch". Why would Cygwin report that 'Domain Users' --- a group not in the DACL at all --- as being able to R/W/X on the files? The relevant mount is this: K: on /cygdrive/k type netapp (text,posix=0,user,noumount,auto) Note: It is indeed on a NetApp that is using NTFS mode. -- 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
File Permissions - Yet Another Question / Clarification
I finally am moving my user community to Cygwin 1.7.35 at work and having some issues with ssh not thinking user's ssh keys are owned by the user. I indeed can see that their directory listings do not show their userid as having read,write, or execute to *any* of their files. In short, just wanted to make sure behavior like that demonstrated below is "by design". In particular, I find it odd that "Domain Users" is the only entity that is listed as having permissions despite not being in the DACL at all. On the plus side, the startup speed is much, much faster than before and we no longer need to worry about maintaining our HUGE passwd and groups files. Any thoughts are appreciated. I've read the ntsec page and still digesting all information... @ umask 77 @ whoami bernsbj @ touch mytestfile @ ls -l mytestfile rwx---+ 1 bernsbj Domain Users 0 Apr 1 15:38 mytestfile @ icacls mytestfile mytestfile MYDOMAIN\bernsbj:(I)(F) BUILTIN\Administrators:(I)(F) OTHERDOMAIN\Domain Admins:(I)(F) -- 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: Compatibility of binaries built with one version of cygwin with other versions of cygwin
"Guaranteed" might be a strong word - especially given the lack of a guarantor; probably depends on whether the programmer has had to workaround any nuances in the Cygwin library that may have changed in later versions. I think the library function exports have been the same for awhile and I've personally had pretty good lucking simply dropping in a new DLL file without issues. -- 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: Too Many Permissions Stripped In 1.7.35?
>> Crucial vote starting... now. Given my original post, I'm obviously fan of ignoring SYSTEM (S-1-5-18) explicitly. As much as the absolutist programmer in me doesn't like nuanced exceptions like this, I think it's the pragmatic thing to do. -- 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: Too Many Permissions Stripped In 1.7.35?
> That's an administrator account, not SYSTEM. The BERNS-WINDOWS$ is the account the process was being run under (launched via psexec -i -s) and is indeed the system account. I ran icacls just to display the current ACL on the directory (which does not include the system account for the purpose of the test). Sorry for not being more clear. Regardless, Corinna clarified her assertion was dependent on enabling Backup/Restore privileges for the process at hand. -- 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: Too Many Permissions Stripped In 1.7.35?
> You just have to enable the SeBackupName and SeRestoreName privs. > Try in Cygwin. It does that automatically. > > For cases where you need to stick to the Windows ACLs, use noacl > mounts. Understood --- I can probably set SeBackupPrivilege / SeRestorePrivilege as 'RequiredPriveleges' for the services that depend on the system account having access via the ACLs. Not being used quite in the spirit of those privileges (i.e. for backup/restore), but doable. We'll also have to revise our permissions model on our network filers since before running 'chmod 700' on a file wouldn't blow away our various administrative groups. Like I said originally, just wanted to verify it was desired behavior and it sounds like it is. 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: Too Many Permissions Stripped In 1.7.35?
> That's not really a goal. The SYSTEM permissions are kind of useless > anyway, given that SYSTEM has permissions to read and write all files > anyway. I don't see that a rule to add SYSTEM permissions to all files > accomplishes anything which isn't already available anyway. I don't think this is true; see below when running as the system account: V:\>echo %USERNAME% BERNS-WINDOWS$ V:\>icacls V:\Test V:\Test DOMAIN\Administrator:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files V:\>cd V:\Test Access is denied. V:\> -- 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
Too Many Permissions Stripped In 1.7.35?
I honestly haven't read up exactly how Cygwin interprets NTFS ACL/ACEs, but I remember seeing on the mailing list that a change was made in 1.7.35 was made to permission handling. It is preferable in my organization that the SYSTEM account always have full control the local file system. When using chmod under 1.7.35, it looks like permissions for SYSTEM get stripped (as well as some others). Is this the desired behavior? If so, I'll workaround it somehow but just wanted to verify before we release this much anticipated Active Directory optimized version. For context, I'm running as the default Domain Administrator on a fresh install of Windows 8.1. @@ Testing With 1.7.34 @@ $ uname -a CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin $ mkdir TEST-34 $ chmod 750 TEST-34 $ icacls TEST-34 TEST-34 DOMAIN\Administrator:(F) DOMAIN\Domain Users:(RX) Everyone:(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(F) NT AUTHORITY\SYSTEM:(OI)(CI)(F) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(M) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files @@ Testing With 1.7.35 @@ $ uname -a CYGWIN_NT-6.3 BERNS-WINDOWS 1.7.35(0.286/5/3) 2015-02-25 13:13 x86_64 Cygwin $ mkdir TEST-35 $ chmod 750 TEST-35 $ icacls TEST-35 TEST-35 DOMAIN\Administrator:(F) DOMAIN\Domain Users:(RX) Everyone:(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(RX) NT AUTHORITY\SYSTEM:(OI)(CI)(RX) BUILTIN\Users:(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(RX) NT AUTHORITY\Authenticated Users:(OI)(CI)(IO) CREATOR OWNER:(OI)(CI)(IO)(RX) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Thanks for the reply, Andrey. I'll take a look at the archives for February. I'm not sure how it'd be "obvious" given that's it's just descriptive metadata for the SID, but I'll try to educate myself before rehashing a previous discussion. -- 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] TEST RELEASE: Cygwin 1.7.34-003 (Christmas/New Year release)
Finally had a chance to test out the new release, albeit in a very limited fashion. On our multi-domain forest with SID-History enabled, running 'ls -l' was able to lookup account names for groups and users on files. Some ACEs had SIDs that would only be in present SID-History and those worked as well. It would be nice if the names presented would be in what Microsoft calls the "NameSamCompatible" format instead of DOMAIN+USERNAME format. I see this is by design based on the documentation submitted Corinna put together. Not a problem, although I'm curious as to why it was setup this way. -- 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: RFC: 1.7.33 problem with user's home directory
One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This became especially noticeable with Cygwin 64-bit because Windows does not automatically redirect write attempts to %LOCALAPPDATA%\VirtualStore. Anyhow, that's probably left to a different conversation for a different day... -- 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] TEST RELEASE: Cygwin 1.7.33-0.6
I haven't tried Cygwin 1.7.33 yet. What would be the expectation of sidHistory working? In the past, I've had a script to read extra SIDs out of AD and merge them into passwd. On Wed, Nov 5, 2014 at 11:43 AM, Corinna Vinschen wrote: > Hi Cygwin friends and users, > > > I just released a 6th TEST version of the next upcoming Cygwin release, > 1.7.33-0.6. > > Changes compared to the former test version 1.7.33-0.5: > > - The 1.7.33-0.5 version introduced a dependency to a symbol (__dso_handle) > provided only by GCC versions starting with GCC 4.8.3-3. This results > in being unable to link executables with GCC 4.8.3-2 and earlier. > Cygwin 1.7.33-0.6 introduces a fix for this situation by providing its > own default symbol __dso_handle. > > > If you want to help testing this new release (which I seriously hope > for), you can find it in your setup-x86.exe or setup-x86_64.exe as > "test" release. > > > The major change in this new release is the new method to read account > (passwd and group) information from the Windows user databases directly, > without the requirement to generate /etc/passwd and /etc/group files to > generate Unix-like uid and gid. > > For your convenience I wrote new documentation. Since this is a TEST > prerelease, the new documentation is not part of the official docs yet. > Rather have a look at > > https://cygwin.com/preliminary-ntsec.html > > If you read it > (which I seriously hope for) and it's all just incomprehensible > gobbledygook to you, please say so on the mailing list > > cygwin AT cygwin DOT com > > so we have a chance to improve the documentation. > > Please give this TEST release a try. > > If you find problems in the new features or regressions compared to the > current stable release 1.7.32, please report them to the public mailing > list > > cygwin AT cygwin DOT com > > > Following is a list of changes in this new release: > > > What's new: > --- > > - Cygwin can now generate passwd/group entries directly from Windows > user databases (local SAM or Active Directory), thus allowing to run > Cygwin without having to create /etc/passwd and /etc/group files. > Introduce /etc/nsswitch.conf file to configure passwd/group handling. > > For bordercase which require to use /etc/passwd and /etc/group files, > change mkpasswd/mkgroup to generate passwd/group entries compatible > with the entries read from SAM/AD. > > - Add -b/--remove-all option to setfacl to reduce the ACL to only the > entries representing POSIX permission bits. > > - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. > This can be utilized in scripts to access paths via cygdrive prefix, even > if the cygdrive prefix has been changed by the user. > > - /proc/partitions now prints the windows mount points the device is mounted > on. This allows to recognize the underlying Windows devices of the Cygwin > raw device names. > > - New API: quotactl, designed after the Linux/BSD function, but severely > restricted: Windows only supports user block quotas on NTFS, no group > quotas, no inode quotas, no time constraints. > > - New APIs: ffsl, ffsll (glibc extensions). > > - New API: stime (SVr4). > > - Provide Cygwin documentation (PDFs and HTML) for offline usage in > /usr/share/doc/cygwin-${version}. > > > What changed: > - > > - New internal exception handling based on SEH on 64 bit Cygwin. > > - Revamp Solaris ACL implementation to more closely work like POSIX ACLs > are supposed to work. Finally implement a CLASS_OBJ emulation. Update > getfacl(1)/setfacl(1) accordingly. > > - When exec'ing applications, check if $PATH exists and is non-empty. If not, > add PATH variable with Cygwin installation directory as content to Windows > environment to allow loading of Cygwin system DLLs. > > - Disable CYGWIN "dosfilewarning" option by default. > - Improve various header files for C++- and standards-compliance. > > - Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6. > > - The xdr functions are no longer exported for newly built executables. > Use libtirpc-devel instead. > > - atexit is now exported as statically linked function from libcygwin.a. > This allows reliable access to the DSO handle of the caller for newly > built executables. The former atexit entry point into the DLL remains > for backward compatibility only. > > > Bug Fixes > - > > - Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid > directory stream. > > - Fix a resource leak in rmdir(2). > > - Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after > open and before calling one of the affected functions. > Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html > > - Handle Netapp-specific problem in statvfs(2)/fstatvfs(2). > Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html > > - Fix chown(2) on ptys in a corner case. > > - Generate correct error when a path i
Re: BLODA Addition
Random is this case is receiving a "permission denied" message from the shell when launching an executable. When repeatably running a test case, we see an error one every 15 minutes on average. Without it installed, no error occurs. I'll see what might be good registry key to query -- not sitting at a computer with it installed right now. I was thinking about debugging the underlying issue that's causing this from a cygwin perspective. Would this be advisable or is this behavior just a fundamental consequence of how cygwin interacts with Windows? On Nov 5, 2014 11:43 AM, "Corinna Vinschen" wrote: > > Hi Bryan, > > On Nov 5 11:12, Bryan Berns wrote: > > I recently discovered that the Liquidware Labs Stratusphere Agent > > causes random issues when launching executables through a Cygwin bash > > What means "random issues" here? > > > shell. Any chance someone can add this to the BLODA list to help > > others that might run into similar issues? > > If you can describe a simple way how to discover the software by > the existence of some file or registry key, or maybe by the name > of a running process (not as reliable), we could add this even to > the BLODA test in cygcheck. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- 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
BLODA Addition
I recently discovered that the Liquidware Labs Stratusphere Agent causes random issues when launching executables through a Cygwin bash shell. Any chance someone can add this to the BLODA list to help others that might run into similar issues? -- 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: Necessary To Query SACL Information?
Arg. Responding to myself. Apparently ALL_SECURITY_INFORMATION is internally defined and doesn't contain the flag for SACL information (so much for being 'ALL'). I'll keep exploring... -- 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
Necessary To Query SACL Information?
I noticed when I launch an executable, Cygwin queries SACL information on the executable (which I can see in Process Monitor as a 'QuerySecurityFile' operation). On some of my protected file servers, this generates a failure audit. Looking at the source code, I'm going to guess this might be from the NtQuerySecurityObject call in security.cc which requests SACL information by asking for for ALL_SECURITY_INFORMATION. Does Cygwin really need to query this information? Aside from keeping my audit logs clean, it seems like it might be an opportunity for optimizing the executable launch process if Cygwin doesn't really need this (or some of the other information that ALL_SECURITY_INFORMATION provides). Thoughts? -- 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: Reduce noise in dependency declaration during uninstall in setup.exe
Andrey Repin wrote on 2014-01-23: >>> Actually I'm working on a method to get rid of /etc/passwd and >>> /etc/group. I have a partially working implementation now, which >>> generates passwd and group entries by fetching the infos from Windows >>> on the fly, compatible to the uids/gids and user/group names to >>> SFU/Interix. > >> That's a really cool change. How will I customize my Cygwin user name (for >> convenient 'ssh server' instead of 'ssh user@server') and shell without >> /etc/passwd, though? (I'd include home directory >> in that list, except I know I can just set $HOME) > > You can set $USER the same way, you know? Ah, that's nice, I'll have to try it. :-) > But that's a wrong way to go. IMO. > You are supposed to be yourself, means, your login name. > Else you'd have alot of stuff mishandled. The user I use is myself, it is just that at my company, my login name on the servers isn't the same as my Windows login name. I haven't noticed anything mishandled, though. Do you have any specific problems in mind? -- Bryan Thrall Principal Software Engineer FlightSafety International * Visual Simulation Systems * 5695 Campus Parkway * Hazelwood, MO 63042 Tel: (314) 551-8413 * Fax: (314) 551-8444 bryan.thr...@flightsafety.com * www.flightsafety.com * A Berkshire Hathaway company -- 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: Reduce noise in dependency declaration during uninstall in setup.exe
Corinna Vinschen wrote on 2014-01-22: > Actually I'm working on a method to get rid of /etc/passwd and > /etc/group. I have a partially working implementation now, which > generates passwd and group entries by fetching the infos from Windows on > the fly, compatible to the uids/gids and user/group names to SFU/Interix. That's a really cool change. How will I customize my Cygwin user name (for convenient 'ssh server' instead of 'ssh user@server') and shell without /etc/passwd, though? (I'd include home directory in that list, except I know I can just set $HOME) Thanks! -- Bryan Thrall Principal Software Engineer FlightSafety International • Visual Simulation Systems • 5695 Campus Parkway • Hazelwood, MO 63042 Tel: (314) 551-8413 • Fax: (314) 551-8444 bryan.thr...@flightsafety.com • www.flightsafety.com • A Berkshire Hathaway company
RE: Failure with fork()
Larry Hall (Cygwin) wrote on 2013-06-27: > On 6/27/2013 4:33 PM, Alan W. Irwin wrote: >> So the question still remains how do I gain access to a version of >> setup.exe with the fork fix that will allow me to not only initialize >> my Cygwin distribution for Wine without the fork abort, but also >> subsequently update it to install all components of Cygwin that I >> need? > > Since you want to just run 'setup.exe', you need a new cygwin package > (i.e. cygwin-1.7.2*-*) before you'll be able to do what you want > without any extra effort on your part. So unless you're willing to > build your own version of this package and put it in your download > directory in the appropriate spot (after you've downloaded the > packages you want), you want to just wait for the next announcement > for the cygwin package. Since the fork bug is only affecting the execution of the postinstall scripts, couldn't the OP install the snapshot in the partially-complete Cygwin install, then run setup.exe to finish the postinstall scripts? -- Bryan Thrall Principal Software Engineer FlightSafety International * Visual Simulation Systems * 5695 Campus Parkway * Hazelwood, MO 63042 Tel: (314) 551-8413 * Fax: (314) 551-8444 bryan.thr...@flightsafety.com * www.flightsafety.com * A Berkshire Hathaway company -- 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
get_myaddress error with nfsd
I just upgraded my cygwin installation to 1.7.20-1 this morning and my nfsd server no longer starts with this error in /var/log/nfsd.log get_myaddress: ioctl: Invalid argument Mountd has the same error but portmap starts fine. I pulled down the source for nfs-server and only see one ioctl in nfsd.c and one in mountd.c and no references to get_myaddress. Has anyone else experienced this? I am not sure where to start looking. -- bryan -- 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
Emacs silently fails to run after last cygwin update
I upgraded cygwin on both an XP and a Windows 7 box this week. In both cases, the x windows version of emacs fails to start. In both cases the X server is cygwin X running on the windows 7 box). I have tried reinstalls on most of my cygwin packages on both hosts to no avail. emacs-nox does run normally and reports version 24.2.1. "emacs -q" makes no difference. No error is reported on the console. I have gdb on the windows box - trying to run emacs gives a During startup program exited with code 0xc013. I have no trouble firing up other x windows programs such as xterm, xemacs, or the latest emacs from a linux virtual machine. All of the boxes have all of the latest windows updates. Emacs was working for me on these hosts a couple of weeks ago. Downgrading emacs and emacs-x11 to 23.2.9 doesn't help. Several internet searches and forum searches have not revealed anyone else having this problem. Does anyone know what the solution might be? Thanks -- -Horace -- 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: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
Alan Thompson wrote on 2012-12-11: > Looking at the link on StackOverflow (from 2010) it may be that the > xemacs version of ctags is overwriting the default version in /bin. > Could this be the culprit? Yes, it looks like xemacs-tags and ctags packages both install /usr/bin/ctags.exe: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=ctags.exe > On Tue, Dec 11, 2012 at 11:55 AM, Alan Thompson > wrote: >> Hi - Yes, I'm sure: >> >>> find /bin -name '*tags*' | xargs ls -ldF >> -rwxr-xr-x 1 alathompson Domain Users 85504 Jan 31 2009 /bin/ctags.exe* >> -rwxr-xr-x 1 alathompson Domain Users 83968 Jan 31 2009 /bin/etags.exe* >> -rwxr-xr-x 1 alathompson Domain Users 5411 Dec 21 2011 /bin/ocamltags* >> -rwxr-xr-x 1 alathompson Domain Users 68608 Jan 31 2009 > /bin/ootags.exe* >>> ls -ldF /bin/ls /bin/vim /bin/gcc >> lrwxrwxrwx 1 alathompson Domain Users 21 Oct 18 12:20 /bin/gcc -> >> /etc/alternatives/gcc* >> -rwxr-xr-x 1 alathompson Domain Users 101902 Feb 6 2012 /bin/ls* >> lrwxrwxrwx 1 alathompson Domain Users 21 Oct 18 12:48 /bin/vim -> >> /etc/alternatives/vim* >>> >>> uname -a >> CYGWIN_NT-6.1-WOW64 ALAN-THO-LAP 1.7.16(0.262/5/3) 2012-07-20 > 22:55 i686 Cygwin >>> >> >> One can see from the timestamp on the links for gcc and vim that I >> installed Cygwin on 10/18/2012. However, it seems that both ctags and >> etags are old versions of the program (circa 2007) and are not the >> Exuberant Ctags version. However, the GNU documentation here: >> http://directory.fsf.org/wiki/Exuberant_Ctags clearly lists the >> Exuberant Ctags, although it has only been updated as of 2004. >> However, looking here: >> http://cygwin.com/packages/ctags/ctags-5.8-1-src we see that cygwin >> has Exuberant Ctags 5.8. Perhaps it is just a packaging issue that >> caused the old one to be present and Exuberant Ctags 5.8 to be not >> present? >> >> You can see from this thread: >> http://stackoverflow.com/questions/2634001/any-idea-why-ctags-wont- > recurse-on-cygwin/13810472#13810472 >> that I'm not the only one who stumbled onto this problem. >> Where should we go from here? Could it just be a packaging problem? >> Alan Thompson >> >> >> On Tue, Dec 11, 2012 at 11:24 AM, Thrall, Bryan >> wrote: >>> >>> Are you sure you're using the ctags you think you are? >>> >>> $ ctags --help >>> Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert >>> Compiled: Dec 11 2009, 11:42:40 Addresses: >>> , http://ctags.sourceforge.net >>> Optional compiled features: +wildcards, +regex, +internal-sort >>> Usage: ctags [options] [file(s)] >>> >>> -R Equivalent to --recurse. >>> >>> >>> Hope this helps! >>> -- >>> Bryan Thrall >>> Principal Software Engineer >>> FlightSafety International >>> bryan.thr...@flightsafety.com >>> >>> > -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: ctags recursion broken?
Alan Thompson wrote on 2012-12-11: > Upon closer inspection, it appears that Cygwin has a different version > of ctags (not Exuberant Ctags!) that does not support recursion at > all! Specifically, > >> ctags -V > ctags (standalone 21.4.22) > Copyright (C) 2007 Free Software Foundation, Inc. > This program is distributed under the terms in ETAGS.README >> >> ctags --help > Usage: ctags [options] [[regex-option ...] file-name] ... > > These are the options accepted by ctags. > You may use unambiguous abbreviations for the long option names. > A - as file name means read names from stdin (one per line). > Absolute names are stored in the output file as they are. Relative ones > are stored relative to the output file's directory. -R, --no-regex > Don't create tags from regexps for the following files. > Are you sure you're using the ctags you think you are? $ ctags --help Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert Compiled: Dec 11 2009, 11:42:40 Addresses: , http://ctags.sourceforge.net Optional compiled features: +wildcards, +regex, +internal-sort Usage: ctags [options] [file(s)] -R Equivalent to --recurse. Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: tcsh hang while executing scripts which use pipes with backticks
Running 8 instances of the script from http://cygwin.com/ml/cygwin/2012-07/msg00014.html I get the following results using cygwin 1.7.16 and tcsh 6.18.01: - OK on 32bit XP with 2 cpus - Hangs on 64bit Win2008 with 4 cpus - OK on 64bit Win2008r2 with a single cpu - Hangs on 64bit Win2008r2 with 2 cpus Those last two were the same server (a VMware VM) with the number of cpus changed. Attempting to kill the hung processes crashed the server :-( There are no problems if tcsh 6.17.0 is used. Bryan. -- 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: curl (7.27.0-1), even curl --version, does not work
FYI, please *attach* cygcheck output in the future so it doesn't clutter up search results. This: Regid Ichira wrote on 2012-09-04: >>> I do have it: >>> $ cygcheck -c cygwin >>> Cygwin Package Information >>> Package VersionStatus >>> cygwin 1.7.16-1 OK Does not match this: > 2779k 2012/04/25 C:\externalPrograms\cygwin\root\bin\cygwin1.dll - os=4.0 > img=1.0 sys=4.0 > "cygwin1.dll" v0.0 ts=2012/4/25 8:41 > Cygwin DLL version info: > DLL version: 1.7.14 > DLL epoch: 19 > DLL old termios: 5 > DLL malloc env: 28 > Cygwin conv: 181 > API major: 0 > API minor: 260 > Shared data: 5 > DLL identifier: cygwin1 > Mount registry: 3 > Cygwin registry name: Cygwin > Program options name: Program Options > Installations name: Installations > Cygdrive default prefix: > Build date: > Shared id: cygwin1S5 My guess is you had Cygwin processes running when you upgraded from 1.7.14 to 1.7.16 and did not reboot afterwards (there should be a cygwin1.dll.new in your /bin directory). Or, as I understand happens sometimes, the Windows replace-on-reboot feature failed. The safest thing to do to fix the problem would be to close all Cygwin processes and reinstall the Cygwin package. If you want to get your hands dirty, you could close all Cygwin processes and replace your existing cygwin1.dll with cygwin1.dll.new. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: Promote sqlite 3.7.13-1 from test status?
Warren Young wrote on 2012-08-16: > Dev Fred likes to use the GUI TortoiseSVN client most of the time. > (Fred is a little strange, but we like him anyway.) My particular use case is 99% of the time, I use Cygwin SVN, but once in a while TortoiseSVN's revision graph is useful. I think what makes this a bigger problem than "Don't use Windows apps at the same time on the same files as you are using Cygwin on" is just having TortoiseSVN installed triggers the SQLite locking problem, so Fred or I might not have used TortoiseSVN all week but it's still interfering with Cygwin SVN because of its Windows Explorer hooks. Turning TortoiseSVN's icon overlay caching to "Shell" (or "None") has fixed the problem for me, but I haven't tried SQLite compiled without the Windows file locking. IMHO, if that combination works (icon caching off, SQLite using Cygwin locking), that's the way to go. > What are Fred's options? > Option 1: Download the native Windows Subversion port. Sensible, but it > means you have to use a crippled shell. Apologies for being pedantic, but TortoiseSVN already provides Windows Subversion command line tools. Your point of the crippled shell stands, however :) -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: Cygwin fresh install imports Windows PATH which includes spaces causing errors
Aaron Schneider wrote on 2012-07-24: > So anyway, the problem is caused when calling a binary present on > windows path that can match a cygwin one, for example running a > ./configure script. > After removing make the issue is happening again: > $ make > cygwin warning: >MS-DOS style path detected: /usr/local/bin/C:\Program Preferred POSIX >equivalent is: /usr/local/bin/C:/Program CYGWIN environment variable >option "nodosfilewarning" turns off this warning. Consult the user's >guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > Can't find C:\Program on PATH. Could this be a problem with the Makefile? It looks like you're using Cygwin make now, but the Makefile might be calling out Windows paths directly... -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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 unstable as hell on Windows7 64bit
James Johnston wrote on 2012-06-21: > It would be nice if there was a list of ways for checking for BLODA. While > there is a long list of BLODA already there, it's possible there could be a > new > dodgy app not on the list. In that case, some things to check for would be > helpful. There is the obvious ways mentioned: check for 3rd-party services, > 3rd-party apps loaded via the Run registry key, AppInit_DLLs - but I'm sure > I'm missing some. CYGWIN=detect_bloda might help (see http://cygwin.com/cygwin-ug-net/using-cygwinenv.html). -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: How to "bisect" Cygwin?
Ryan C. Underwood wrote on 2012-06-01: > On Thu, May 31, 2012 at 11:51:53PM +0200, Cyrille Lefevre wrote: >> >> well, have you tryed the cygwin time machine : >> >> http://www.fruitbat.org/Cygwin/index.html#cygwincirca > > I must not be understanding how to use this. For example, if I take > the URL for 2/13: > > ftp://www.fruitbat.org/pub/cygwin/circa/2012/02/13/150019 > > If I put that URL into Cygwin setup.exe, it complains that it can't > find setup.bz2.sig. If I view in my browser, there are no files > visible. I guess the file listing could be disabled to avoid mass > leeching. But then I just don't know what I'm doing wrong, having not > used this service before. I tried a handful of other URLs with the > same results. Has anyone else used this recently? > See the "Old Update" from 8/5/2008 under http://www.fruitbat.org/Cygwin/index.html#cygwincirca: You need to specify -X when running Cygwin setup.exe. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: Shell script loop runs out of memory
AZ 9901 wrote on 2012-05-31: > 2012/5/31 Jordan : > Then, when (bash) scripting under Cygwin, you must take care to avoid > forking as much as possible. > > You could try to improve the "sleep 1" loop with the following one : > > while md5sum $FILE_TO_CHECK | cut -d " " -f1 | grep -q "^$MD5PRINT$" > do > sleep 1 > done > > Note that MD5PRINTNEW is no more useful here. > With this loop we avoid the fork done by > MD5PRINTNEW=`md5sum $FILE_TO_CHECK | cut -d " " -f1` Doesn't that just replace the 2 MD5PRINTNEW forks (md5sum and cut) with 3 (md5sum, cut, and grep)? Seems like the (untested) following would be better (in terms of fewer forks): TMPFILE=$(mktemp) md5sum $FILE_TO_CHECK > "$TMPFILE" ... while md5sum -c "$TMPFILE" do sleep 1 done rm "$TMPFILE" -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: Ctrl-C issue for Windows program
Wm. David Bentlage wrote on 2012-04-13: > Hello, > > I run locally-developed Windows console program via mintty/cygwin. > I've noticed a problem with Ctrl-C in mintty 1.0.3 not terminating my > app. The problem came about with my switching to "CYGWIN_NT-5.1 pc > 1.7.10(0.259/5/3) 2012-02-05 12:36 i686 Cygwin". Ctrl-C just makes > the window hang. /bin/kill -f cannot kill the task either. I can > kill my Windows program via task manager. > > mintty 1.0.3 and Ctrl-C on "CYGWIN_NT-5.2 server 1.7.9(0.237/5/3) > 2011-03-29 10:10 i686 Cygwin" works fine. On 1.7.10 or "CYGWIN_NT-5.2 > server 1.7.13(0.260/5/3) 2012-04-05 12:43 i686 Cygwin" Ctrl-C does > not. In addition, rxvt has the same change in Ctrl-C behavior with > the introduction of 1.7.10. > > Can the functionality of Ctrl-C please be restored? Cygwin 1.7.12 has a fix for Ctrl-C handling: http://cygwin.com/ml/cygwin-announce/2012-04/msg00016.html Hope this helps! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: Cygwin 1.7.12
Achim Gratz wrote on 2012-04-04: > Corinna Vinschen writes: >> >> I just released 1.7.12. This is mainly a bugfix release, but a couple >> of bigger changes were required under the hood to fix some of the bugs. >> > > I'm not really sure if that happens because of the changes in 1.7.12 or > if I just never saw it before: > > Using ~-expansion in the shell gives me the eight users that mkpasswd > has created plus an additional "user" with as its name and the > home directory set to /mnt/userdata, which gets me a funny prompt when > doing a cd into that directory. Is there a way to drop such users from > the expansion? I see it too, and I'm running a pre-1.7.12 snapshot: $ uname -a CYGWIN_NT-5.1 pc1163-8413-xp 1.7.12s(0.260/5/3) 20120321 15:56:37 i686 Cygwin -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: how to verify setup.exe signature
Alexey Luchko wrote on 2012-03-28: > Hi! > > I was concerning how to verify http://cygwin.com/setup.exe for some time. > Today I've got an idea to check for .sig file and it is there too. > > However, cygwin's public key is required to check it. Where is it supposed > to be? I think the links in the first paragraph of http://cygwin.com/install.html should answer your question. Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: perl-Tk widget broken again on perl 5.10.1-5
Thrall, Bryan wrote on 2012-02-27: > Thrall, Bryan wrote on 2012-01-25: >> perl-Tk's widget works just fine with >> >> perl5.10.1-3 >> perl-Tk 804.028-3 >> >> but if I upgrade to perl 5.10.1-5, widget breaks again[1] with the following >> errors repeated until the process is killed: >> >> Use of uninitialized value $id in hash element at >> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 39. >> Use of uninitialized value $id in delete at >> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 87. >> >> perl-Tk 804.029-1 works just fine with perl 5.10.1-3. >> >> cygcheck -svr output attached. >> >> Thanks. >> >> [1] Original report threads here: >> >> http://cygwin.com/ml/cygwin/2009-03/msg00800.html >> http://cygwin.com/ml/cygwin/2009-07/msg00890.html >> > > Ping? This problem is fixed with perl5.10.1-5 perl-Tk 804.030-1 Thanks! -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: perl-Tk widget broken again on perl 5.10.1-5
Thrall, Bryan wrote on 2012-01-25: > perl-Tk's widget works just fine with > > perl5.10.1-3 > perl-Tk 804.028-3 > > but if I upgrade to perl 5.10.1-5, widget breaks again[1] with the following > errors repeated until the process is killed: > > Use of uninitialized value $id in hash element at > /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 39. > Use of uninitialized value $id in delete at > /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/After.pm line 87. > > perl-Tk 804.029-1 works just fine with perl 5.10.1-3. > > cygcheck -svr output attached. > > Thanks. > > [1] Original report threads here: > > http://cygwin.com/ml/cygwin/2009-03/msg00800.html > http://cygwin.com/ml/cygwin/2009-07/msg00890.html > Ping? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: svn2cl (subversion-tools 1.7.3-1) fails to load svn2cl.xsl
David Rothenberger wrote on 2012-02-20: > subverison-tools-1.7.3-2 is available now with that patch restored. Thanks! I can confirm that fixes the problem on my end :) -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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
svn2cl (subversion-tools 1.7.3-1) fails to load svn2cl.xsl
It thinks the svn2cl.xsl file should be in /usr/bin, but it looks like the file is in /etc/svn2cl: $ svn2cl warning: failed to load external entity "/usr/bin/svn2cl.xsl" cannot parse /usr/bin/svn2cl.xsl $ cygcheck -l subversion-tools | grep svn2cl.xsl /etc/svn2cl/svn2cl.xsl $ cygcheck -cd subversion-tools Cygwin Package Information Package Version subversion-tools 1.7.3-1 Creating a symlink /usr/bin/svn2cl.xsl -> /etc/svn2cl/svn2cl.xsl works around the problem. Thanks, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: man redirect error
Reid Thompson wrote on 2012-01-04: > On Wed, 2012-01-04 at 08:51 -0600, Thrall, Bryan wrote: >> Perhaps the OP was looking for something like apropos or whatis? >> >> Given that man already pipes its output through a pager, the OP could >> just use the MANPAGER environment variable to do what he wants: > > http://cygwin.com/cgi-bin2/package-grep.cgi?grep=apropos Yes, I know :-) I was trying to suggest apropos might be what the OP was trying to find while also providing a literal solution to his problem. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: man redirect error
Reid Thompson wrote on 2012-01-04: > On Tue, 2012-01-03 at 15:30 -0600, Nellis, Kenneth wrote: >> Thought maybe someone would be interested in the following error. >> >> $ man gcc | head >> GCC(1)GNU >> GCC(1) >> >> >> >> NAME >>gcc - GNU project C and C++ compiler >> SYNOPSIS >>gcc [-c|-S|-E] [-std=standard] >>[-g] [-pg] [-Olevel] >> Error executing formatting or display command. >> System command (cd "/usr/share/man" && (echo ".pl 11i"; /usr/bin/gunzip >> -c '/usr/share/man/man1/gcc.1.gz') | /usr/bin/tbl | /usr/bin/nroff -c >> -mandoc 2>/dev/null | /usr/bin/less -isrR) exited with status 36096. >> No manual entry for gcc >> $ > > > probably not. Why are you wanting to head the output? Man already > displays using a pager. Perhaps the OP was looking for something like apropos or whatis? Given that man already pipes its output through a pager, the OP could just use the MANPAGER environment variable to do what he wants: $ MANPAGER=head man gcc GCC(1)GNU GCC(1) NAME gcc - GNU project C and C++ compiler SYNOPSIS gcc [-c|-S|-E] [-std=standard] [-g] [-pg] [-Olevel] Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
RE: Permission denied but have permission
Lou U wrote on 2011-09-21: > > I am a newbie running cygwin on Windows 7. I want to run an installer > for graphics software, Dislin, viz. > > $./setup.exe > bash: ./setup.exe Permission denied Windows 7 has something called UAC[1] which forces you to run anything called 'setup.exe' with Administrator privileges. You either need to disable UAC or run the installer from Windows Explorer or a command prompt. [1] http://en.wikipedia.org/wiki/User_Account_Control Hope this helps, -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com -- 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: Symlink to drive and space in directory name leads to DOS warning
Eric Blake wrote on 2011-05-02: > On 05/02/2011 10:04 AM, Thrall, Bryan wrote: >> AFAIK, I am not using bash-completion; the package is installed, but > I don't source /etc/bash_completion in my ~/.bashrc. > > You don't have to manually source it in ~/.bashrc - these days, merely > installing bash-completion adds /etc/profile.d/bash_completion, which is > automatically sourced for all interactive bash shells. Ah, yes, I missed that in my scan of 'cygcheck -l bash-completion' :) >>> $ set -vx >>> $ pushd ~/myuserdrv/My\ Down[TAB] >>> >>> might give me some insight where to look at plugging the leak? >> >> I don't think there's much help there, unfortunately: >> >> thrall@pc1163-8413-xp ~ >> $ set -vx >> settitle >> ++ settitle >> ++ echo -ne '\033]0;bash\007' >> thrall@pc1163-8413-xp ~ >> $ pushd ~/myuserdrv/My\ Downcygwin warning: > > Well, it _does_ help. 'complete -p pushd' shows 'complete -d pushd', > which is the setting installed by bash-completion. But the pushd > default completions mean that the problem is in bash itself, not in > bash-completion. So it gives me somewhere further to look. Thanks for taking a look! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- 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: Symlink to drive and space in directory name leads to DOS warning
Eric Blake wrote on 2011-05-02: > On 05/02/2011 09:30 AM, Thrall, Bryan wrote: >> When I try to do a tab-completion on a directory with a space in it > for the first time after starting Cygwin, I get a DOS warning even > though I'm not using a DOS path. This only seems to happen when I > access the directory through a symlink I have to my E: drive, like so: >> >> thrall@pc1163-8413-xp ~ >> $ pushd ~/myuserdrv/My\ Downcygwin warning: >> MS-DOS style path detected: ~/myuserdrv/My\ Downloads Preferred POSIX >> equivalent is: ~/myuserdrv/My/ Downloads CYGWIN environment variable >> option "nodosfilewarning" turns off this warning. Consult the user's >> guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > > Are you using bash-completion? If so, it's likely a bug in > bash-completion for passing an underquoted file name through the shell > such that it results in a failed globbing attempt on a literal \. AFAIK, I am not using bash-completion; the package is installed, but I don't source /etc/bash_completion in my ~/.bashrc. > I haven't yet managed to reproduce this in my setup (perhaps I need to > double-check that my $CYGWIN hasn't already suppressed the warning?). > Maybe showing: > > $ set -vx > $ pushd ~/myuserdrv/My\ Down[TAB] > > might give me some insight where to look at plugging the leak? I don't think there's much help there, unfortunately: thrall@pc1163-8413-xp ~ $ set -vx settitle ++ settitle ++ echo -ne '\033]0;bash\007' thrall@pc1163-8413-xp ~ $ pushd ~/myuserdrv/My\ Downcygwin warning: MS-DOS style path detected: ~/myuserdrv/My\ Downloads Preferred POSIX equivalent is: ~/myuserdrv/My/ Downloads CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames loads/ pushd ~/myuserdrv/My\ Downloads/ + pushd '/home/thrall/myuserdrv/My Downloads/' ~/myuserdrv/My Downloads ~ settitle ++ settitle ++ echo -ne '\033]0;bash\007' (settitle is my function to set the window title; PROMPT_COMMAND is set to it) It does seem to be limited to tab-completion, though; if I type in the full directory name (~/myuserdrv/My\ Downloads) and hit enter, I don't get the warning. E: is a partition of my local drive, in case it matters. -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- 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 2008 64-bit install
Jeremy Bopp bopp.net> writes: > Could this be related to this earlier thread? > > http://cygwin.com/ml/cygwin/2010-09/msg00212.html > > -Jeremy I think you're right, Jeremy. Once I stopped looking for my specific error message, it seems this is just a general problem with AWS images. And Amazon is silent on the issue. Sad. For now, I guess I'm just going to use KpyM for my SSH server. -- 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 2008 64-bit install
Thorsten Kampe thorstenkampe.de> writes: > I'd just delete everything and do a fresh minimal installation. If this > fails again, you can continue here. First check > http://cygwin.com/faq/faq.using.html#faq.using.bloda I'll do my best, but my order of operations when I got the failure was: 1) Spin up a brand new EC2 Windows 2008 64-bit instance 2) Log in 3) Install Cygwin I literally did nothing else. So, if there is some dodgy software causing an issue, I may not have the luxury of uninstalling it. I haven't tried it myself, but I am told the same does NOT happen on a 32-bit W2K8 instance. Thanks, Bryan -- 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 2008 64-bit install
Thorsten Kampe thorstenkampe.de> writes: > Why don't you simply run (at least) one of the scripts manually and see > if you see an error?! I ran them all, with the following results: bash-3.2# /etc/postinstall/000-cygwin-post-install.sh bash-3.2# /etc/postinstall/base-files-mketc.sh bash: /etc/postinstall/base-files-mketc.sh: Permission denied bash-3.2# /etc/postinstall/base-files-profile.sh bash: /etc/postinstall/base-files-profile.sh: Permission denied bash-3.2# /etc/postinstall/bash.sh bash-3.2# /etc/postinstall/coreutils.sh bash-3.2# /etc/postinstall/joe.sh bash-3.2# /etc/postinstall/man.sh bash-3.2# /etc/postinstall/terminfo.sh Segmentation fault (core dumped) bash-3.2# /etc/postinstall/terminfo0.sh bash-3.2# > > Following some suggestions, I turned off DEP, but the problem > > persists. > > UAC is much more likely a problem. UAC is the first thing I turn off when spinning up a new machine :) I'm not an expert at this...I usually just install, configure the SSH server, and go about my business. I've never had it not work before. I managed to run all but 3 of the postinstall scripts manually, and that has restored some basic functionality (e.g., before this, I couldn't even run the "ls" command without a "command not found" error). I'm leery of going through the SSH server install in this state. -- 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
Windows 2008 64-bit install
I'm trying to install Cygwin on a stock Amazon EC2 Windows 2008 64-bit image. At the end of setup, I get a dialog that says "Postinstall script errors" with the following information in it: Package: Unknown package 000-cygwin-post-install.sh exit code -1073741819 base-files-mketc.sh exit code -1073741819 base-files-profile.sh exit code -1073741819 bash.sh exit code 35584 coreutils.sh exit code -1073741819 joe.sh exit code -1073741819 man.sh exit code -1073741819 terminfo.sh exit code 35584 terminfo0.sh exit code -1073741819 Some Googling revealed someone else with the identical problem, but no resolution. Following some suggestions, I turned off DEP, but the problem persists. I put all the logs in a zip file here: http://www.slatner.com/quick/cygwinresults.zip Any assistance would be greatly appreciated. -- 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: ATTN: Perl maintainer - RE: Problem with Perl/Tk and Pixmap
Reini Urban wrote on 2010-12-22: > 2010/12/22 Thrall, Bryan: >> Thrall, Bryan wrote on 2010-12-16: >>> Andrew DeFaria wrote on 2010-12-16: >>>> On 12/16/2010 02:07 PM, Johannes v. Löwis wrote: >>>>> I have a Perl/Tk script that is supposed to show a pixmap on the >>>>> left side of the title bar of the main window. It works on Linux and >>>>> on a rather old version of Cygwin 1.5. On Cygwin 1.7 (on XP Home and >>>>> Prof) the following happens: >>>>> >>>>> $ ./logotest.pl Can't bless non-reference value at >>>>> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Image.pm line 23. ... >>>>> Any ideas or suggestions what further information I could provide in >>>>> order to sort this out? >>>>> >>>> Reproduced. Note you problem appears to be with Tk::Image, not with >>>> Cygwin, though you are right in that it works on Linux and complains >>>> and dies on Cygwin. >>>> >>>> Interestingly, if you run your program and the Perl debugger (i.e. >>>> perl -d logtest.pl) then simply type c for continue it works fine. >>>> >>>> Looking at Image.pm I see that if I break at Image.pm:23 there's a >>>> "return bless $obj,$package" statement. In the debugger, $obj is >>>> defined and there's no problem. If, however, I just run this without >>>> the debugger, but put some print statements in Image.pm, I see that >>>> $obj is indeed returned from $widget->Tk::image as undefined. >>>> >>>> This appears to be a Perl/Tk bug. >>>> >>>> Even stranger! Change your >>>> >>>> $mw->Pixmap('logo', -data=>$icon); >>>> to >>>> >>>> my $foo $mw->Pixmap('logo', -data=>$icon); >>>> and it works! So you have a work around, and a bug to report. >>> >>> I also can reproduce the problem. >>> >>> This behavior reminds me of a perl-Tk packaging bug from last year: >>> >>> http://www.cygwin.com/ml/cygwin/2009-07/msg00890.html >>> >>> In fact, /usr/bin/widget seems to be broken again, unless you run it >>> in the perl debugger: >>> >>> thr...@pc1163-8413-xp ~ >>> $ /usr/bin/widget >>> Can't set -labelFont to `Courier 12 bold' for >>> Tk::LabEntry=HASH(0x1067dac0): unknown option "-labelFont" at >>> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 294. >>> >>> at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 306 >>> thr...@pc1163-8413-xp ~ $ cygcheck -cd perl perl-Tk Cygwin Package >>> Information Package Version cygwin 1.7.7-1 >>> perl 5.10.1-4 perl-Tk 804.029-1 >>> >> >> It seems I have unfairly blamed Perl-Tk for these problems; reverting > to perl-5.10.1-3 fixes both the OP's Pixmap problem and the widget > problem on my machine. > > I hear. > Known problem with certain XS modules. > > With -4 I had to recompile core and all XS modules and apparently some > old modules are not binary compatible anymore, although the > configuration did not change. Only the environment did change. > > The solution is to recompile the failing XS modules or revert perl back > to -3 > perl-Tk would need an upgrade against -4. I'm just glad to have a workaround :) Thanks for the explanation! -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- 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
ATTN: Perl maintainer - RE: Problem with Perl/Tk and Pixmap
Thrall, Bryan wrote on 2010-12-16: > Andrew DeFaria wrote on 2010-12-16: >> On 12/16/2010 02:07 PM, Johannes v. Löwis wrote: >>> I have a Perl/Tk script that is supposed to show a pixmap on the left >>> side of the title bar of the main window. It works on Linux and on a >>> rather old version of Cygwin 1.5. On Cygwin 1.7 (on XP Home and Prof) >>> the following happens: >>> >>> $ ./logotest.pl Can't bless non-reference value at >>> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Image.pm line 23. ... >>> Any ideas or suggestions what further information I could provide in >>> order to sort this out? >>> >> Reproduced. Note you problem appears to be with Tk::Image, not with >> Cygwin, though you are right in that it works on Linux and complains >> and dies on Cygwin. >> >> Interestingly, if you run your program and the Perl debugger (i.e. perl >> -d logtest.pl) then simply type c for continue it works fine. >> >> Looking at Image.pm I see that if I break at Image.pm:23 there's a >> "return bless $obj,$package" statement. In the debugger, $obj is >> defined and there's no problem. If, however, I just run this without >> the debugger, but put some print statements in Image.pm, I see that >> $obj is indeed returned from $widget->Tk::image as undefined. >> >> This appears to be a Perl/Tk bug. >> >> Even stranger! Change your >> >>$mw->Pixmap('logo', -data=>$icon); >> to >> >>my $foo $mw->Pixmap('logo', -data=>$icon); >> and it works! So you have a work around, and a bug to report. > > I also can reproduce the problem. > > This behavior reminds me of a perl-Tk packaging bug from last year: > > http://www.cygwin.com/ml/cygwin/2009-07/msg00890.html > > In fact, /usr/bin/widget seems to be broken again, unless you run it in > the perl debugger: > > thr...@pc1163-8413-xp ~ > $ /usr/bin/widget > Can't set -labelFont to `Courier 12 bold' for > Tk::LabEntry=HASH(0x1067dac0): unknown option "-labelFont" at > /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 294. > > at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 306 > thr...@pc1163-8413-xp ~ > $ cygcheck -cd perl perl-Tk > Cygwin Package Information > Package Version > cygwin 1.7.7-1 > perl 5.10.1-4 > perl-Tk 804.029-1 > It seems I have unfairly blamed Perl-Tk for these problems; reverting to perl-5.10.1-3 fixes both the OP's Pixmap problem and the widget problem on my machine. Hope this helps, -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- 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 Perl/Tk and Pixmap
Andrew DeFaria wrote on 2010-12-16: > On 12/16/2010 02:07 PM, Johannes v. Löwis wrote: >> I have a Perl/Tk script that is supposed to show a pixmap on the left >> side of the title bar of the main window. It works on Linux and on a >> rather old version of Cygwin 1.5. >> On Cygwin 1.7 (on XP Home and Prof) the following happens: >> >> $ ./logotest.pl Can't bless non-reference value at >> /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Image.pm line 23. ... >> Any ideas or suggestions what further information I could provide >> in order to sort this out? >> > Reproduced. Note you problem appears to be with Tk::Image, not with > Cygwin, though you are right in that it works on Linux and complains and > dies on Cygwin. > > Interestingly, if you run your program and the Perl debugger (i.e. perl > -d logtest.pl) then simply type c for continue it works fine. > > Looking at Image.pm I see that if I break at Image.pm:23 there's a > "return bless $obj,$package" statement. In the debugger, $obj is defined > and there's no problem. If, however, I just run this without the > debugger, but put some print statements in Image.pm, I see that $obj is > indeed returned from $widget->Tk::image as undefined. > > This appears to be a Perl/Tk bug. > > Even stranger! Change your > >$mw->Pixmap('logo', -data=>$icon); > to > >my $foo $mw->Pixmap('logo', -data=>$icon); > and it works! So you have a work around, and a bug to report. I also can reproduce the problem. This behavior reminds me of a perl-Tk packaging bug from last year: http://www.cygwin.com/ml/cygwin/2009-07/msg00890.html In fact, /usr/bin/widget seems to be broken again, unless you run it in the perl debugger: thr...@pc1163-8413-xp ~ $ /usr/bin/widget Can't set -labelFont to `Courier 12 bold' for Tk::LabEntry=HASH(0x1067dac0): unknown option "-labelFont" at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 294. at /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/Tk/Derived.pm line 306 thr...@pc1163-8413-xp ~ $ cygcheck -cd perl perl-Tk Cygwin Package Information Package Version cygwin 1.7.7-1 perl 5.10.1-4 perl-Tk 804.029-1 -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com -- 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: Permissions on Windows 2008
Jeremy Bopp bopp.net> writes: > Take a look at the noacl option. You'll want to apply that to whatever > mountpoint contains the target path of your copy operation. If you want > to be surgical in the application, create a new mountpoint with this > option set and copy your files into paths within it. Otherwise, you can > apply it to the cygdrive mountpoint so that the option applies to any > path under /cygdrive and UNC paths. > > I'm not sure if it's possible to change the mount options of /, > /usr/bin, or /usr/lib since those mountpoints are implicitly defined. > Setting this option on them would probably break things anyway. If your > target path is currently something like /home/whatever, set up a new > mountpoint with the noacl option and copy to that instead. Ah, now, THAT did the trick. I left the default cygdrive alone and created a new mountpoint with the noacl option. Now it does exactly what I want it to when files are uploaded into that directory. Thanks again, Jeremy! -- 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: Permissions on Windows 2008
Jeremy Bopp bopp.net> writes: > By default Cygwin tries to emulate POSIX file permissions: > > http://cygwin.com/cygwin-ug-net/ntsec.html > > You can disable this by modifying your /etc/fstab file and adding the > appropriate options to cause the target locations for your files to have > the necessary options: > > http://cygwin.com/cygwin-ug-net/using.html#mount-table > > Specifically, you may need to modify the settings for the cygdrive > mountpoint: > > http://cygwin.com/cygwin-ug-net/using.html#cygdrive Jeremy, I guess I spoke too soon. I'm not really sure which fstab options are appropriate here. Are you suggesting modifying the cygdrive mount, or adding a new one with some different options? I'm not really clear how to proceed here or which are the relevant options. -- 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