[ANNOUNCEMENT] Updated: libfakesu 1.2.0
Version 1.2.0-0 of "libfakesu" has been uploaded. This library simulates the Unix root user. It is meant to make porting Unix programs to Cygwin easier. Many Unix daemon programs, such as Apache, Sendmail and Procmail, start up as root but change to an unprivileged user ID. By including this library, any Cygwin super-user (member of the 'Administrators' group) will be represented with user id '0' to your program. Version 1.2.0 * added the following functions: fstatat * addedd the /usr/bin/fakesu command for finding occurrances of the uid functions implemented in libfakesu * split fakesu.h into separate include files, so patching can be automated with sed. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: xfig-3.2.5c-2.x86_64 crashes on save as or export on windows 10
Jon Turney skrev: On 29/10/2015 19:11, Hans-Georg Scherneck wrote: it crashes on x_86 (i.e. 32 bit version) too, even after re-installing the xorg-server packages. xfig won't show the export window before it crashes. What else can I do? Any step-by-step procedure with xorg-server renewal? Is there an issue with Athena widgets? I'd suggest, as an alternative workaround, with the current server: ln -s /usr/share/X11/fonts/75dpi /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:pri=40 This was enough for me to get xfig to not crash when showing it's file open dialog. It seems that xfig requires the font '*-times-medium-r-normal--16-*' for that dialog, but that is not one of the sizes provided by xorg/font/adobe-*dpi (14 and 17 are the nearest), so we have to allow this font to be scaled (or provide a scalable font which also matches that XLFD) One could wish for xfig to provide a clearer indication of the problem rather that just segfaulting. (I note that xfig's file open dialog seems to hang if we navigate to the root directory, but I guess that is a separate issue) Jon, PROBLEM SOLVED thanks to your suggestion, this was indeed the heart of the problem. The symlink solved the problem in a breeze. Great many thanks. I hope, when this mail converation is recorded in the cygwin discussion forum it solves the headaches of many other frustrated xfig users too. -- Med vänliga hälsningar / With best regards yours - Hans-Georg Scherneck / A \ -+--- | / \ | . Telephone & -fax | Chalmers University of Technology \ / . +46 31 772 5556| Earth and Space Sciences - . +46 31 772 5590 fx | & Onsala Space Observatory | | . E-Mail:| SE-439 92 Onsala, Sweden / \ . h...@chalmers.se| http://www.chalmers.se/rss . Ocean Loading Serv.| holt.oso.chalmers.se/loading /===\ ,===//===\ . Gravimeter | holt.oso.chalmers.se/hgs/SCG//`===,// -+-\===//===' \===/ -- 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 in collation functions?
On 10/30/2015 10:07 AM, Ken Brown wrote: Hi Corinna, On 10/30/2015 8:03 AM, Corinna Vinschen wrote: On Oct 29 18:21, Ken Brown wrote: The fallback I had in mind is to return the shorter string if they have different lengths and otherwise to revert to wcscmp. > I had a longer look into this suggestion and the below code and it took me some time to find out what bugged me with it: What about str/wcsxfrm? Per POSIX, calling strcmp on the result of strxfrm is equivalent to calling strcoll (analogue with wcs*). If you extend *coll to perform an extra check on the length, you will have cases in which the above rule fails. You can't perform the length test on the result of *xfrm and expect the same result as in *coll. In fact, when calling LCMapStringW with NORM_IGNORESYMOLS (you would have to do this anyway if we add this flag in *coll), the resulting transformed strings created from the input strings "11" and "1.1" would be identical, so a length test on the xfrm string is not meaningful at all. The bottom line is, afaics, we must make sure that CompareStringW and LCMapStringW are called the same way, and their result/output has to be returned to the caller. Performing an extra check in *coll which can't be reliably performed in *xfrm is not feasible. Does that make sense? Yes, I see the problem, and I don't see a good way around it. So I think we probably have to leave things as they are and live with the fact that we can't do comparisons that ignore whitespace and punctuation. The alternative of allowing str/wcscoll to return 0 on unequal strings doesn't seem feasible in view of Eric's comments. I have one other idea. What would you think of defining a function cygwin_strcoll that's like strcoll but with an extra bool parameter 'ignoresymbols'? If ignoresymbols = false, this would be the same as strcoll. If ignoresymbols = true, this would use NORM_IGNORESYMBOLS with the fallback I suggested. That way applications that prefer to be more glibc-compatible and don't need strxfrm could do something like #define strcoll(A,B) cygwin_strcoll ((A), (B), true) If you think this is reasonable, I'll submit a patch. If not, no problem. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: xfig-3.2.5c-2.x86_64 crashes on save as or export on windows 10
On 29/10/2015 19:11, Hans-Georg Scherneck wrote: it crashes on x_86 (i.e. 32 bit version) too, even after re-installing the xorg-server packages. xfig won't show the export window before it crashes. What else can I do? Any step-by-step procedure with xorg-server renewal? Is there an issue with Athena widgets? I'd suggest, as an alternative workaround, with the current server: ln -s /usr/share/X11/fonts/75dpi /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:pri=40 This was enough for me to get xfig to not crash when showing it's file open dialog. It seems that xfig requires the font '*-times-medium-r-normal--16-*' for that dialog, but that is not one of the sizes provided by xorg/font/adobe-*dpi (14 and 17 are the nearest), so we have to allow this font to be scaled (or provide a scalable font which also matches that XLFD) One could wish for xfig to provide a clearer indication of the problem rather that just segfaulting. (I note that xfig's file open dialog seems to hang if we navigate to the root directory, but I guess that is a separate issue) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to run xinit without first entering a cygwin terminal
On 30/10/2015 00:40, Xuehan Xu wrote: Thanks for your reply:-) I followed your advice, now it seems that rdesktop is running, but the window that xinit showed was just plain black. rdesktop is supposed to be a remote desktop client that runs on linux and connect to a windows remote desktop. When I use the command "/usr/bin/xinit.exe ./rdesktop/rdesktop.exe -f 192.168.1.79" in a cygwin terminal, it can show the desktop of 192.168.1.79. Could this be due to the same reason that startx can't show the cygwin desktop? What should I do? Thanks;-) Hmm... so when I try this, it seems it only works when I arrange for rdesktop's stderr to go somewhere, e.g. C:\cygwin64\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit /usr/bin/rdesktop -f byron >/var/log/xwin/rdesktop_session.log 2>&1" If that's really necessary, perhaps that's a bug in run. (You do know that you could achieve a similar effect with 'mstsc /f /v:byron' ?) On 29 October 2015 at 21:23, Jon Turney wrote: On 29/10/2015 06:25, Xuehan Xu wrote: Hi, everyone I'm trying to run xinit.exe to start a GUI program in a windows cmd prompt. The command I run: "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe /home/Administrator/rdesktop.exe -f 192.168.1.79 But, it seems that rdesktop.exe isn't running, the window was just showing a terminal prompt. Using the command lines from the start menu items created for the xinit package as a template (see [1]), I think you need something like: c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe /home/Administrator/rdesktop.exe -f 192.168.1.79" The command string being given to bash -c needs quoting, otherwise subsequent words are assumed to be parameters to that command. This reason is wrong. I should have said something like "needs quoting to get correctly passed to bash" since I think the issue is not in bash, but in run. run needs to be given the -quote option to protect those quotes. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
