Re: Most git executables are hard links to git.exe?
On 2023/07/22 10:35, Jim Garrison via Cygwin wrote: On 07/22/23 10:33, Adam Dinwoodie wrote: On Fri, 21 Jul 2023 at 22:54, Jim Garrison via Cygwin wrote: On 07/21/23 14:52, Brian Inglis wrote: On 2023-07-21 14:59, Jim Garrison via Cygwin wrote: Git comes with over 100 executables, mostly in /usr/libexec/git-core, that all appear to be *hard* links to /bin/git, in both Cygwin and Windows. The Windows fsutil command shows they're all hard linked: [snip] I'm curious to know if there's a specific reason for this implementation that would make it the choice over symbolic links. The hardlink implementation on windows is very similar to the implementation on linux. I'm pretty sure that utils that want to save on space will look at the inode-number and notice that the hardlinked files all have the same inode-number (windows has a similar concept though it is called something else). On linux, utils that are ignorant of inode numbers, will see hardlinked files as separate files -- just as windows does. The symlink files will break if their targets move (same on lin+win). -- 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: Map home dir drive (H:) to /home/myuser/ ?
On 2023/07/28 21:24, Roland Mainz via Cygwin wrote: Good morning! Does Cygwin have a way to map a (NFS) home dir drive (H:) to /home/myuser/, without resorting to POSIX-style softlinks ([1]) ? Example: 1. Home dir mounted on drive H: via NFS 2. How do I now map H: to /home/myuser/ ? For example Linux and Solaris use the automounter to mount NFS dirs directly to /home/myuser/ , and Solaris uses lofs (loopback filesystem) to mount a local users home dir /export/home/myuser/. Does Cygwin have a similar facility for drives represented by drive letters (e.g. H: [2]) ? --- Not really -- as the automounter and lofs are OS features in linux that are not in Windows. Windows can do similar if you have a Windows server that provides smbfs/cifs mounts. I do the same with a linux-samba server that provides a home-directory service to users, but Windows requires a server of some sort to provide some of these things, AFAIK. In my setup, though, 'h' provides the home directory of the user ON the samba server -- different the "local home dir". What you want, sorta CAN be done in that samba can also provide a user dir that provides scripts that get read into a user environment that can set the home dir through the environment. But setting "USERPROFILE" and such would have to be done/user -- maybe as part of creating a Domain that can controll users+logins. I did that ages ago when Win7 first came out -- and am not sure what new facilities there are for doing that, other than I think Win10/11 can't really be part of a Domain -- only business versions of them. Remember, NFS isn't a Windows technology so I wouldn't expect it to give you much in the way of Win-compatible feature -- though it might give you more feature if you limit yourself to the POSIX subsystem -- not sure how that works with Win10/11's linux subsystem (or if it does at all). -- 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: Can not stat file with utf char U+F020
I'm a bit confused as to what char you are trying to access/use, as U+F020 is in the Private Use area (PUA) Since it's in the PUA, it seems its meaning could differ by application/OS/User, no? I.e. have no set definition I mean you can use it in Cygwin to represent some character not usually permitted in a DOS/Win filename (like :/\, etc.), but it wouldn't have the same meaning then in Windows though.? Isn't Private Use area application specific so an application can create and use its own symbol set -- even though it wouldn't be portable to another application. So if you create a character in Cygwin that maps to that area -- how would you expect Windows to know that the character is and how treat it? I think characters in the PUA range are used to allow Cygwin filenames to contain colon, slashes and quotes -- so one wouldn't want Windows to understand the cygwin intent or it would defeat the purpose of using custom characters to represent filenames that are legal under POSIX but not under Windows. -- 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
[SOLVED] Re: mirror corruption, or non-backward compatible library change?
On 2023/03/21 09:13, L A Walsh via Cygwin wrote: Connected to kernel.org as I normally do, but got this: Internal Error: gcrypt library error 1 unsupported pk alg. --- Using most recent version of setup.exe from cygwin.com solved the problem. Sorry for bogon. -- 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
mirror corruption, or non-backward compatible library change?
Connected to kernel.org as I normally do, but got this: Internal Error: gcrypt library error 1 unsupported pk alg. [OK] Then another popup: Mirror Error: Setup.ini signature http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2.sig from http://mirrors.kernel.org/sourceware/cygwin/ failed to verify. Possible corrupt mirror? Setup.ini rejected. It looks like I'm getting this popup with each package I have installed. Any idea what might be wrong? Really a corrupt mirror? Or did I miss a gcrypt library update that supports new signatures, but that I can't get because the update that provides this is signed with the new algorithm? Ideas? Thanks! -- 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
checking cyg version (was Re: GNU make losing jobserver tokens)
On 2022/03/21 08:09, Ken Brown wrote: For starters, is your Cygwin installation up to date? Cygwin's internal implementation of pipes was overhauled starting with cygwin-3.3.0. How does one check the version of cygwin? I've updated cygwin files this year, but if I use cygcheck -V, I only see cygwin-3.2, which looks to be from last year. Is that they right way to check the cygwin version? thanks! -linda -- 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: inotify cannot be used, reverting to polling: Too many open files
New message in tail: Anyone else seen this type of message lately:? tail -f .*log|wc tail: inotify cannot be used, reverting to polling: Too many open files It doesn't seem to be a big issue, but thought I should mention it... -- 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: Removing ^X in paths
On 2022/02/02 20:12, Dennis Heimbigner wrote: I am using 64bit. And it has nothing to do misreading characters. The ^X is described in this document: https://www.cygwin.com/cygwin-ug-net/using-specialnames.html, Wow, I've never seen such a pathname. What's an example of a filename that cygwin displays this way? -- 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: ls -C broken
On 2022/01/28 07:46, Thomas Wolff wrote: If I redirect output of `ls -C` (file / pipe), it used to produce well-formatted output in columns. Suddenly it produces garbage formatting instead. As `ls` itself is not new, maybe it's some library that breaks behaviour? Or even pty code?? Works on Cygwin 32-bit. Any idea? Thomas --- The authors of Gnu ls changed 'ls' defaults because "they can". Old ls -C: /bin/ls /proc 331 379 913 filesystems mounts registry32 swapsversion 332 500 cpuinfo loadavg net registry64 sys 335 731 cygdrive meminfo partitions selfsysvipc new ls -C: /bin/ls /proc|cat 331 332 335 370 379 500 731 732 945 946 cpuinfo cygdrive devices filesystems loadavg meminfo misc mounts net partitions registry registry32 registry64 self stat swaps sys sysvipc uptime version --- with column: law.Bliss> /bin/ls /proc|column (tabs mismatch) 331 731 devices net stat 332 732 filesystems partitions swaps 335 952 loadavg registry sys 370 953 meminfo registry32 sysvipc 379 cpuinfo miscregistry64 uptime 500 cygdrive mountsselfversion with column+expand -8: s> /bin/ls /proc|column|expand -8 1021379 devices net stat 1022500 filesystems partitions swaps 331 731 loadavg registrysys 332 732 meminfo registry32 sysvipc 335 cpuinfo miscregistry64 uptime 370 cygdrivemounts selfversion --- several other tools no longer have settings to expand tabs to user-values requiring the use of expand. Formats of numeric output were also changed, requiring usage of 'numfmt' This was all done to benefit script consistency at the expense of users usability. It is expected that users can adapt to the computers. by default, 'ls' will produce different output when it goes to the screen vs. when it goes to a pipe. When 'ls' goes to a pipe it is required to only use 1 column. To get the behavior you want, try piping through 'column' first (see 'man (1) column). They made many changes in core-utils to make automated shell scripts more consistent at the expense of user-usability where they now suggest using pipes into other utilities to get previous output Try using ls|column. Of course ls also used to expand tabs to every 8 characters and it no longer does that. So you must use another util 'tabs' to set tabs to every 8th column (ls's standard tab setting) -- 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: Removing ^X in paths
On 2022/02/02 12:40, Dennis Heimbigner wrote: It appears that windows now supports the UTF-8 codepage. It has since early 2000's. I light of this, it seems time to change cygwin so it no longer adds those control-x (^X) characters in e.g. path names. ^x is ASCII. Cygwin doesn't insert ^X characters in paths. Perhaps you are thinking of '\' which looks like ￥ (a capital 'Y' with 2 horizontal lines, (Fullwidth Yen Sign U+FFE5)...if that's the case, some 8-bit font displayed that sign instead of a backslash in non-unicode locals. Are you using a 32-bit or 64-bit version of Cygwin? on what version of windows? If you still use a 32-bit version, you might need to move to a 64-bit version. I know the 32-bit version sometimes had the problem because it supported fewer fonts and fewer characters at the same time. You might check out your locale (if in english, try setting: LC_CTYPE="en_US.UTF-8" in your shell and also check that your used font has a backslash in the 0x7f position. But in shell, ^x is usually a character to erase the whole line -- so it really wouldn't do to have it in a PATH. Hope this helps, and sorry if this is completely off base. Linda -- 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: Renaming (with 'mv') very large files is SLOW
On 2022/01/31 13:36, Adam Dinwoodie wrote: Could it be that the first 'mv' triggered an anti-virus read of the file since perhaps it detects it as a new/changed file? But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk activity? That definitely seems plausible; there's a reason a significant number of the applications that are known to interfere with Cygwin operation (see [0]) are antivirus applications. But what would trigger your antivirus to want to scan a file, and how much work is required to do that, is something you'll need to take up with your antivirus vendor, I'm afraid. Something that most people don't realize, is that windows always puts a lock on a file when it is going to READ it. It's an advisory lock, and usually, on a local file access, it can be removed by the user who started the read and it's not noticed. But if cygwin is accessing the file through some virtual table, Windows might think it is on a separate virtual device -- like an indexing scanner that indexes content, or anti-vir. This becomes real noticeable if it is a real remote file on a remote fs. In samba there's a setting to allow breaking advisory locks -- and if you are the only person who can be accessing that file, its best to allow them to be broken -- only real useful if you have multiple users (or programs) trying to modify the same file at the same time. If the oplocks are held by another process windows may return a 'file busy' so cygwin uses a file-copy method to 'move' the file. I usually only run into this locally when the file is opened by a system process when I try to modify it, like deleting a thumbs.db when explorer is updating it. The param in samba is "fake oplocks = yes", tells samba to fake oplocks and not really enforce them. It's a per-share parameter, so you need to set it on every share. But only on shares where you are the only 'modifier'. For actual shared-access w/other users -- only read-only access should be used. If you ever want to have local file caching of remote content work -- need to set the oplocks to fake or have the files be read-only. [0]: https://cygwin.com/faq/faq.html#faq.using.bloda -- 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: Cygwin/X display scaling corrupting font display of typed characters;
On 2022/01/21 10:26, L A Walsh wrote: ... To summarize, I am not sure that the original issue has anything to do with 2nd monitor, nor any changes in the Xorg-sources. In _my_ case it was a matter of how the Xserver was started, and what dpi settings it was started with. If server was started with incorrect dpi settings, it would cause problems with some Xclients having mangled or trunated characters at the bottom of their windows. For me, it was a matter of ensuring that my modified startX script was called instead of the stock script, as my modified script checks the windows DPI setting on startup. That said -- on Win10 it could be further complicated by having multiple monitors with different dpi settings. I seem to remember win10 having some provision for attaching a different DPI value to different monitors. That's likely to create a problem in 'X', since AFAIK, X hasn't been enhanced to allow different DPI values on different "screens". -- 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: Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-????
On 2022/01/19 17:01, Ken Whitesell wrote:
On 1/19/2022 2:28 PM, Jon Turney wrote:
On 19/01/2022 00:02, Ken Whitesell wrote:
On 1/17/2022 1:29 PM, Ken Whitesell wrote:
After more research and experimentation, it appears to be related to
one of xorg-server, xorg-server-common, or xorg-server-xorg.
Installing the older version 1.20.12-1 of these packages allows the
windows to be moved between monitors without any issues. Upgrading to
the current version 21.1.3-1 creates the problems. I'm able to
replicate this behavior on two different laptops with two different
external monitors.
It seems likely that this is an unintended effect of changes in
xorg-server 21.1.0-1, trying to fix problems in this area (See [1])
I am seeing this issue or one very much like it on Win7x64
But I have 1.20.12-1 of xorg-server + xorg-server{,-common,-debuginfo},
but I do not have xorg-server-xorg installed *at all*.
Mine has nothing to do with moving windows between monitors.
I'm seeing truncated windows on my main monitor (2560x1440).
My 2nd monitor is 1920x1080.
On boot, I start the Xserver by calling ~/bin/Xserver.sh
I use a modified Xserver.sh script that was no longer being called
due to a "Xserver.sh.lnk" being in ~/bin that pointed to the system
script in /bin. Ooops.
Upon fixing that problem, the problem of X-apps no longer updating correctly
disappeared.
My script has a few diffs and is missing the xauth stuff..
It's about 6 years old, and hasn't been cleaned up for public consumption,
but it works.
Point being, that for me, the problem seems to have been worked around
in the startup script.
Caveat -- my X-apps don't update in my 2nd window, so there's still some
lemon in my setup, but I haven't taken the time to figure it out as my 2nd
Screen is on the wall and used for video -- it's too far away for me to
read text on it, so I haven't bothered to chase down the lack of updates (I
can drag a window over to the 2nd screen and that displays fine, but
Xupdates
don't.
Getting it to work properly might be a problem since the DPI on the 2nd
monitor
is different than on the 1st one. I hear Win10 has allowances for different
DPI screens.
Thw two Xwin.logs are from the cygwin startup script (.orig) and my startup
script. The cygwin script seems end up sizing my 2560x1440 screen down to
1920x1080, which corresponds to the dead area in updating X-apps I was
seeing.
update
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.12.0
OS: CYGWIN_NT-6.1-7601 ATHENAE 3.2.0-340.x86_64 2021-03-29 08:42 UTC x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.20.12-1 built 2021-07-11
XWin was started with the following command line:
/usr/bin/XWin -dpi 120 -listen tcp -nopn +iglx -wgl -compositealpha
-compositewm -lesspointer -clipboard -ac -unixkill -nowinkill
-multiwindow -wm -ardelay 150 -arinterval 30 +bs -nomultimonitors
-hostintitle -noreset -logverbose 2 -fp
/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 2560 h 1440
winInitializeScreenDefaults - native DPI x 120 y 120
[438305.291] (II) xorg.conf is not supported
[438305.291] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more
information
[438305.291] (++) FontPath set to
"/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts"
[438305.291] LoadPreferences: Loading /Users/law.Bliss/.XWinrc
[438305.291] LoadPreferences: Done parsing the configuration file...
[438305.291] winDetectSupportedEngines - RemoteSession: no
[438305.369] winDetectSupportedEngines - DirectDraw4 installed, allowing
ShadowDDNL
[438305.385] winDetectSupportedEngines - Returning, supported engines 0005
[438305.385] winSetEngine - Multi Window or Rootless => ShadowGDI
[438305.385] winScreenInit - Using Windows display depth of 32 bits per pixel
[438306.883] winAllocateFBShadowGDI - Creating DIB with width: 2560 height:
1440 depth: 32
[438306.883] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[438306.883] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8
d 24 bpp 32
[438306.898] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[438307.163] (II) AIGLX: Testing pixelFormatIndex 5
[438307.273] GL_VERSION: 4.6.0 NVIDIA 441.41
[438307.273] GL_VENDOR: NVIDIA Corporation
[438307.273] GL_RENDERER:GeForce RTX 2080 Ti/PCIe/SSE2
[438307.273] (II) GLX: enabled GLX_SGI_make_current_read
[438307.273] (II) GLX: enabled GLX_SGI_swap_control
[438307.273] (II) GLX: enabled GLX_MESA_swap_control
[438307.273] (II) GLX: enabled GLX_SGIX_pbuffer
[438307.273] (II) GLX: enabled GLX_ARB_multisample
[438307.273] (II) GLX: enabled GLX_SGIS_multisample
[438307.273] (II) GLX: enabled GLX_ARB_fbconfig_float
[4383
Re: Phasing out old Windows versions and 32 bit support
On 2021/10/26 13:55, Corinna Vinschen via Cygwin wrote: Hi folks, The upcoming version 3.3.0 is the last version officially supporting Windows Vista and Windows Server 2008. The next major release 3.4.0 will be released in 2022 and will be the last one officially supporting Windows 7, Windows 8, Windows Server 2008 R2, and Windows Server 2012. Is that like 2022-Jan, or 2022-Dec? Sigh. -- 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: Prompt wrapping lines problems
On 2021/10/09 00:38, jp wrote: I'm very happy that you respond me. Yes, I've tried the solution suggested but I didn't succeed, but it doesn't matter now, because I've installed and old version of cygwin. Theese are the result of the command, but it will not help you because it comes from the old version of cygwin and not from the new one containing the bug. $ echo "$TERM" xterm me@me ~ $ stty -a speed 38400 baud; rows 22; columns 191; line = 0; ^^^>...That's awfully wide!!! normally you use 80 charcaters wide -- and the terminal you showed looked more like 80 characters, than 191. Bash may not be wrapping until 191, try setting columns to 80 (stty cols 80) and making sure your stty -a shows the same columns as your '$LINES' variable. About COLUMNS, I see: COLUMNS Used by the select compound command to determine the terminal width when printing selection lists. Automatically set if the checkwinsize option is enabled or in an interactive shell upon receipt of a SIGWINCH. This suggests that it might be necessary to have the checkwinsize variable set, since if you change the size of your bash window, it won't have anyway of knowing if that option is off -- 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: Prompt wrapping lines problems
Did you try the the solution suggested? I.e. What do you see if you type: echo "$TERM" How did you start your bash prompt? Also might be useful to send the output of: stty -a On 2021/10/06 03:35, jp via Cygwin wrote: Hello,I have the problem described in this page :https://superuser.com/questions/283236/cygwin-bash-prompt-is-wrapping-lines-on-the-same-line I've tried everything to solved this but I didn't succeed. I have to reinstall again a previous version of cygwin... So please, for the next version of cygwin, resolved this in the package, because it totally drive me crazy... Thanks a lot and thanks for your great work for the cygwin 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: Can't ssh to cygwin after switching sign-in to Windows Hello PIN
On 2021/09/15 12:53, Henry S. Thompson via Cygwin wrote: frankly, it seems like a bug, and if Microsoft succeeds in moving more people to using PINs for login, it will surely begin to bite others... Isn't the idea of using the PIN login to get rid of the use (and the ability) to use passwords? I agree with you that it is likely to cause problems, but creating a block to using a password seems to be intentional. It's a bit like some of the problems with the 'Oauth' system where one provider (like google) provides a way to allow you to login to other sites using your google authentication, but not requiring you give the "other site" a password. When I first read about it though, it seemed like the authorization process required web access for the authorization to be exchanged, but I'm not 100% sure about that. If it required web-auth, that has its own set of problems. -- 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
windows explorer links in cygwin /bin
I have about 99 ".lnk" files in my /bin dir. What are these for? They appear to be explorer links to various things, to list some files w/o the .lnk extension: ( /bin/ls -T 0 -x -w 96 |sed -r 's/\.lnk//g' ) Console2 a2ping a5toa4adhocfilelist amstexarara arlatex authorindex bibexport bundledoc cachepic chkweb cron_diagnose.sh ctanifyctanuploadde-macro dtxgendviasm dvigifdvilj6 So why are these in the /bin directory since they don't work on the command line (like in BASH). They do work in explorer, but most of them are console utilities. So why would ".lnk" files be used in cygwin packages since they don't work under cygwin, but are 'explorer' links. Note, these are not hard nor soft links as one might create with 'ln [-s]'. -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 2021/07/15 01:23, Sam Edge via Cygwin wrote: On 15/07/2021 08:02, L A Walsh wrote: On 2021/07/07 11:43, Andrey Repin wrote: Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. After wading through the unsolicited self-congratulation a few observations. 1. You want support from the Cygwin community for problems you're having despite having installed it in a way that is expressly discouraged. (https://cygwin.com/faq.html#faq.setup.c) Good luck with that. I pointed out a problem, didn't ask for support from people who blindly leap off clifs. 2. You've not bothered to search the archives or even read the manual, specifically https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files but instead immediately assume a flaw in the code. Not very scientific ... or polite. --- I have read such docs many times in the past. Cygwin is designed to be a POSIX implementation. POSIX supports ACLs as Linux implementations show. There are tons of ways of getting the behavior I noticed no matter where you put your cygwin directory. If you have OS mount points under your cygwin directory you can have the same problem. so it isn't specific to having your cygwin dir at root. I get that you don't know all the background and assume that the current user guide tells you everything. However some of us have been using Cygwin since before it supported ntsec (By the way, the permission workaround is another good reason for not installing in system root if advice from the authors of Cygwin - Corinna et al - isn't enough for you.) --- Except that at one point, most of the cygwin developers installed cygwin at '/'. That you don't know that shows how long you've been using cygwin. 3. Installing Cygwin under, say, C:\cygwin64 does not prevent you from using it for recovery. --- If you don't have the right options set in the registry, other directories outside of /windows can be inaccessible. I have other reasons for my setup. My windows system has most of my files on a remote, linux system. When I'm using the linux shell, for example, I can bring up explorer for the directory I'm in by typing 'explore [opt. path]'. My Doc dir, among others is the same on Windows as on Linux ~/Documents or /d/. If I'm running a prog on linux, and it asks for a browser, it launches my browser on Windows. In the past, I had both cygwin32 and cygwin64 installed in their own directories, because there was a brief time when the 64-bit version of windows and cygwin didn't have all the functionality of 32-bit cygwin, so automatic invocation of the right version was the only way to get full functionality on a 64-bit native install. My purpose in using Cygwin has been to use my linux experience and tools to help manage my Windows installation and to use my Windows system as my desktop for a combined linux+windows system. That doesn't work well if I install cygwin in a separate "corner" of the system where it is deceived about the root of its file system. Linux can deal with that as it supports arbitrary mounting. Cygwin doesn't in a way that Windows can see, so Cygwin has to use Windows mounting to have a coherent view of the file system. -- 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: Symlink issue?
On 2021/08/21 17:55, Brian Inglis wrote: On 2021-08-21 18:40, Thomas Wolff wrote: > > > Am 21.08.2021 um 23:59 schrieb Ken Brown via Cygwin: >> On 8/21/2021 4:15 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin >> wrote: >>> Hi, >>> Please consider the following Cygwin session: >>> $ cd ~ >> I don't know why bash completion suggests something different. My >> guess (and it's only a guess) is that bash completion takes a >> shortcut for performance reasons. --- cd w/completion uses the physical path because completion is an external "script", while "cd" alone uses bash's internal "logical" dir. > The symlink/.. confusion is a dreadful trap since Unix times. > Unfortunately, bash completion does not consider path resolution, so > if any, it's a bash completion bug. --- Not a bug or trap. It is a user choice to have 'cd' use logical paths instead of physical paths, whereas completion uses physical paths. You can get physical paths w/cd with "set -P", but most people find logical paths more friendly: /tmp> ln -s .. foo /tmp> cd foo# really cd's into '/' /tmp/foo> cd .. # but logically '/tmp/foo' /tmp> set -P# turns on physical paths w/cd /tmp> cd foo# now cd 'foo' puts you in physical '/' /> cd - # go back to last dir before 'cd' /tmp> set +P# turn off physical paths (logical back on) /tmp> cd foo /tmp/foo> cd .. /tmp> rm foo Or, as previously suggested. One time usage w/param to 'cd'. (Don't alias this, would be rather confusing) Try using cd -P (via alias?) which may resolve physically if it works. Otherwise enjoy the quirks of cd via symlinks and .. resolution after. It's not just '..', but also when you 'cd' into a mounted file system, then completion and other utils _may_ show you the contents of the dir the file system is mounted on. -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 2021/07/07 11:43, Andrey Repin wrote: What is "progd" ? Did you mount some directory into Cygwin tree? Sorta, actually the cygtree mounted at 'C:\'. Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. --- If you have something unexpected happening on your own computer, and you choose not to find the cause, you really don't know if it was a virus, malware or some other problem. I've had my directory tree mounted the way it is since Windows XP, and have tried to understand issues about computers that many term "magick" (or black magick). Being a computer scientist, I've always tried to understand what was going on. I don't always find out quickly, but I often return to problems that I haven't solved years later to sometimes find the cause, or sometimes find the problems have gone away. Considering my life has been about computers, opting out has really not been an option for me. Certainly, having it create no-access dirs for the user isn't desirable. I'm betting that they'd be denied locally as well if my local user didn't have admin override rights. It may be something in the parent directory. --- Nope... can't be, windows doesn't work that way. A directory can affect its contents, but permissions that are inherited can't skip a generation. or fstab mount options. --- I pretty much use the default: # /etc/fstab # #This file is read once by the first process in a Cygwin #process tree. To pick up changes, restart all Cygwin #processes. For a description #see https://cygwin.com/cygwin-ug-net/using.html#mount-table # This is default anyway: none / cygdrive binary,posix=0,user 0 0 Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout. --- What is more sane, ignoring a problem that was opted out of for 20 years, or understand what causes problems. I can't speak for Windows 10, but through Windows 7, especially in the X64 world, it makes little to no sense to cut your cygwin tools off from being able to access and work on your windows installation. If you have ever boot to a rescue system running from your hard drive -- you have the choice of using all your cygwin tools to recover your system, or to just use Windows tools. If you have 30+ years of unix/linux/posix experience with linux/posix tools, does it make any sense to throw that away when trying to recover your system? X64 Cygwin tools work natively when installed at root. Many of the Windows tools are still x32 which won't run on a rescue system. Linux xfs has 2 acls on directories -- one for the directory and one that can be the default for contents to inherit. It's not identical to windows, but it is similar and if you understand one, the other isn't that different. Cygwin has placed the most emphasis on POSIX compatibility vs. Windows compatibility. In some places it could have been more Windows compatible and still achieved POSIX compat. I do know, that if you have several added Deny acls added to every file, it can mess up default inheritance on content files. What windows has added to the mix has to be deleted -- special perms for creators (user+group). It's similar to default perms in linux, but it isn't the same. It is messed up, other devs have said so -- cygwin perms will conflict with windows perms when they are mixed. They've never tried to fix that. The result are utilities and permissions that have 'no access' set for 'creators' (usually owners). That's not a desired feature unless you opt out of using the windows GUI. But that's the main reason I use it, so what's the point? In any event, I know there are bugs in cygwin, but I don't care enough + know enough about windows development to fix them. That doesn't mean I opt out of using Cygwin or Windows (if I can help it), but it doesn't mean I won't report problems or bugs when I encounter them (doesn't mean I will either, depends on time). Anyway...opting out of understanding why things are or work they way they do is not something I can easily do, by nature. I'm too curious. (too much so, for the time I have to deal with things!). :-) Linda -- 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: objects created in a dir w/cygwin mangled perms; inherit no-access
On 2021/07/04 07:20, Andrey Repin wrote: The "+" at the end indicates presence of extended permissions. --- Ya, that's what I was referring to when I wrote about having 5 deny records at the front, though that didn't necessarily stand out. ⍨ Aside from the extended permissions, though, the net result was me getting a 'no access' when I tried to look into the directory with explorer. While I did have access via a local shell, I also have no-access from bash on a remote system (the samba domain controller on linux): > echo -n $(uname -n):;id |sed 's/groups.*//' Ishtar:uid=5013(law) gid=201(lawgroup) > ls -l newdir ls: reading directory 'newdir': Permission denied > ls -dl newdir dr-xrwxr-x 2 law lawgroup 0 Jul 6 05:20 newdir/ On local machine, same: > echo -n $(uname -n):;id |sed 's/groups.*//' Athenae:uid=5013(Bliss\law) gid=201(Bliss\lawgroup) ls -dxlF newdir d---rwxr-x+ 1 Bliss\law Bliss\lawgroup 0 Jul 6 05:20 newdir/ What getfacl says? # file: newdir # owner: Bliss\law # group: Bliss\lawgroup user::--- user:root:--- user:law:--- user:Astara:--- group::rwx group:SYSTEM:rwx group:Administrators:rwx group:Users:r-x mask::rwx other::r-x default:user::--- default:user:root:--- default:user:law:--- default:user:Astara:--- default:group::rwx default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask::rwx default:other::r-x What is "progd" ? Did you mount some directory into Cygwin tree? Sorta, actually the cygtree mounted at 'C:\'. So 2 Junctions and 1 symlinkd /Progd => /ProgramData/ /Prog => /Program Files (x86)/ /Prog64 => /Program Files/ Of course I can overide, but why are such weird acls on this anyway? -- especially when it doesn't seem to really work? Probably because of interpretation of the original Windows permissions. --- Not exactly, I don't think. Windows doesn't add "DENY" entries up front. Seems like there should be a better way since MS's subsystem for UNIX didn't seem to use all those DENY entries that I ever saw. Am guessing they somehow came from those default CREATOR U/G entries on the parent directory. This problem has been around for a few years. Certainly, having it create no-access dirs for the user isn't desirable. I'm betting that they'd be denied locally as well if my local user didn't have admin override rights. -- 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
objects created in a dir w/cygwin mangled perms; inherit no-access
Trying to track down exact conditions for a simpler testcase for a weird error message in tar and ran across this... in directory 'SI': /progd/Microsoft/../Tools/Sysinternals> ll -ad SI drwxrwxr-x+ 1 0 Jul 3 16:28 SI/ w/umask: umask 0002 I make dir 'newdir': mkdir newdir and ls -lgG shows: d---rwxr-x+ 10 Jul 3 16:40 newdir/ No access for user(me). I ran into this because trying to enter the directory in explorer I got no access! Trying to look at the perms, I get warnings about the rights possibly being out of order until eventually, if I want to proceed, it claims it has to reorder them. This seems to have come from some weird setting that seems to come from Cygwin, with 5 deny records at the front for NULL, 3 local accounts and 1 domain account (me)... and the local accts ... also me of a sort. Then come various allows, some of them that would seem to undo some of the denies, but its really dependent on order -- which explorer says is suspect... Fine...so the results when I did the "mkdir newdir", were such that ended up with u-wrx, and no access in explore? Of course I can overide, but why are such weird acls on this anyway? -- especially when it doesn't seem to really work? -- 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: bug in cygwin tar reading unexpected input(s)...
On 2021/06/16 10:22, Achim Gratz wrote: L A Walsh writes: 2019/02/07 22:53 DiskView [SI\DiskView.exe] and stems from the use of the --xattrs switch. Hmm. Looks like some of the symlink / attrs content is taking a route that doesn't deal correctly with '\' as a path separator. Which isn't too terribly surprising in a way, but it would still be useful to find out where. Can you run (a pared down) example in strace and show the result? = This is rather "weird". I looked over the dir I'd been using and went to create a test case. Decided to create symlink to one of the tools in the sysinternals toolbox. cd'd to the dir to pick up the path in 'T': /progd/Microsoft/Windows/Start Menu/Programs/Menus/Tools/Sysinternals/SI /progd/Microsoft/../Sysinternals/SI> T=$PWD made test dir and put a link in it to a tool in the dir: /tmp> cd test /tmp/test> ln -s "$T/Desktops" . /tmp/test> ll total 0 lrwxrwxrwx 1 81 Jul 3 13:48 Desktops -> /progd/Microsoft/Windows/Start Menu/Programs/Menus/Tools/Sysinternals/SI/Desktops test it... C:\tmp\test>tar cf /dev/null --acls --xattrs --sparse "-b 2048" --one-file-system . tar: Desktops: Warning: Cannot llistxattrat: Permission denied -- looks similar, strace output attached. I don't know if this is an instance of the same error or a different one -- I say that because when I look at the link I created in /tmp/test using cmd /c dir, I get: ... Directory of C:\tmp\test 2021/07/03 13:48 Desktops [...] it's a junction?? (That wasn't the case before -- ahh it was because the target didn't exist...). Trying again but adding .lnk, so dir shows: 2021/07/03 14:53 Desktops [C:\progd\Microsoft\Windows\Start Menu\Programs\Menus\Tools\Sysinternals\SI\Desktops.lnk] Maybe the strace will confirm, but I think if a symlink target isn't accessible when tar archiving the symlink, maybe that's when the problem pops up. Accessibility has to mean not only present, but possibly allowed by perm settings -- which aren't set right by cygwin even for cygwin's own use...(separate email to come)... --- Process 5412 created --- Process 5412 loaded C:\Windows\System32\ntdll.dll at 777a --- Process 5412 loaded C:\Windows\System32\kernel32.dll at 7758 --- Process 5412 loaded C:\Windows\System32\KernelBase.dll at 07fefda3 --- Process 5412 loaded C:\bin\cygwin1.dll at 00018004 --- Process 5412 loaded C:\bin\cygiconv-2.dll at 0003de34 --- Process 5412 loaded C:\bin\cygintl-8.dll at 0003d53c 0 0 [main] tar (5412) ** 127 127 [main] tar (5412) Program name: C:\bin\tar.exe (windows pid 5412) 45 172 [main] tar (5412) OS version: Windows NT-6.1 32 204 [main] tar (5412) ** --- Process 5412 loaded C:\Windows\System32\advapi32.dll at 07fefdee --- Process 5412 loaded C:\Windows\System32\msvcrt.dll at 07fefde4 --- Process 5412 loaded C:\Windows\System32\sechost.dll at 07feff5e --- Process 5412 loaded C:\Windows\System32\rpcrt4.dll at 07feff25 --- Process 5412 loaded C:\Windows\System32\cryptbase.dll at 07fefd2e 45114715 [main] tar (5412) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180333190) 13286043 [main] tar (5412) open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x84, *m 6 566099 [main] tar (5412) user_heap_info::init: heap base 0x8, heap top 0x8, heap size 0x2000 (536870912) 536152 [main] tar (5412) open_shared: name S-1-5-21-3-7-3-5013.1, n 1, shared 0x18002 (wanted 0x18002), h 0x80, *m 6 346186 [main] tar (5412) user_info::create: opening user shared for 'S-1-5-21-3-7-3-5013' at 0x18002 366222 [main] tar (5412) user_info::create: user shared version AB1FCCE8 616283 [main] tar (5412) fhandler_pipe::create: name \\.\pipe\cygwin-a46ac466ed629d62-5412-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 1736456 [main] tar (5412) fhandler_pipe::create: pipe read handle 0x98 316487 [main] tar (5412) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-a46ac466ed629d62-5412-sigwait 1466633 [main] tar (5412) fhandler_pipe::create: pipe write handle 0x9C 676700 [main] tar (5412) dll_crt0_0: finished dll_crt0_0 initialization --- Process 5412 thread 4612 created 3257025 [sig] tar (5412) wait_sig: entering ReadFile loop, my_readsig 0x98, my_sendsig 0x9C 2747299 [main] tar (5412) time: 1625345566 = time(0x0) 1077406 [main] tar (5412) mount_info::conv_to_posix_path: conv_to_posix_path (C:\tmp\test, 0x0, no-add-slash) 567462 [main] tar (5412) normalize_win32_path: C:\tmp\test = normalize_win32_path (C:\tmp\test) 387500 [
Re: bug in cygwin tar reading unexpected input(s)...
On 2021/06/16 10:22, Achim Gratz wrote: L A Walsh writes: Tar'ing up a windows dir (ProgData) had some unexected failures of the sort: tar: Dbgview: Warning: Cannot llistxattrat: No such file or director, Where the item listed (Dbgview, ...) is a windows symlink like: 2019/02/07 22:53 Dbgview [SI\Dbgview.exe], and stems from the use of the --xattrs switch. Hmm. Looks like some of the symlink / attrs content is taking a route that doesn't deal correctly with '\' as a path separator. Which isn't too terribly surprising in a way, but it would still be useful to find out where. Can you run (a pared down) example in strace and show the result? Interesting diagnosis. Won't know if I can do so until I've tried. Should be _able_ to setup a test case, will have to try it and see. Thanks for the exact diagnosis of what's needed, and next step! :-) Linda So far, have been busy w/other things, like reinstalling my OSbut will try to get back to this.. tnx. -- 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: bug in cygwin tar reading unexpected input(s)...
On 2021/06/16 10:22, Achim Gratz wrote: L A Walsh writes: Tar'ing up a windows dir (ProgData) had some unexected failures of the sort: tar: Dbgview: Warning: Cannot llistxattrat: No such file or director, Where the item listed (Dbgview, ...) is a windows symlink like: 2019/02/07 22:53 Dbgview [SI\Dbgview.exe], and stems from the use of the --xattrs switch. Hmm. Looks like some of the symlink / attrs content is taking a route that doesn't deal correctly with '\' as a path separator. Which isn't too terribly surprising in a way, but it would still be useful to find out where. Can you run (a pared down) example in strace and show the result? Interesting diagnosis. Won't know if I can do so until I've tried. Should be _able_ to setup a test case, will have to try it and see. Thanks for the exact diagnosis of what's needed, and next step! :-) Will try to get to it, but am trying to deal with other problems at the same time (one of which was the one that had me do full backups)... Linda Regards, Achim. -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/08 04:19, Andrey Repin wrote: It has it in every version starting Windows 95/NT4. @Linda: try http://joelpurra.com/Projects/X-Mouse_Controls/ --- Just had the occasion to need it, since had to re-inst W7. Unfortunately, it immediately dumps core. Very odd. Dependency walker tries and issues an immediate failure: 00:00:00.000: Failure starting the process. The request is not supported (50). That looks suspiciously like MS's latest strike against Win7, telling people it's incompatible with newer SW. At least reinst'ing W7 gave me a chance to catch Adobe's SW timebomb destroying my Photoshop CS5 exploding as it happens and their fans telling me how it was crazy for me to expect old SW to work on a newer HW as an excuse for why PS5 would stop working after getting a newer Graphix card to replace an older one that died ... for some reason, TWICE NOW, upgrading Win7-Ult to itself has restored PS5's ability to work with NVidia's latest hardware. Now, after re-inst'ing Win7 on itself to repair a prob, PS5 works again w/latest Nvidia HW -- at least until I reconnect my desktop to the internet and allow Adobe to re-download their malware and kill it again (something I've seen happen about 4 times now with a 5th time in the making). Sigh... Used to be SW timebombs were a criminal act. Then they became a Corporate way of doing business... *double sigh* -- 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: bug in cygwin tar reading unexpected input(s)...
On 2021/06/15 00:16, Russell VT wrote:
I think we need more context, here... as what does Windows versus Cygwin
think those permissions are...???
---
Which permissions? The error is 'no such object', not
'access denied'. I believe it is similar to trying to read (or
modify) xattr's or acl's on linux symlinks.
Are you running your terminal, as you... or did you run it as Administrator?
---
I am in group Administrators as well as Domain Admins
(Samba Domain). Domain Admins and System are both in the
local Administrators group.
Have you run an update, and not rebooted?
---
I don't believe so at that time, but I have rebooted since then.
The problem only occurred on files that were symlinks as seen by Windows
and Cygwin.
There should be some "basic shell debugging" done here, first...
---
I'm not sure what you mean. Oops, I forgot to list the
command line, but thought that "--xattrs" might be implied from the
fact that the error was about retrieving xattrs.
Cmdline was using shell script calling a function, "backup_dir"
with "ProgramData" from the root directory, where the function was:
backup_dir() {
my DIR=${1:?}
tar c --acls --xattrs --sparse -b 2048 --one-file-system "$DIR" |
dd bs=1M iflag=fullblock of="/b/June_backups/$DIR" oflag=nonblock
}
since
there's a disconnect from when tar gets its file list, and when it
physically goes to retrieve a (possibly temporary) file. It will also
complain about directories it can read, but not access.
---
Those were symlinks, not directories.
So, it would be
better to figure out what the "difference" is between what you expect,
and what actually happened with the tar.
---
I would expect it might not complain about not being
able to read xattr's on symlinks? I don't think it complains about
not being able to read them on linux -- or at least I've never seen
such.
Unfortunately, permission issues between Windows and Cygwin can be
*/extremely/* complex (ie. there are a ton of details missing here,
which might make it easier to help troubleshoot).
---
What necessary details are missing?
Hope that helps point you in a good direction.
---
Not sure. I thought I was reporting a bug in cygwin tar
giving an error about trying to read xattrs on symlinks, as I don't
believe it gives an error on linux doing the same thing. Does it?
Thanks for your questions, but I'm still not very clear on what
I left out.
I'd tend to ignore the error on what appeared to be
a misspelled filename, as I'm not even sure how to recreate
that file, but attempting to dump xattrs on a symlink seems like
a pretty straight forward symptom/testcase. What more details
do you think would be pertinent?
Thanks!
-Linda
Cheers!
Russell VT
On Mon, Jun 14, 2021 at 9:22 PM L A Walsh <mailto:cyg...@tlinx.org>> wrote:
Tar'ing up a windows dir (ProgData) had some unexected failures:
Several of the sort:
tar: Dbgview: Warning: Cannot llistxattrat: No such file or directory
tar: Desktops: Warning: Cannot llistxattrat: No such file or directory
tar: DiskView: Warning: Cannot llistxattrat: No such file or directory
tar: LoadOrd: Warning: Cannot llistxattrat: No such file or directory
tar: portmon: Warning: Cannot llistxattrat: No such file or directory
Where the item listed (Dbgview, DiskView, etc) is a
windows symlink like:
2019/02/07 22:53 Dbgview [SI\Dbgview.exe]
2019/02/07 22:53 Desktops [SI\Desktops.exe]
2019/02/07 22:53 DiskView [SI\DiskView.exe]
and stems from the use of the --xattrs switch.
Win7SP1x64
cygcheck (cygwin) 3.2.0
The tar continued and finished much as it would after an unreadable
file.
Another error, maybe similar,
tar: C\:Prog64FastPictureViewer: Warning: Cannot file_has_acl_at: No
such file or directory
From a file in "C:\Program Files\FastPictureViewer" [likely mis-]named
"C:Prog64FastPictureViewer"
It seems to be a .dll, that somehow got its name mangled.
Not sure what it was trying to do, but the file seems to be 'in-use'.
--
Russell M. Van Tassell mailto:russel...@gmail.com>>
--
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 or question on Cygwin XWin
On 2021/06/14 17:30, Duncan Roe wrote: On Mon, Jun 14, 2021 at 04:41:42PM -0700, L A Walsh wrote: There is a listen parameter on XWin, but the man page doesn't say what format to use for the listen parameter. I want to have it listen for tcp from a local net: 192.168.3.0. I started having problems with my cygwin X receiving network connections via TCP, locally (like 192.168.3.1 => 192.168.3.12). And was trying to figure out what the syntax was for specifying what net to have it listen on. Thanks! At least under Linux, 'man Xserver' gives the format "-listen trans-type" with example "-listen tcp". You can '-[no]listen' to tcp, inet (i.e.IP4), inet6, unix or local. Cheers ... Duncan. --- Ah, suspected something similar. But I couldn't remember the linux syntax off hand to narrow down addressesbut since no incoming TCP connections are working on my Winbox rt. now, its a bit moot. Looks like I get to re-install-upgrade Win...what fun! Thanks -- 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
bug in cygwin tar reading unexpected input(s)...
Tar'ing up a windows dir (ProgData) had some unexected failures: Several of the sort: tar: Dbgview: Warning: Cannot llistxattrat: No such file or directory tar: Desktops: Warning: Cannot llistxattrat: No such file or directory tar: DiskView: Warning: Cannot llistxattrat: No such file or directory tar: LoadOrd: Warning: Cannot llistxattrat: No such file or directory tar: portmon: Warning: Cannot llistxattrat: No such file or directory Where the item listed (Dbgview, DiskView, etc) is a windows symlink like: 2019/02/07 22:53 Dbgview [SI\Dbgview.exe] 2019/02/07 22:53 Desktops [SI\Desktops.exe] 2019/02/07 22:53 DiskView [SI\DiskView.exe] and stems from the use of the --xattrs switch. Win7SP1x64 cygcheck (cygwin) 3.2.0 The tar continued and finished much as it would after an unreadable file. Another error, maybe similar, tar: C\:Prog64FastPictureViewer: Warning: Cannot file_has_acl_at: No such file or directory From a file in "C:\Program Files\FastPictureViewer" [likely mis-]named "C:Prog64FastPictureViewer" It seems to be a .dll, that somehow got its name mangled. Not sure what it was trying to do, but the file seems to be 'in-use'. -- 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 or question on Cygwin XWin
There is a listen parameter on XWin, but the man page doesn't say what format to use for the listen parameter. I want to have it listen for tcp from a local net: 192.168.3.0. I started having problems with my cygwin X receiving network connections via TCP, locally (like 192.168.3.1 => 192.168.3.12). And was trying to figure out what the syntax was for specifying what net to have it listen on. Thanks! -- 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: odd prob for cygwin 'dd' from a character device on network disk
On 2021/06/11 18:32, Duncan Roe wrote: On Thu, Jun 10, 2021 at 08:20:30PM -0700, L A Walsh wrote: On 2021/06/09 19:23, Duncan Roe wrote: nfs / nodev? I'm not sure what you mean or are asking. I'm not using nfs...but cygwin. The file 'zero' is in the same dir as the file 'null'. I usually read 'zero' and write to 'null, though for 1-way testing, I read from file 'zero' on the remote file system and write, locally to /dev/null. For other direction write to 'null' and read from /dev/zero locally. When you said you were accessing zero over the network, you didn't say how so I suggested if you were using nfs then nodev might be the culprit. How are you accessing files aver the network? I suspect that whatever mechanism you are using has the equivalent of the nfs nodev feature (part of nfsmount, may be specified in fstab) and the nodev equivalent is turned on in your case. Was afraid that's what you meant...don't know of such an option with samba, not to mention using the same version of samba now, as for ages. Using smb/cifs -- a mounted samba share with my home directory mounted as drive 'H'. The device files are created in my home directory (on linux) as files 'zero' and 'null'. I don't know of any equivalent 'nodev' option in samba -- but regardless, I'm not sure what has changed. I'm still running the same samba that I have for over a year -- my kernel might be different, but I don't think there's been any change to '/dev/zero' -- but in the same directory, writing to the file named 'null' still works. *sigh* -- 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: odd prob for cygwin 'dd' from a character device on network disk
On 2021/06/09 19:23, Duncan Roe wrote: nfs / nodev? I'm not sure what you mean or are asking. I'm not using nfs...but cygwin. The file 'zero' is in the same dir as the file 'null'. I usually read 'zero' and write to 'null, though for 1-way testing, I read from file 'zero' on the remote file system and write, locally to /dev/null. For other direction write to 'null' and read from /dev/zero locally. -- 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
odd prob for cygwin 'dd' from a character device on network disk
I've been using a character device on linux in my home directory named 'zero' that is a copy of the 'zero' device in /dev: crwxrwxrw- 1 1, 5 Jun 15 2015 zero to do read benchmarks using 'dd' (and write benchmarks using a file named 'null' thats a copy of /dev/null). I run it "occasionally", but not on a regular basis, since it stays a bit boring. Nevertheless, ballpark numbers consistent with historical norms verify correct network function (separate from read/write files). Read/write speeds at last check a few weeks ago were typical with reads at 700MB/s and writes at about 300MB/s. A few hours ago I tried it again due to some strange network probs where I seemed to be getting file xfer speeds as low as 200K/s. I tried the bench script, and its half broken now -- because I can no longer get anything back from the zero device on my server via the network. Locally, I can do 'dd' from /dev/zero (or the zero file) and it takes a few seconds and gave about 800MB/s. So seemed to have been working fine, but remotely -- still nada... reads 0 bytes from /dev/zero and about 300MB/s write speed. Can anyone think of anything that might have changed in cygwin such that it would know the remote device is a "/dev/zero". Wondered if the 'dd' prog might have changed, but just realize it did same with 'cat' as well. Anyway -- I'm a bit stumped as to possible causes... The writing to a remote /dev/null part is still working, so not sure why one would change and not the other. If anyone can think of anything, please let me know -- I'm also gonna ping the samba list and maybe my distro list Thanks! -linda -- 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: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
On 2021/06/08 07:10, Mike Kaganski wrote: so any "answers" like yours "why do you ask here" are off-topic. --- But what most people dont' see -- I didn't say you *shouldn't* post here, I asked why when the evidence suggested the problem was python reading TZ info from 2 sources -- like config files and ENV. Honestly I wasn't saying you shouldn't have asked here, just questioning your logic/reasoning. I'm just not very clear on where I'm going in a conversation sometimes, as I take a very round-about path, which if taken, often ends up getting someone to where they want to go, but certainly not via a str8-line. *sigh* *cheers* -- 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: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
On 2021/06/08 06:30, Mike Kaganski wrote: First of all - please stop telling me that I required support. I didn't demand anything, and was asking *in the hope*, but without any wrong expectations that anyone owes anything here. --- Have you ever heard the statement "asking is polite demanding."? I've had lots of people tell me that for similar reasons. Don't stress this I really find more of this as humorous than anything critical. I never claimed that someone must support my use case - so please, please stop answering what wasn't said. --- You didn't claim, you asked. Also you asserted that your python didn't work because of cygwin in the mix. I'm not a cygwin developer, but have used it for over 20 years. I spoke up because I am a computer scientist and the way you were describing the problem was a bit on the amusing side, only because of the logic involved. I am a free software developer, working on LibreOffice project; congrats...I've never really gotten that far because i'm too picky, and easily distractable among other reasons. That ... doesn't mean it's inappropriate to ask with a hope, a question that could be *possibly* answered, and which answer could happen to be helpful also to others. --- I know, I do it frequently, and am accused of waisting other people's time for my work. Unfortunately, it's a dynamic that is hard for some people to deal with. The cygwin devs can't support all the 3rd party programs that interfere. See above. --- You aren't getting that answering questions *IS* a form of support. For better or worse, most companies now hire 3rd party companies to do support who know nothing about the product. They just ask general questions and keep having you do random maintenance and diagnostic tasks until something pops out that may answer the question, but more often until the customer is discouraged enough to stop answering back. I took an issue to its final conclusion one time -- about 45 days of back and forth with them asking me to do various random tasks and run 3rd party progs -- but none of them in support knew anything about the product or the servers or the hardware -- they weren't allowed to know -- they were there as a buffer, to keep the users away from the developers! That's how most companies operate these days -- Google, Microsoft, NVidia, all the major game companies. Like a call into nvidia where it doesn't install a driver for two items. I contacted nvidia and their support person couldn't answer the question. Instead, they put the problem on me because I was still running Win7 and couldn't generate an activeX diag, but I could run their own card diag -- but they focused on the activeX diag. I countered with the fact that the two unknown devices are listed as being attached to the video card. Can't they look at a hardware spec and tell me what is connected there? They stopped responding. Like a previous issue, no doubt, it will stay open for ever in the "doing research state" Anyway, I'm way off your original topic, but I hope I at least gave you a few pointers -- even if you did think I was criticizing, oh well... But I did what the 3rd party support people did and led you along more generic ways of looking for the prob even though I know little about cygwin internals. Anyway, see you found a workaround, so fab & have fun! -- 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: After cygwin 3.2 update windows terminal input is sometimes broken
On 2021/06/08 05:41, Tomas Tumelionis wrote: Sorry for the vague description. --- I get accused of being too vague all the time. Glad you narrowed down the problem. Good job! Have fun! -- 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: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
On 2021/06/08 05:28, Mike Kaganski wrote: No, I report a problem that a native program runs incorrectly *under Cygwin*, because Cygwin is indeed part of the picture. --- The problem is in the MS-Win term program. If you report it to them and tell them it only misbehaves when you have a 3rd party app injecting "dll's" (libraries) into the MS-program, they will _likely_ tell you that they can't support every 3rd party program that injects libraries into MS programs, and they can only support you running it without the 3rd party programs. Just like cygwin devs have noticed that various other programs (see BLODA:https://cygwin.com/faq/faq.html#faq.using.bloda ) are known for causing problems in cygwin. The cygwin devs can't support all the 3rd party programs that interfere. and being not a prophet, I can't know in advance if the actual bug lies in Windows, in Python, or in Cygwin interaction with them. --- As I said before, python is probably picking up time-zone changes from _both_ cygwin and windows. The workaround is to use the appropriate version of python with the correct OS. Cygwin is an OS emulation, Win10 is another OS. They both have versions of python designed for them. If MS thought the cygwin version of python was good enough for every purpose, they wouldn't have issued their own version. You might ask on a python list if anyone else has experienced something similar with python or any other program. I'm fairly sure that neither MS nor cygwin design their OS with python in mind and that it is python that is interacting funny when running under some merge of both. Have you asked the python people about this problem? What did they suggest? And I assume that Cygwin is not declaring that its users "must never run native applications from Cygwin", so I find that passage above inappropriate and off-topic. --- Just because they don't tell you to never run linux apps directly in cygwin doesn't mean they support it if you insist on trying. Most devs won't tell you all the things you can't do, because that list is endless. That certainly doesn't suggest that they would support all the things that don't work. Though as to why -- likely the windows version is getting time zone clues + correction from BOTH cygwin and Windows, like it's told its in a TZ that is at 1 time, while Windows feeds it other data that says it is 2 hours off from the default. Maybe. It's OK if no one here knows the reason - I of course don't expect anyone here obliged to give an answer. My question was intended to ask if someone (e.g., a Cygwin dev) somehow can see the problem from their expertise, and - maybe - even know how to fix it. Maybe there's some technique how to workaround this problem - and even if it's not a Cygwin's bug, it still could be useful for Cygwin users, hence still the post to the list, accompanied by someone's workaround, would be reasonable and useful. When you say you run the Win python on cygwin, what do you mean? ... I just ran python from windows (not the same version you have, but an old one python2.7. I ran it from bash, but the resulting python doesn't have any cygwin libraries loaded -- that tells me that python is looking at some absolute paths and the environment and picking up both -- it's a MS-python "bug". Look in its environment and remove any thing for timezone and try that. Or look in your path and make sure there are no cygwin directories in the path that your win-python is using. I'm pretty sure that will solve your problem. FWIW, here is a list of what python running from 'bash.exe' from cygwin has loaded -- and none of it is from cygwin: /prog/Sysinternals/cmd/exe> Listdlls python ListDLLs v3.1 - List loaded DLLs Copyright (C) 1997-2011 Mark Russinovich Sysinternals - www.sysinternals.com -- python.exe pid: 4928 Command line: C:\Python27\python.exe BaseSize Path 0x1d00 0xa000C:\Python27\python.exe 0x7776 0x19f000 C:\Windows\SYSTEM32\ntdll.dll 0x7295 0x3f000 C:\Windows\SYSTEM32\wow64.dll 0x728f 0x5c000 C:\Windows\SYSTEM32\wow64win.dll 0x728e 0x8000C:\Windows\SYSTEM32\wow64cpu.dll 0x1d00 0xa000C:\Python27\python.exe 0x7792 0x18 C:\Windows\SysWOW64\ntdll.dll 0x7684 0x11 C:\Windows\syswow64\kernel32.dll 0x7674 0x47000 C:\Windows\syswow64\KERNELBASE.dll 0x1e00 0x227000 C:\Windows\SysWOW64\python27.dll 0x7742 0x10 C:\Windows\syswow64\USER32.dll 0x7658 0x9 C:\Windows\syswow64\GDI32.dll 0x7698 0xa000C:\Windows\syswow64\LPK.dll 0x75f7 0x9d000 C:\Windows\syswow64\USP10.dll 0x7669 0xac000 C:\Windows\syswow64\msvcrt.dll 0x7679 0xa1000 C:\Windows\s
Re: After cygwin 3.2 update windows terminal input is sometimes broken
On 2021/06/06 22:08, Tomas Tumelionis via Cygwin wrote: Been using windows terminal preview (this is still actual with current latest version 1.9) and after cygwin 3.2 update windows terminal input is broken after: * splitting pane * moving terminal window to other window * sleeping pc This means that if I open the terminal and split pane, I can not enter text into the previous pane forever. Does the cygwin terminal still work? Seems like you are reporting a Windows problem in cygwin. What does cygwin have to do with a windows terminal -- it doesn't use cygwin at all, does it? So how does an update in cygwin cause a windows problem? You realize MS update your Terminal preview's OS almost daily, most the time without you realizing it. It's more likely they broke it at the same time cygwin had an update, than something in cygwin affecting Win10... If they have a version of the Terminal preview that runs on Win7, though, I'll be happy to have a look at the problem... ;-) -- 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: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
On 2021/06/06 23:59, Mike Kaganski via Cygwin wrote: Hello, Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 19043.985), I have this issue: when I start Cygwin's Python, I have correct time reported: But running Python for Windows (it doesn't matter which, specifically for the test I used the one from MS Store [1]), I have incorrect local time Why are you reporting a problem in Windows-Python on a cygwin list, especially when the cygwin python runs correctly? Admittedly I'd be more interested to know what happened in perl, but doubt MS wants to try supporting that can of worms. I don't see it as a bug, really, but another Win10 feature! Though as to why -- likely the windows version is getting time zone clues + correction from BOTH cygwin and Windows, like it's told its in a TZ that is at 1 time, while Windows feeds it other data that says it is 2 hours off from the default. Anyway, I assume you reported it here just to amuse cygwin users at MS's Win-Python? ;-) Long live my buggy Win7! ;-) It's so funny -- bugs that I had for 6-7 years in Win7, they finally told me would be fixed in Win10. But recently, saw the same bug/prob being reported in Win10 -- and MS still doesn't know the problem. So checked a some settings and found out how to fix it on Win7, but only -- 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: how to "re-enable" perl after 5.32 install; how to reinstall all perl-mods?
On 2021/06/01 22:47, ASSI wrote: L A Walsh writes: updated cygwin and it reinstalled a new version of perl, but when I try to run any perl progs nothing runs (see below). So I'd like to try to reinstall all the cygwin perl-mods that I have installed. You didn't say how you updated Cygwin, but if you used setup then it already did exactly that. Why would it have reinstalled all of the modules it just installed? I need to _RE_-install (to make sure all of the existing modules correspond to what was downloaded by the 5.32 update. I have possible doubts as to their integrity. How can I select "all" among the perl mods? and install? I can select for only the "installed" perl mods, but how can I tell it to reinstall all of them? I'm not sure I understand your question, but how would you re-install a not installed module? I wanted to re-install all of the **installed** modules to verify integrity. According to /etc/setup, there are about 202 modules that need to be reinstalled, but I don't see howto tell setup to re-install all the "installed" modules (so I can be sure they are all "refreshed". Again, they already should be. --- Not necessarily iff I'm getting coredumps/missing modules from my existing perl programs. Thanks (errors from 2 of my local perl progs, "pcalc" and "dedup") and trying cpanwhich also doesn't work. :-( pcalc Segmentation fault (core dumped) Well, I'm afraid I can't help you with an error so non-specific. --- Yeah... Signal SEGV at /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/Term/Size.pm line 14. None of the stuff in /usr/local/ comes from Cygwin, that was all put there by yourself. How about you move that away first? So your ExtUtils::MakeMaker installation seems incomplete, you need to install the perl-ExtUtils-MakeMaker package at least. Yeah... Yeah, I had a bunch of modules in the previous 5.30 tree from 'site' that didn't get remade and I didn't know perl 5.32 was going to cause so many problems that I couldn't run most of the stuff I had. On linux I had backups in the worst case and could restore a perl dir to capture all the modules I would need to recompile from cpan, but on windows, don't have a good backup program since MS removed MSbackup in Win7, so people couldn't backup binary programs (except via image restores). Grr. I think that the problem I have in Cygwin-setup is it is difficult to 'keep' an older binary install from something like perl as one has to go through and 'keep' every compat module that is installed for perl along the way every time you run setup. Cygwin really needs to use something like rpm for POSIX-compatible package management and only use setup for the cygwin-binaries that need to be installed outside of setup. Then cygwin could use all the package management utils from linux (RH, Suse, et al.) that would allow more flexible local package management. Rt. now have to figure out how to make POSIX::RT::Semaphore work in new perl...only emphasizing why perl is falling out of favor as a devel. env. *sigh*... -- 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: how to "re-enable" perl after 5.32 install; how to reinstall all perl-mods?
On 2021/06/01 21:32, Brian Inglis wrote: $ grep ^perl- /etc/setup/installed.db | cut -d' ' -f1 | paste -d, -s perl-Algorithm-Diff,perl-Authen-SASL,perl-Authen-SASL-XS,... ...,perl-namespace-autoclean,perl-namespace-clean $ wget -NP /tmp/ https://cygwin.com/setup-x86_64.exe $ cygstart /tmp/setup-x86_64 -fgnqrP \ `grep ^perl- /etc/setup/installed.db | cut -d' ' -f1 | paste -d, -s` Thanks, mostly. It did try to install them, but the solver was/is too smart, it comes up with 2 solutions 1/2 to uninstall 5.32, install 5.30-x and a bunch of other modules, and (2/2) (Default) Don't uninstall 5.30 and keep 5.32. I think the db-base in /etc/setup contains all the 5.32 compat modules -- so it basically saw all those uninstalls/reinstall and just told me it was taking the easier path! ;-) How does one pick a non-default choice at that point (not that this was the only problem -- seems I have existing modules installed in 5.32 under a local site_lib directory. Problem there is that the existing modules there don't link: HiRes.c: loadable library and perl binaries are mismatched (got handshake key 0x 80770, needed 0x0) But if i just push that dir out of the way, the 1st prog I tried (pcalc that led to me trying cpan which didn't work) now works, however the 2nd prog "dedup", wouldn't work because of a missing prereq from CPAN which won't make: dedup Can't locate POSIX/RT/Semaphore.pm in @INC (you may need to install the POSIX::RT::Semaphore module) --- Tried making that, but I don't think it is compatible with 5.32 due to incompatible changes in perl (vaguely remember something like that, but not sure...) But it fails with: cpan -i POSIX::RT::Semaphore Loading internal logger. Log::Log4perl recommended for better logging CPAN::SQLite not installed, trying to work without Reading '/Share/CPAN/Metadata' Database was generated on Tue, 01 Jun 2021 01:29:03 GMT Running install for module 'POSIX::RT::Semaphore' CPAN: LWP::UserAgent loaded ok (v6.54) Fetching with LWP: http://mirrors.kernel.org/CPAN/authors/id/M/MJ/MJP/POSIX-RT-Semaphore-0.05.tar.gz CPAN: YAML loaded ok (v1.30) CPAN: Digest::SHA loaded ok (v6.02) Fetching with LWP: HASH(0x811899ad8)authors/id/M/MJ/MJP/CHECKSUMS Fetching with LWP: HASH(0x811899ad8)authors/id/M/MJ/MJP/CHECKSUMS.gz Fetching with LWP: http://mirrors.kernel.org/CPAN/authors/id/M/MJ/MJP/CHECKSUMS CPAN: Compress::Zlib loaded ok (v2.093) Checksum for /Share/CPAN/sources/authors/id/M/MJ/MJP/POSIX-RT-Semaphore-0.05.tar.gz ok CPAN: Archive::Tar loaded ok (v2.36) CPAN: CPAN::Meta::Requirements loaded ok (v2.140) CPAN: Parse::CPAN::Meta loaded ok (v2.150010) CPAN: CPAN::Meta loaded ok (v2.150010) Configuring M/MJ/MJP/POSIX-RT-Semaphore-0.05.tar.gz with Makefile.PL Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for POSIX::RT::Semaphore Writing MYMETA.yml and MYMETA.json MJP/POSIX-RT-Semaphore-0.05.tar.gz /usr/bin/perl Makefile.PL -- OK Running make for M/MJ/MJP/POSIX-RT-Semaphore-0.05.tar.gz CPAN: Module::CoreList loaded ok (v5.20210123) cp Semaphore.pm blib/lib/POSIX/RT/Semaphore.pm Running Mkbootstrap for Semaphore () "/usr/bin/perl.exe" "/usr/share/perl5/5.32/ExtUtils/xsubpp" -typemap '/usr/share/perl5/5.32/ExtUtils/typemap' -typemap '/var/cache/CPAN/build/POSIX-RT-Semaphore-0.05-2/typemap' Semaphore.xs > Semaphore.xsc chmod 644 "Semaphore.bs" "/usr/bin/perl.exe" -MExtUtils::Command::MM -e 'cp_nonempty' -- Semaphore.bs blib/arch/auto/POSIX/RT/Semaphore/Semaphore.bs 644 mv Semaphore.xsc Semaphore.c gcc -c -I. -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 -pipe -Wall -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/build=/usr/src/debug/perl-5.32.1-1 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/src/perl-5.32.1=/usr/src/debug/perl-5.32.1-1 -fwrapv -fno-strict-aliasing -DUSEIMPORTLIB -O3 -DVERSION=\"0.05\" -DXS_VERSION=\"0.05\" "-I/usr/lib/perl5/5.32/x86_64-cygwin-threads/CORE" -DHAVE_SEM_DESTROY -DHAVE_SEM_GETVALUE -DHAVE_SEM_INIT -DHAVE_SEM_OPEN -DHAVE_SEM_POST -DHAVE_SEM_TIMEDWAIT -DHAVE_SEM_TRYWAIT -DHAVE_SEM_UNLINK -DHAVE_SEM_WAIT Semaphore.c Semaphore.c: In function ‘XS_POSIX__RT__Semaphore_unlink’: Semaphore.c:269:8: warning: variable ‘pkg’ set but not used [-Wunused-but-set-variable] 269 | char* pkg; |^~~ Semaphore.c: In function ‘XS_POSIX__RT__Semaphore__Unnamed_init’: Semaphore.c:586:8: warning: variable ‘pkg’ set but not used [-Wunused-but-set-variable] 586 | char* pkg; |^~~ Semaphore.c: In function ‘XS_POSIX__RT__Semaphore__Named_open’: Semaphore.c:686:8: warning: variable ‘pkg’ set but not used [-Wunused-but-set-variable] 686 | char* pkg; |^~~ At top level: Semaphore.xs:92:1: warning: ‘function_not_implemented’ defined but not used [-Wunused-function] 92 | function_not_implemented(void) | ^~
how to "re-enable" perl after 5.32 install; how to reinstall all perl-mods?
This is getting really icky...
updated cygwin and it reinstalled a new version of perl,
but when I try to run any perl progs nothing runs (see below).
So I'd like to try to reinstall all the cygwin
perl-mods that I have installed.
How can I select "all" among the perl mods? and install?
I can select for only the "installed" perl mods, but how can
I tell it to reinstall all of them?
According to /etc/setup, there are about 202 modules that need
to be reinstalled, but I don't see howto tell setup to re-install
all the "installed" modules (so I can be sure they are all "refreshed".
Thanks
(errors from 2 of my local perl progs, "pcalc" and "dedup")
and trying cpanwhich also doesn't work. :-(
pcalc
Segmentation fault (core dumped)
# Trying perldb:
perl -d pcalc
Loading DB routines from perl5db.pl version 1.57
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
Signal SEGV at
/usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/Term/Size.pm
line 14.
require Term/Size.pm called at pcalc line 26
main::BEGIN() called at
/usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/Term/Size.pm
line 0
eval {...} called at
/usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads/Term/Size.pm
line 0
Another prog:
dedup
Can't locate Carp/Always.pm in @INC (you may need to install the
Carp::Always module)...
Try cpan:
cpan
Can't locate ExtUtils/MakeMaker/version/vpp.pm in @INC (you may need to
install the ExtUtils::MakeMaker::version::vpp module) (@INC contains:
/bin/lib /usr/local/lib/perl5/site_perl/5.32/x86_64-cygwin-threads
/usr/local/share/perl5/site_perl/5.32
/usr/lib/perl5/vendor_perl/5.32/x86_64-cygwin-threads
/usr/share/perl5/vendor_perl/5.32
/usr/lib/perl5/5.32/x86_64-cygwin-threads /usr/share/perl5/5.32) at
(eval 11) line 1.
BEGIN failed--compilation aborted at (eval 11) line 1.
Compilation failed in require at
/usr/share/perl5/5.32/ExtUtils/MakeMaker.pm line 10.
BEGIN failed--compilation aborted at
/usr/share/perl5/5.32/ExtUtils/MakeMaker.pm line 10.
Compilation failed in require at /usr/share/perl5/5.32/CPAN.pm line 48.
BEGIN failed--compilation aborted at /usr/share/perl5/5.32/CPAN.pm line 48.
Compilation failed in require at /usr/share/perl5/5.32/App/Cpan.pm line 290.
BEGIN failed--compilation aborted at /usr/share/perl5/5.32/App/Cpan.pm
line 290.
Compilation failed in require at /bin/cpan line 10.
BEGIN failed--compilation aborted at /bin/cpan line 10.
--
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 opening/loading an X11 font.
If I use 'xlsfonts' to list my X server fonts, one of them fonts I am trying to use is "lucidatypewriter-medium". display xlsfonts and filtering on the family, I get tons: -b&h-lucidatypewriter-medium-r-normal-sans-0-0-100-100-m-0-iso10646-1 -b&h-lucidatypewriter-medium-r-normal-sans-0-0-100-100-m-0-iso8859-1 ... -b&h-lucidatypewriter-medium-r-normal-sans-11-80-100-100-m-70-iso10646-1 -b&h-lucidatypewriter-medium-r-normal-sans-11-80-100-100-m-70-iso8859-1 ... -b&h-lucidatypewriter-medium-r-normal-sans-14-100-100-100-m-80-iso10646-1 160 matches of various sizes and encodings So in my "~/.Xdefaults", I have tried: !XTerm*font: -*-lucidatypewriter-medium-*-*-*-*-*-*-*-*-*-*-*- XTerm*font: lucidatypewriter !XTerm*font: -b&h-lucidatypewriter-medium-r-normal-sans-11-80-100-100-m-70-iso10646-1 full and sparse specification, but no matter, when I run xterm, I get: xterm: cannot load font '-b&h-lucidatypewriter-medium-r-normal-sans-11-80-100-100-m-70-iso10646-1' xterm: cannot load font '-*-lucidatypewriter-medium-*-*-*-11-*-*-*-*-*-*-*-' xterm: cannot load font '-*-lucidatypewriter-medium-*-*-*-*-*-*-*-*-*-*-*-' xterm: cannot load font 'lucidatypewriter-medium' xterm: cannot load font 'lucidatypewriter-medium' etc. How is this possible? xlsfonts displays the font(s), but an x-prog like xterm can't load any form Have tried neutering locale as well to no effect. (LC_ALL=C or POSIX)... Can't figure out why the font is listed but not loadable??! Ideas? Thanks! -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/11 07:33, Jon Turney wrote: On 10/04/2021 22:37, L A Walsh wrote: On 2021/04/10 12:14, L A Walsh wrote: On 2021/04/09 07:41, Jon Turney wrote: I think so, yes. === That's unfortunate. Well, I wasn't sure if it was new or old. At least its not some new problem. Sigh. Thanks for the backstory. [1] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00168.html [2] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00278.html [3] https://sourceware.org/pipermail/cygwin/2017-May/232564.html --- I don't know if this was tried, but the only way to really do it would be along the lines of detecting when windows had grabbed control via its time -- for cygwin to use a timer to detect when it lost control. Ex. in cygwin's blink routine, it would need to check There is no 'cygwin blink routine' - this is something that the X client (e.g. gvim in your example) is doing, while it believe that it has focus. --- Use of "cygwin blink routine" refers to whatever timing mechanism calls some graphical routine to toggle on and off a cursor, unless you are saying that the timer routine responsible for blinking is only present in gvim, in which case X or cygwin might need their own timer routine. that it still had focus, and if it had lost it for longer than 50-75ms (maybe configurable), assume cursor is over a Win-Window... May not be worth the bother, but it might catch the problem? There's almost certainly no need for such heuristics. Windows provides various notification messages when the focus is moving, it's translating those (correctly) into the model that X clients expect that is the problem. I suggest a heuristic because a direct translation has been resistant to implementation, so far, but also because windows is using a heuristic to determine when to change focus. It uses a timer to give you time to move to a widget and not activate everything between the two -- like when I right click on a task on the menu bar and the options appear about .5-1" to the right of the menu bar (mine is on the left, not bottom). That means I need to move over some other "stuff" before I can get to the target. If I move too slowly, the target disappears. If windows waits too long to activate the target, I find myself moving into a window and waiting for it to become active. So the time before windows activates the target is also a configurable wait time, which is why I thought cygwin might use something similar. It may not be ideal, and not always, do I move to my target quickly enough, but it works most of the time in practical use. -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/09 08:12, Thomas Wolff wrote: Hmm, when I start xterm -bc and click out of xterm (e.g. mintty or Thunderbird), the cursor stops blinking for me. --- That's the key difference "click out of xterm" -- in pointer follows focus, no clicking is used. The active window becomes the one under the cursor (in my case) 175ms later. -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/10 12:14, L A Walsh wrote: On 2021/04/09 07:41, Jon Turney wrote: I think so, yes. === That's unfortunate. Well, I wasn't sure if it was new or old. At least its not some new problem. Sigh. Thanks for the backstory. [1] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00168.html [2] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00278.html [3] https://sourceware.org/pipermail/cygwin/2017-May/232564.html --- I don't know if this was tried, but the only way to really do it would be along the lines of detecting when windows had grabbed control via its time -- for cygwin to use a timer to detect when it lost control. Ex. in cygwin's blink routine, it would need to check that it still had focus, and if it had lost it for longer than 50-75ms (maybe configurable), assume cursor is over a Win-Window... May not be worth the bother, but it might catch the problem? -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/09 07:41, Jon Turney wrote: I think so, yes. === That's fine, I guess I hadn't noticed it before -- had about 3-X and maybe 2 native and couldn't figure out why I occasionally had typing going to the wrong window when I realized I had been relying on the blinking for the active window...oi! See [1] et seq. for a discussion of what I think is the same problem, where the Cygwin X server doesn't notify X windows of a focus loss when the focus moves to a non-X window. Unfortunately, my attempts at fixing this just introduced more problems (see [2],[3] et seq.), and so were reverted. === That's unfortunate. Well, I wasn't sure if it was new or old. At least its not some new problem. Sigh. Thanks for the backstory. [1] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00168.html [2] https://sourceware.org/legacy-ml/cygwin/2017-04/msg00278.html [3] https://sourceware.org/pipermail/cygwin/2017-May/232564.html -- 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: X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
On 2021/04/07 11:46, Achim Gratz wrote: L A Walsh writes: If I move the windows cursor to another editor window in X11, the blinking cursor moves to the new window, but if I move it to a native window, the blinking doesn't stop. Has this always been this way? Windows never had "focus follows mouse" in any version I can remember. It's been in every version since at least Win98, but required either some special utility to set it or editing the registry. They do have a focus follows mouse setting, but one that always raises the the window in question, which can still duplicate the problem of switching to a win-window where it gets focus and X11 may not know it. First thing I have on my desktop is 1-click to activate -- same as web settings. I have RSI issues and trying to double click on things really causes the irritation level to go up quickly. That means I can select by hovering -- that setting is in the folder options under Tools when you look at a folder. Single-click to open items, and underline icon titles consistent w/my browser. In the Mouse or Ease-of-access settings, one can choose to activate a window by hovering over it with the mouse. The one that still takes a registry setting since Win98 days. is true focus follows mouse w/o the window being raised. There's still a configurable delay before the focus changes -- usually 175-250ms, or the moving your cursor across the screen would cause a bunch of windows to raise in the default configuration. The 175 works for me. But it has to do with HKEY_CURRENT_USER\Control Panel\Desktop\UserPreferencesMask. It's a 8-byte binary value. I always see the low-order nibble of the first byte set to '1'(like 0xb1). So that hasn't changed for me since win98 but whether or not xprograms have blinking cursors that stop blinking or hide when you type are things that have been added in that time, but I've never seen the cursor keep going like I do most recently, when the focus goes off the X-window to a Win-window. I notice you zoomed in on windows being able to change focus by moving the cursor to a different window w/no click involved. Did something change in that area in X11 where it was changed to need to see a click before changing? Thanks! Regards, Achim. -- 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
X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
I don't recall this always being this way as I keep running into a problem with my input going into the wrong window. I've noted I seem to be relying on which editor(i.e. gvim) window in X11 has focus by noting that it has a blinking square cursor in the window at the cursor's current position in the edited text. If I move the windows cursor to another editor window in X11, the blinking cursor moves to the new window, but if I move it to a native window, the blinking doesn't stop. Has this always been this way? -- 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: Perl Unidecode modules - which to use (if not Text::Unidecode)?
On 2021/04/04 14:26, Joel Rees via Cygwin wrote:
1. What perl Unicode modules should I consider, if not Text::Unidecode?
The present need
is to be able to convert those few "foreign" characters (like
ÇĆĈĊçĉċĜĞĠĢĝģğġËÌÍÎÏÒÓÔÕ)
that are basically ASCII with accent marks to their closest ASCII
equivalents, but I'd
like to do more with Unicode in the future, without going down any
dead-ends as far as
being able to run under cygwin is concerned.
"Stripping those few foreign accent characters" is probably not really what
you want to do.
Why not? You don't know his use case and you are misinterpreting his
example as random garbage.
Those aren't a random foreign encoding -- those are C's G's then E, I O
with accent variations that he may want to collapse for purposes of storing
in a text storage and retrieval (search) application. They are all well
formed/well-coded UTF-8 characters -- they are not some 8-bit encoding
that was remangled during a no-recoding display of them in a UTF-8
context.
I didn't know about Text::Unidecode -- but it specifically to create
Latinized alternatives to foreign characters. That was another hint
that it wasn't a random mistake. The manpage for it says:
It often happens that you have non-Roman text data in Unicode,
but you
can't display it -- usually because you're trying to show it to a
user
via an application that doesn't support Unicode, or because the fonts
you need aren't accessible. You could represent the Unicode
characters
as "???" or "\15BA\15A0\1610...", but that's nearly useless
to the
user who actually wants to read what the text says.
An example was like:
tperl
use utf8;
use Text::Unidecode;
my $name="\x{5317}\x{4EB0}";
printf "name, %s == %s\n", $name, unidecode($name);
'
name, 北亰 == Bei Jing
It's not just about removing accents but getting an English
like translation based on the foreign text.
All of the characters he used as example were well coded utf-8
characters --
Those "accent characters" are misinterpreted foreign encoding (likely not
to be Unicode) characters. Simply "stripping" the "accent characters" will
basically convert them to truly meaningless junk. I suppose the meaningless
junk can then be interpreted by the reader as "used to be a be a foreign
word here", but why bother contributing further to information entropy?
2. I see some talk of Internationalization in Chapter 2 of "Setting up
Cygwin", but
cannot see anything relating to perl modules, and I don't see any easy way
to search many
months of the mailing list for a keyword... is there any information I
should know about?
Have you read the perldoc on internationalization?
--
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 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: Perl Unidecode modules - which to use (if not Text::Unidecode)?
Sorry for not including this in other post, but attached is the output for my cpan -i stage -- there was a bit of it, and like I said, it looked like it might not work, but i it did. I used 'xz' to compress it from 37610 down to 2272 bytes. log.xz Description: application/xz-compressed-tar -- 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: Perl Unidecode modules - which to use (if not Text::Unidecode)?
On 2021/04/01 13:35, Mark Aitchison wrote:
1. What perl Unicode modules should I consider, if not Text::Unidecode? The present need
is to be able to convert those few "foreign" characters (like ÇĆĈĊçĉċĜĞĠĢĝģğġËÌÍÎÏÒÓÔÕ)
that are basically ASCII with accent marks to their closest ASCII equivalents,
---
Hmm...have you tried installing from cpan?
I just tried it and it seems to work.
cpan -i Text::Unidecode;
> cat /tmp/in
ÇĆĈĊçĉċĜĞĠĢĝģğġËÌÍÎÏÒÓÔÕ
cat /tmp/in| perl -e '
use Text::Unidecode;
while (<>) {
print unidecode($_);
}'
cccE
---
I.e. it stripped off all the accent marks. Is that what you
want?
(it spewed some warnings, but seemed to test out ok, so tried it).
put your characters in a file "/tmp/in", (i.e.
cat /tmp/in
-- I know, not very creative,
but then:
cat /tmp/in| tperl
use Text::Unidecode;
while (<>) {
print unidecode($_);
}'
cccE)
Where are you seeing those characters and how do you know they are not
already in unicode? I.e. That I'm seeing characters "CcGgEIO" but with
accents -- indicates they area already in Unicode.
What are you wanting to do.. just convert them to the ASCII characters
with the accent marks stripped off?
but I'd
like to do more with Unicode in the future, without going down any dead-ends as far as
being able to run under cygwin is concerned.
2. I see some talk of Internationalization in Chapter 2 of "Setting up Cygwin", but
cannot see anything relating to perl modules, and I don't see any easy way to search many
months of the mailing list for a keyword... is there any information I should know about?
Thanks,
Mark Aitchison
--
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 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: Different symlink resolution in native console vs. terminal
On 2021/03/10 14:51, Andrey Repin wrote: Running `pwd -P` or `readlink -e .` in a specific directory from native terminal provide unresolved answers. The directory $HOME/Documents/EVE is a symlink pointing to $HOME\Documents\Games\EVE. When running either command inside the directory from native terminal, the result is literally /home/Documents/EVE, but when running the same command from mintty inside same directory, the results may vary. $HOME/Documents/EVE or $HOME/Documents/Games/EVE (which is expected answer). It also seems, there are results difference between `bash -l` `and bash -i` and `pwd -P` and `readlink -e .`. Generally, "pwd" is more correct. 1) When you look at the processes(native v mintty), are both the same #bits? 2) Can you reproduce this with any other dir? Both Documents and Games have multiple copies due to the public docs+games are in the docs+games library (along with user versions). Maybe the winterm is picking up a different file? 3) do you actually have a directory named '$HOME' or is it a real dirname? 4) the symlink is in 'EVE' in both cases, yes? Can you copy 'EVE' (the symlink) to a dir like /tmp and do they resolve differently there? I think one or both of those dirs have a GUID associated with them, maybe one is using a different GUID than the other? I also have Win7x64 but have never seen them misbehaving... How was your link made? -- 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: Would it be possible to update the bash package?
On 2021/03/03 16:40, Jack S wrote: On Sun, Feb 28, 2021 at 10:03 PM L A Walsh wrote: What features are you looking for in 5.0 that you need it? Bug fixes and security updates. Also I want to have version parity with my servers. I don't recall any security vulnerabilities reported in 4.3/4.4 that have been fixed, and there have been just as many bugs introduced in 5.0 as fixed, as features and behaviors changed. Really I don't see a compelling reason there should be any hurry to update. In my own testing, I've been unable to build a version that doesn't crash/dump core on linux and don't really think the 5.x series has had a thorough vetting such that it would be regarded as being as stable as 4.3/4.4. The 5.x series is still new and I'm thinking if 5.x is offered, it should stay on the beta channel for a few more major releases. I certainly don't see 5.0 being more Posix compatible than the 4.x series or more compatible with existing shells. I'm not sure cygwin should strive to be on the bleeding edge as it is designed to be a Posix compatible solution -- not necessarily something with all the latest bleeding edge versions. It's not up to me what version ships with cygwin, but if I wanted a newer version I'd build it myself and I'd hope the bash maintainer for cygwin would upgrade to 5.x when 5.x is more mature, though I certainly see no problem and would support 5.x being offered as in the beta/test channel for a few releases. That seems like a perfect fit for a stable vs. new structure. But that's just my opinion at the time... -l -- 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: Would it be possible to update the bash package?
On 2021/02/27 18:06, Matt via Cygwin wrote: Hi maintainers, Would it be possible to get an updated version of the bash package? The latest version available for cygwin is 4.4.12-3 which was released in 2017. There's been at least one major version of bash (5.0) released since then in January 2019 and 5.1 just came out in December 2020. Is there something you are missing in 5.0? I'm still at 4.3 and it seems to be working fine. What features are you looking for in 5.0 that you need it? you could just build + install it yourself too. It's not that hard of a package to build. -- 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: Cygwin doesn't handle SIGWINCH properly in Windows Terminal
On 2021/02/16 02:26, Thomas Wolff wrote: I have a similar trap in my .bashrc and it's being triggered when running bash from either cmd (conhost) or Windows Terminal and resizing them. Did I miss something in this issue? What do you mean by "reset LINES/COLUMNS"? I am not sure what is the behaviour diffrence in Linux and cygwin you mentioned. running "-bash.exe" from Win-R: whence -- -bash -bash is /bin/-bash -bash is /usr/bin/-bash # initial size: echo $LINES/$COLUMNS 30/80 showsize;printf "\n" (30x80) # shrink by 4 lines; showsize shows 26 lines, but ENV vars are unchanged showsize;printf "\n$LINES/$COLUMNS\n" (26x80) 30/80 stty size #shows: 26 80 #checkwinsize is set. shopt -p checkwinsize shopt -s checkwinsize # same thing happens if I run 'cmd.exe' then start bash.exe Normally, showsize displays size dynamically if I take my finger off the mouse -- only way to see win size as I resize it. However in cmd.exe, it doesn't work. AFAIK, its always been this way in Win7. There were a bunch of bugs in Win7 that MS refused to release, or in some cases, only upon request (hotfix). While there was a SP2 for the corresponding server edition of Win7 (Win2008), they didn't want to ship a Win7SP2, because they wanted to force people to upgrade to get fixes, so they left known bugs in Win7 for as much as 6-7 years before they started telling users who had known bugs they weren't going to fix, to upgrade to Win10 if they wanted it fixed. OTOH, if you want to fix this, that's great, but there are other problems in cmd.exe like 'erase' not working in some ms-cmd line programs (netsh coming to mind), but other ms-programs only work when attached to 'cons0', like 'sc' doesn't read input when it asks if you want to see more help when run from mintty, but it works from cmd.exe. Many of these were reported to MS before SP1, and weren't fixed. Should be criminal -- if they won't support it, then source should be released. -l -- 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: Cygwin doesn't handle SIGWINCH properly in Windows Terminal
On 2021/02/14 16:05, Takashi Yano wrote:
On Sun, 14 Feb 2021 12:44:32 -0800
L A Walsh wrote:
showsize () {\
declare s=$(stty size); s="(${s// /x})" ;\
printf "%s" "$s${s//?/$'\b'}" ;\
}; export -f showsize
trap showsize SIGWINCH
-
What do you mean by "reset LINES/COLUMNS"? I am not sure what
is the behaviour diffrence in Linux and cygwin you mentioned.
---
Actually not sure I can reproduce this now. The only
thing I am noticing is that if bash is attached to /dev/pts3
(as in mintty), it works, but if attached to /dev/cons0 (as in
cmd.exe), nothing works as no signal is propagated from
the window resize to running program.
AFAIK, though, that's always been one of multiple
probs in using windows cmd with a bash shell.
--
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: Cygwin doesn't handle SIGWINCH properly in Windows Terminal
On 2021/02/14 00:43, Takashi Yano via Cygwin wrote:
This is because cygwin console handles SIGWINCH when the input
messages is processed. If the process does not call either read()
or select(), SIGWINCH will not be sent. This is the long standing
problem of the implementation and hard to fix.
This seems to be a bug of console code. I will submit a patch
for this issue.
---
I'd be careful 'fixing' this, as it seems to work the same
way on linux / bash.
I have this func setup on bash_profile & bashrc on
both cygwin and linux:
# display new size of terminal when resized
:
showsize () {\
declare s=$(stty size); s="(${s// /x})" ;\
printf "%s" "$s${s//?/$'\b'}" ;\
}; export -f showsize
trap showsize SIGWINCH
-
Of note, on linux, I didn't have to reset LINES/COLUMNS,
however, on cygwin, I note that I should.
Oh well -- hmmmis that a bug?
--
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: switching to any other than English keyboard layout is not handled correctly anymore on the prompt at minimum
On 2021/01/25 14:20, Ariel Burbaickij via Cygwin wrote: and this is what I get upon attempt to submit little sweet ö: $(__fzf_cd__)Ignoring redcarpet-3.4.0 because its extensions are not built. ... 1: from /usr/bin/fzf:929:in `get_input' /usr/bin/fzf:929:in `ord': invalid byte sequence in UTF-8 (ArgumentError) $ and I mean what I say, pressing ö immediately leads to it, no tricks, no custom builds, no debugs enabled, no nothing. --- Remember in my first post, I said that the codes you included were not valid UTF-8. It sounds like your program wants UTF-8, but your keyboard is putting out latin1. Did you download that program I mentioned? In there you can select the 'o' with diaeresis then copy/paste it into your program. The character you are inserting into your program isn't encoded in UTF-8, so I'm pretty sure that your keyboard isn't producing UTF-8 encoding. You mention that it does work after you restart your terminal. Setting in locale don't take effect in the current terminal, but in future ones that you start. So it is a good idea to restart your terminal after you change locale. I assume the error you are showing is from a window that wasn't restarted after your locale was changed? -- 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: switching to any other than English keyboard layout is not handled correctly anymore on the prompt at minimum
On 2021/01/25 12:50, Ariel Burbaickij wrote: Wait a sec, what do you specifically mean with "... Cygwin just uses the POSIX standard..." -- POSIX standard for what and how does it interfere with getting the current layout and mapping from OS? --- Cygwin doesn't get things directly from the OS. It relies on things like the locale being set correctly in order for it to function. Windows does not use the POSIX or unix/linux type API, so changing settings in Windows isn't something that will necessarily configure cygwin to work. If you are using the cygwin terminal, I don't know -- I don't use the same features. But, for example, bash, the shell likely running in the cygwin terminal, has its own understanding of how it should process characters. It, in turn, relies on the "readline" facility. It may be configured by default, but a few settings, I had to set *ages ago* (been using cygwin for >20 years) in the ".inputrc" file in my home directory: set convert-meta off set input-meta on set output-meta on Those all may be default settings now, but at one point in time I think I had to set them. What do you also mean with "... So you need to set your terminal to interpret unicode..." ? My terminal is Cygwin Terminal here. cmd.exe does at least handle Russian and German just fine, not so Arabic and Hebrew but this, I am pretty sure, because of some additional fiddling around right-to-left writing needed. Notepad++(!) already handles all input types just fine as do all the other programs tested so far. So, what are these supposed big OS-side secrets specifically that cygwin cannot get to here? --- It isn't a matter of "can't", it is a matter of doing so would cause cygwin not to behave like programs on linux or on unix. Cygwin relies on settings in configuration files -- not OS-side hidden secrets. At one point in time, most to all of windows internals were undocumented. On unix/linux/posix they worked together to document how all the programs would work together, but windows wanted no part of that. Just like the path-separator on windows is usually '\'. Bill Gates chose that specifically because it was the "opposite" of "/" that was used on unix and CP/M (a micro computer OS at the time). He wanted to differentiate his offering by making sure DOS and Windows did things differently from how standards were shaping up (early 80's) in other OS's. You and others are stuck with the legacy of those choices. Just like if you set the keyboard in a MS app running on an apple OS, it wouldn't necessarily change anything in the apple OS. They went yet another, different way. At least MS didn't sue everyone who came close to their standards or software like Apple did (and still does). This prevented any sort of compatible software from outside of Apple's approval. MS could have gone that way -- but because it was the largest, it got some controls slapped in place to allow compatibility. Cygwin arose out of linux + posix compatibility -- not out of Windows, as such, you need to figure out how to configure cygwin separately and apart from Windows. Cygwin tries to document things and follow open standards. In the extreme, cygwin has open source, so you can see how it works, and change it yourself to suit your needs (or hire a software engineer to do so). Windows and apple don't supply source nor extreme detail in how their OS works. I was trying to be helpful and tell you that cygwin interfaces may need extra configuration if you want to personalize things or go with non defaults. On windows, if you want to do anything outside of what the OS clearly presents to you, it will be a much more difficult path to change anything. I don't know the answers to the questions you are asking, I don't work on cygwin, I just use it on windows as a slightly more comfortable text-based interface than what windows has provided over the years. I have some background in linux which makes cygwin's interface more familiar to me. I've never gotten into Windows development, since it was always too costly and too dead-end. Several technologies from MS have come and gone over the past 40+ years. I could have invested in learning any of them, and now, many or most would be gone. Given that, learning a special API that would only be usable for windows, that likely would be obsolete in 5 years, and paying for the privilege of being allowed to use such an API and tools seems like a waste of time. As such, things I learned about unix and shell 30 years ago, are still usable + useful today. I don't know how to create a keyboard layout on linux, I use what is there. I certainly don't know how to modify a cygwin/posix keyboard layout to be compatible with windows. Sorry. Maybe someone else knows more. If you want cygwin to automatically read your changes in windows, I'm told that the cygwin project would be happy to accept patches and source up
Re: switching to any other than English keyboard layout is not handled correctly anymore on the prompt at minimum
On 2021/01/25 06:03, Ariel Burbaickij via Cygwin wrote: It says following: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= but why would it matter in the scenario where the user switches the layout explicitly him-/herself? Because the OS (the keyboard driver) needs to know what mapping is used on the keyboard, so that when you press a key, the keyboard driver sends the keycode with the correct meaning to programs. The keys on your keyboard, _inherently_ have no meaning. They have an "assigned" meaning as assigned by the locale settings so they can send those characters to a program. If you create your own layout, you need to create a *custom* mapping in POSIX. Cygwin just uses the POSIX standard, it doesn't create the mapping or the meanings. (what cygwin uses -- cygwin didn't create its own system, it uses the POSIX standard). On Mon, 25 Jan 2021 13:46:48 +0100 Ariel Burbaickij wrote: Hello Cygwin, I tried to find some files from the command line prompt which are named using various non-Latin (Russian, Hebrew, Arabic) and non-default Latin (German) layouts under Windows 10 Enterprise using recent cygwin version and the outcome is that instead of representing letters I see control characters of the type: \263\320\321 (Unicode numeric value of the letters?). Any ideas what happens here and how correct functionality can be restored? --- Note that the characters you type are 1 thing. How a program interprets those characters is by using the "locale" settings. The locale is using UTF-8. So you need to set your terminal to interpret unicode. I don't know much about Win10, but in the Microsoft cmd.exe prog, "chcp" changes the code page. The code page for UTF-8 is 65001, so in such a terminal you could type: chcp# this should say something like: Active code page: 801 # your number may be different # Remember it to switch back to your initial code page (or just # close the cmd window). To switch to UTF-8, type: chcp 65001 That will interpret output as UTF-8 in that program. Note, I'm not sure that will be all of your problems. "\263" is not valid for the 1st byte of a UTF-8 string. Valid First bytes of a single UTF-8 char (in hex): 00-7f, c2-cf, d0-df, e0-ef, f0-f4. So if you see something like 0xb3 in the 1st byte of a unicode character, you know it can't exist (part of UTF-8's self-synchronizing feature). A very useful utility for displaying all unicode characters and what character sets you have that can display them can be found at: https://www.babelstone.co.uk/Software/BabelMap.html Unzip it into a folder and put a link to it where it is easy to access. Hope this helps. -- 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
Need admin privs before something can inherit them (was Re: ssh-host-config doesn't "inherit" user admin privilege)
On 2021/01/14 17:21, art wrote: I get a security code 5 when ssh-host-config tries to install cygsshd. I was logged into Win 10 pro/x64 as an admin user. The "fix" was to start a Cygwin64 Terminal with Admin and then run ssh-host-config within this script. You say ssh-host-config tries to install cygsshd. How was ssh-host-config called (started)? When Cygwin64 Terminal was run, it was run with Admin at the start. Was that done when ssh-host-config was run? How was it run? unrelated...: Veni, vidi, vectori! @1976, 2021 --- You like vectoring, I take it? :-)? Cheers! Linda -- 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: Workaround for cygwin's way of linking folders?
On 2020/12/06 14:41, Johnathan Schneider via Cygwin wrote: Hi all, I'm setting up a cross platform development environment using Cygwin. Upon attempting to use Cygwin's CMake that is natively bundled, I discovered that Cygwin goes looking for the gcc in /usr/bin/cc, If you go into 'bash' under cygwin, what do you see in /usr/bin? /usr/bin is only a valid path inside programs that are running on cygwin -- if you run programs outside of cygwin, say directly from Windows, they won't see them. Cmake would likely be in the same folder as gcc. How are you invoking Cmake? If you are running cmake from, say, the cygwin path of /bin (assuming you have cygwin installed at C:\ and have your cygwin mount prefix set to '/'. In bash, type mount -p and you should see something like: mount -p Prefix Type Flags / user binmode Just like windows has various magic folders that show up under explorer, but don't really exist, cygwin does too, but only cygwin utils see the cygwin-folders. FWIW, /bin from a cygwin install is mounted (within cygwin) on /usr/bin, so the contents should be the same. If you want to make use of windows+cygwin at the same time, it's best to install cygwin at 'C:\' and set you mount prefix like I have above, then you will get more commonality between windows+cygwin. For example, to make /usr/bin appear under window, I have a symlink at C:/usr/bin that points to C:/bin. Under windows, a 'dir' of C:\usr will show (from cmd.exe, some lines removed for brevity): C:\Users\linda>dir \usr Volume in drive C is System Disk Directory of C:\usr 2020/05/17 17:11 . 2020/05/17 17:11 .. 2018/05/19 09:42 bin [..\bin] 2020/10/07 09:35 include 2018/05/19 09:41 lib [..\lib] 2018/05/17 11:20 lib64 [..\lib] 2020/12/06 23:25 sbin [..\sbin] 2020/11/03 20:38 share 2020/10/07 08:37 src 2020/05/17 17:11 x86_64-pc-cygwin 0 File(s) 0 bytes 17 Dir(s) 150,639,538,176 bytes free Alas, my question - what is the recommended workaround? --- Look for cygwin paths from a cygwin shell. That's the start. Making win+cyg play nice, involves little bits like symlinks like I used above. It's not officially supported by the cygwin, but I find such things convenient. -- 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: Updated: fetchmail-6.4.14-1
On 2020/12/04 12:18, Achim Gratz wrote: L A Walsh writes: I see no reference to any python of any version. Yes, the package does depend on it, and as noted in the announcement it depends specifically on python36. So, people who configure fetchmail with the man page and have never used fetchmailconf should get in the habit of ignoring package requirements? Not sure how good that is. When I look at the fetchmail website, https://www.fetchmail.info/, I see that it lists https://sourceforge.net/projects/fetchmail/ as a project page, but with sources on https://gitlab.com/fetchmail/fetchmail/ . I see no mention of python being required on its info page, though I see it mentioned on the sourceforge site. Oh please, it isn't all that hard to figure out that fetchmailconf is implemented in Python. Oh please yourself! :^) I've never used fetchmailconf in using fetchmail. fetchmail doesn't require python -- a special "fetchmailconf" requires it, which wasn't part of fetchmail when I started using it -- for that matter it still isn't part of my linux distro's fetchmail. I read the manpage and edited .fetchmailrc in my home directory. I started using fetchmail before fetchmailconf was around, AFAIK. Maybe putting fetchmailconf in its own package would be appropriate? -- 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: Updated: fetchmail-6.4.14-1
On 2020/12/02 12:29, Achim Gratz wrote: fetchmail-6.4.14-1... This release uses the Python3 interpreter as Python2 is now EOL... When I look at the binary on linux (ldd), I see no reference to any python of any version. I haven't seen the 6.4.14 package for my distro yet, but the 6.4.12 version doesn't require python. When I look at the fetchmail website, https://www.fetchmail.info/, I see that it lists https://sourceforge.net/projects/fetchmail/ as a project page, but with sources on https://gitlab.com/fetchmail/fetchmail/ . I see no mention of python being required on its info page, though I see it mentioned on the sourceforge site. Should fetchmail have a dependency on python when it doesn't seem to be needed? Maybe put the python requiring stuff in a separate 'python-fetchmail' package to install that portion? Should I be guessing -- is it a python interface for fetchmail? I know I would be surprised if I went to install (or upgrade) fetchmail and it required me to install python. Seems like many(most?) other python interfaces for things reside in 'python-xx' packages -- is that an oversight for the fetchmail code? Tnx! -linda -- 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: Please add /cygdrive/c/Windows/Sysnative to the default PATH
On 2020/11/17 15:41, tealhill via Cygwin wrote: ### Summary Why should Cygwin add Sysnative to $PATH? As a workaround for Microsoft's failure to add Sysnative to %PATH%. ### Full explanation Cygwin imports the Windows %PATH% variable at startup. It would be ideal if Microsoft would add Sysnative to the default Windows %PATH%. Such a change would help Cygwin users and others. But I doubt that Microsoft will make this change. Adding sysnative, **incorrectly** would add 64-bit applications to a 32-bit path. You are asking a non-windows environment, Cygwin, that in order to be POSIX compatible, it should add a windows path? Name ONE other unix or posix platform that does this by default. -- 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: surrounding double quotes not removed from native command line arguments when they contain unicode and locale is default
On 2020/11/12 08:10, Ilya Basin via Cygwin wrote: Hi. When I launch a Cygwin program from a native Windows program and an argument in the command line string is quoted and contains national characters then the Cygwin program behaves as if double quotes were part of the program argument. This happens if I don't explicitly set LC_ALL or if I set LC_ALL=C or set LC_ALL=C.UTF-8 The argument handling for cygwin and posix programs comes from the shell that is used. The native windows programs don't have that. Best thing to try is to run bash as a wrapper around the program, like: C:/cygwin/bin/bash.exe -c "/cygwin/c/test-z-я/some.txt". Make sure your LC_CTYPE is set to a valid value for your area, like mine is set to "en_US.UTF-8". Only my LC_CTYPE is set to something other than the default, like: locale LANG= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= This is a problem because arguments with spaces must be quoted. If I set the locale to some language and country the quotes are removed as expected no matter what code page I use, UTF-8 or a single-byte code page. The locale doesn't have to match the alphabet used. Right -- it is just for other stuff, but the problem is the locale program still wants *some* valid value. Type "locale -a" to list all locales and pick whatever is closest to where you are, or pick "en_US", like you said, doesn't really matter -- but: C:\>set LC_ALL=C.UTF-8 C.UTF-8 isn't a valid value for LANG or LC_ALL. You probably don't want a single code page for your language like: C:\>set LC_ALL=en_US.CP1252 C:\>C:/cygwin/bin/ls -l "C:/test-z-я/some.txt" -rw-r--r-- 1 il None 0 Nov 12 09:52 'C:/test-z-'$'/030''N'$'/217''/some.txt' Because if you use a character that isn't in that code page, you are likely to have problems. You want to use a UTF-8, or utf8 codepage. Like this: C:\>set LC_ALL=en_US.UTF-8 That's the way the locale system works/interacts with windows. Just use quotes + UTF-8 -- that way you can write your stuff consistently and get consistent results. It's even better if you just use 'bash' and avoid the Win-Cyg-Win boundary translations. -linda -- 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: Commercial use of cygwin
On 2020/11/12 02:42, Marco Atzeri via Cygwin copied the whole note: On 12.11.2020 09:42, Antonio Sidoti via Cygwin wrote: I was looking into using Cygwin for commercial use... [27 lines of duplicate text] in general there is no restriction on usage. Marco If you are going to bottom post, please trim your quotes. If you need to quote the original for context, only quote what is needed for context. In a threaded reader, your reply is placed under the original poster's email, where, if a reader is interested, it was just read. Duplicating the entire note isn't necessary nor, I'd bet, really wanted, by most. -- 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: Strange paths in NTFS reparse points created by Cygwin Setup for e.g. TTF fonts
On 2020/11/08 06:40, Michael Soegtrop wrote: What I don't understand is why it does work sometimes and sometimes not. I always use the same scripts to install and remove cygwin on the same machines and then do pretty much the same thing with this cygwin (build our open source software) before I delete it. Likely because the windows settings are different on the various machines -- especially the various policies. But, first, basic, you know that windows symlinks are turned off for normal users by default when they first get it (i.e. they can't create them). Which ways work and who can create them are settings under fsultil/behavior/(set/query) symlinkEvaluation. These 4 settings control directions of symlinking There's another setting that is suppose to control where fonts can be installed, but can't find it off hand -- in the group policy editor. If I remember, it was suppose to allow/disallow fonts being installed in folders other than /windows/fonts. I think the default might be to allow, but am not sure. I thought I disabled it, and what I've seen is the same font-file hardlinked between windows/fonts and the application path. It is unlikely that the issue is that the target files are open as L A Welsh suggested because always either all symlinks or none at all remain. The number is always the same (with recent versions afair 258). Windows doesn't hold open all fonts -- but some subset -- they have some font cache services that may be running at times to support some apps. So could be if one of those apps has run, it started its font caching service, which could lock it. Each font system has a set of "core fonts" that it will load whether they are called upon or not -- that could create a toggle situation between a bunch being used or not. Some applications (though I don't think rm does this) will follow the symlink by default, so when they try to delete a file, it doesn't delete the symlink but tries to delete the font, which may be opened by some service. BTW, are you familiar with 'Process Hacker' (google it, its open source, and hasn't been changed for a while). It can replace the task manager and ProcessExplorer that MS helps distribute. It's more powerful than either. But specifically if you can't delete a file, you can find out what process(es) have the file open. Finding that out might enable you to find the what apps might be running and holding those files open. Symlinks and their older counterparts mountd+junction have different formats for directories and volumes. Some will work with network, some not. If they are all Microsoft windows symlinks, you might look at the fsutil settings -- as well as open files. You maybe said, but don't remember -- is there any error message when you can't delete those files? @ L A Walsh: you wrote "1) if you try to delete the file in cygwin" Why shouldn't I be able to remove symlinks with rm -rf from within a cygwin? As far as I understand the standard behavior of "rm" is to remove the symlink and not its target. --- With posix/linux type symlinks, yes, but am not equally sure that windows behaves the same in all circumstances. One thing you could try is to use cygwin-only symlinks and not use native symlinks -- the cygwin-only links should be more reliably just controlled by cygwin rules. If they are native links, there might be some windows settings interaction(s). In case it doesn't work the symlinks are quite hard to get rid of. FSUTIL REPARSEPOINT DELETE is the only method which works I found so far. Even after a reboot, resetting the ACLs in various ways, ... no usual method to remove these files works. --- How were these links created? Also, MSsymlinks unlike unix symlinks require the target's existence when they are setup. unix symlinks do no checks on the target. If the target is missing, some operations on that symlink (if it is a win-symlink) might not work as expected. Also note, that these two entries in my root dir look like this from unix: lrwxrwxrwx 1 20 Nov 6 2014 Prog -> /Program Files (x86)/ lrwxrwxrwx 1 13 Apr 21 2013 Prog64 -> Program Files/ Both sorta look like symlinks. But in windows, they look different because they were made differently, and they may have different effects on 'rm' from cygwin. 2014/11/06 19:45 Prog [C:\Program Files (x86)] 2013/04/21 22:53 Prog64 [Program Files] 1. Make sure the symlinks you see in cygwin are the same type. 2. you say you have symlinks left over after you try deletion. Do they point to existing files? or not? If not, what happens if you create the target of one of them, and then try deleting the symlink? 3. you said you had to use fsutil to remove so
Re: Strange paths in NTFS reparse points created by Cygwin Setup for e.g. TTF fonts
On 2020/11/05 13:41, Michael Soegtrop via Cygwin wrote: I wonder if the path "/mnt/c/Windows/Fonts/wingding.ttf" is something which should be written into a NTFS reparse point by cygwin setup. Probably not - it looks like a cygwin path and it is understandable that this confuses NTFS. Uhexcept that "/mnt/c/Windows/Fonts/wingding.ttf" is a valid NT pathname (file and reg). For that matter, "/mnt/\x00\x01\x04" is a valid NT pathname -- how, why?: NT uses a 'count' hidden before the string, so any character is valid. However, the above is not universally true in 'Windows' where some system libraries enforce using backslash as the separator. I'm guessing you get some permission denied messages when you try to delete some fonts. This can happen in 2 cases: 1) if you try to delete the file in cygwin or 2), if some program hardlinked the font to the same in the windows directory instead of symlinking it. With both, it comes down to your delete command trying to delete (for example) a font that is linked into the /windows/fonts dir and some program (or lib) already has it open. Generally, you can't delete *open* files in Windows. In windows, an open will lock some range of bytes on the disk. Windows "lock"s are locks on byte ranges, "on disk" that windows won't let you write to, move or delete while someone has that file open. -- 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: Conflict if same username local and in domain
On 2020/10/31 03:56, David Balažic wrote: I don't have any of /user /users /User /Users folders on my setup. Do you mean C:\Users ? --- Sorry, yeah. Even if I symlink it, won't that just change the location, but not the used usernames? You have one user in the Domain and one on the machine. Right? I mean, you've verified that they have different "GUIDs" or "UUIDs" -- meaning that windows see them each as separate accounts. When you login to each username under windows, run 'cmd.exe', then echo %USERPROFILE%, %HOMEPATH%. If you are getting the same value, I think you don't really have 2 accounts -- but since you got the access denied, it sounds like you do. Easiest is to put your homedir in or under your your HOMEPATH directory. like in cmd.exe, I think it's: mklink /d C:\home "C:\%HOMEPATH%" (sorta backwards what you might do at the cygwin prompt)... -- 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: Conflict if same username local and in domain
On 2020/10/29 05:39, David Balažic via Cygwin wrote: Hi! I started Cygwin Terminal to find out, I landed in the other users home folder and have no write access. I have the same username, but not the same "home" directory. The user that signs in 1st gets the short name, the 2nd login gets the domain or system name appended like /users/linda/local-account /users/linda.domain/domain account. Both of the user names have uniq windows UUID's and I have both in my /etc/passwd. The two directories SHARE many of the same files -- so both my logins are in a common 'local' group (like 'lindaGroup'), and since the machine is in the domain, I can create a 'domain\lindagroup' and on my local machine, both logins are in that group -- for that matter, the domain group is also in the local group -- so theoretically I could just put both logins in the domain group. Anwyay, it DOES work -- it just has to be configured right. So you say you got /home/joe for both -- but don't they have a /user directory that is different for each? just point your /home/=>/User, or if you really want them separate, then have /home/joe point to /Users/joe/home, and the domain should get joe.dom so /home/joe.dom => /Users/joe.dom/home. I started with my /home dir pointed at my the same dir as my /users dir, so by default, windows separated them. Both my userid and username are different -- have 2 entries in /etc/passwd: Bliss\linda:*:5013:201:L A Walsh,U-Bliss\linda,S-1-5-21-3-7-3-5013:/Users/linda.Bliss:/bin/bash linda:*:1000:1015:U-Athenae\linda,S-1-5-21-188-75-11-1000:/Users/linda:/bin/bash -- 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
bug in cygwin perl
I'm using perl 5.26.
The following perl-lib function fails.
perl -e 'use charnames qw{:full};'
Undefined subroutine utf8::SWASHNEW called at /usr/share/perl5/5.26/_charnames.p
m line 176.
Compilation failed in require at /usr/share/perl5/5.26/charnames.pm line 6.
BEGIN failed--compilation aborted at /usr/share/perl5/5.26/charnames.pm line 6.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
Haven't tried newer versions due to problems.
Also, 'cpan' fails due to the same error:
cpan
Undefined subroutine utf8::SWASHNEW called at /usr/share/perl5/5.26/Safe.pm line
70. ...
Is this known to be fixed in 5.28 and/or 5.30? Maybe that module
can be fixed?
Thanks,
linda
perl -v shows:
Summary of my perl5 (revision 5 version 26 subversion 3) configuration:
Platform:
osname=cygwin
osvers=3.0.7(0.33853)
archname=x86_64-cygwin-threads-multi
uname='cygwin_nt-10.0 cygwinpro 3.0.7(0.33853) 2019-04-30 18:08 x86_64 cygwi
n '
config_args='-des -Dprefix=/usr -Dmksymlinks -Darchname=x86_64-cygwin-thread
s -Dlibperl=cygperl5_26.dll -Dcc=gcc -Dld=g++ -Accflags=-ggdb -O2 -pipe -Wall -W
error=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-b
uffer-size=4 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/build=/usr/s
rc/debug/perl-5.26.3-2 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64/sr
c/perl-5.26.3=/usr/src/debug/perl-5.26.3-2 -fwrapv'
hint=recommended
useposix=true
d_sigaction=define
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='gcc'
ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 -
pipe -Wall -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64
/build=/usr/src/debug/perl-5.26.3-2 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/p
erl.x86_64/src/perl-5.26.3=/usr/src/debug/perl-5.26.3-2 -fwrapv -fno-strict-alia
sing'
optimize='-O3'
cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -D_GNU_SOURCE -ggdb -O2 -
pipe -Wall -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/perl.x86_64
/build=/usr/src/debug/perl-5.26.3-2 -fdebug-prefix-map=/mnt/share/cygpkgs/perl/p
erl.x86_64/src/perl-5.26.3=/usr/src/debug/perl-5.26.3-2 -fwrapv -fno-strict-alia
sing'
ccversion=''
gccversion='7.4.0'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
cygwin permissions on folders creating problems for windows applications (like explorer, gvim)
I was trying to edit files in /etc/ssh: /etc/ssh> gvim sshd_config Error: Current working directory has restricted permissions which render it inaccessible as Win32 working directory. Can't start native Windows application from here. setsid: failed to execute gvim: Permission denied The files were owned by a domain account which is broken right now. An Aside (I think) (my workstation became unjoined after a windows update and the trust between workstation+samba DC was broken. Tried removing + re-adding only to get: The join operation was not successful. This could be because an existing computer account having name 'ANY' was previous created using a different set of credential. Use a different computer name, or contact your administrator to remove any stale conflicting account. The error was Access is denied. So far, I've been stymied on that front as well End of aside The dir was owned by a domain account, so chowned it to a local account+ group, and no effect. Noticed an ACL on it from the + in ls. my lsacl script shows: /etc/ssh> lsacl . [u::rwx,u:Administrators_u:rwx,g::rwx,g:SYSTEM:rwx,g:Users:r-x,g:Authenticated Users:rwx,m::rwx,o::---/u::rwx,u:Administrators_u:rwx,g::rwx,g:SYSTEM:rwx,g:Users:r-x,g:Authenticated Users:rwx,m::rwx,o::r-x] . and getfacl shows: /etc/ssh> getfacl . # file: . # owner: Administrators_u # group: Administrators user::rwx user:Administrators_u:rwx group::rwx group:SYSTEM:rwx group:Users:r-x group:Authenticated Users:rwx mask::rwx other::--- default:user::rwx default:user:Administrators_u:rwx default:group::rwx default:group:SYSTEM:rwx default:group:Users:r-x default:group:Authenticated Users:rwx default:mask::rwx default:other::r-x Looking in explorer I see a NULL SID with Deny of Traverse, Read ext attrs and perm, and del subfolders for the folder only. Authenticated users get denied for folder Create files/write data, Create folders /append data, write attrs, write ext.attrs, + delete subfolders+files Then they get some perms for folder+subfolds+files and a copy of the null sid denials... Explorer maintains that "The permissions on etc/ssh are incorrectly ordered which may cause some entries to be ineffective. In order to change any permissions, windows requires they be reordered. I've run into this stuff before with cygwin permissions being incompatible with windows permissions. I've sort of ignored it for the most part as my domain account generally had permissions to what I needed, but my local account hasn't had the same treatment. So I can reinstall new acls for the local equivalents of the domain accounts or I can try to figure out why cygwin has to use acls that are incompatible with windows applications -- and by incompatible, I mean they won't start. Oddly enough Samba seems to be able to store cygwin Acls, in a way that doesn't seem to require a disabling of windows acls nor linux acls. I may be wrong, but I seem to have a feeling that this has to do with a decision to use Sun-ACL's in cygwin while Samba uses Posix ACLs. Also, something I didn't understand is I seem to remember that something special had to be done to implement a primary group on the files -- yet, since Vista, MS has had a primary group on their files to support their POSIX subsystem. Is that currently being used? If not, would it be possible? The group ID may not be figuring into how the cyg-acl's are very incompat with window's acl's, I dunno. But my main concern is not being able to start any windows apps in directories where cygwin has set the permissions as they seem to be incompatible. Can these be made compatible? If there is some behavior that would have to change in regards to how cygwin acls + permissions behave, could it be based off an environment variable -- to use more compatible posix ACL's rather than sun ACL's? I may be showing a great deal of ignorance, but it seems that cygwin is supposed to be a posix implementation -- wouldn't posix acls make more sense? Thanks... Linda -- 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: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities
What are you complaining about? What erroneous behavior? We can't read your mind, but it isn't clear what you think is going wrong -- so how are we supposed to figure out what the erroneous behavior is? Please give an example of what you think is wrong and what you expected instead. Please be clear enough that your own mother and father would clearly understand the problem. Also, is there a reason you submitted this to the cygwin list instead of the bug-b...@gnu.org list? On 9/7/2020 11:24 PM, johnb...@email.com wrote: -- 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: cygwin1.dll: uname_x not found
On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > On Sep 7 14:34, L A Walsh wrote: >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ >>> >>> Please give them a try. >> --- >> Got: >> >> "The procedure entry point uname_x could not be located in the dynamic >> link library cygwin1.dll" > > uname_x is exported just fine. You're doing something wrong. > > Corinna --- I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. What step did I miss? Sorry, I know whatever I missed is obvious to you -- it always is obvious to someone who knows the answer, but to those that don't know the answer, it isn't at all obvious. I have used test libraries before the same way and had them work. So I don't know what I missed. -- 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
cygwin1.dll: uname_x not found
> > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > Please give them a try. --- Got: "The procedure entry point uname_x could not be located in the dynamic link library cygwin1.dll" :-( -- 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: Bug in 'grep'ing for string in /proc/registry...
On 9/7/2020 12:05 AM, Brian Inglis wrote:
>> /bin/grep -Pr '\.dll'
>> /bin/grep: Group: Is a directory
>> /bin/grep: ImagePath: Is a directory
ImagePath is a expandable string value under the Eventlog
key. 'ls -l' shows ImagePath has having 65 bytes.
> ll ImagePath
-r--r- 1 65 Sep 6 22:06 ImagePath
Reading the contents, one gets:
>>> read -r x >> echo $x
>> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
>> whose length is ${#x} = 64 (not counting end-of-string)
> You remember that the /proc/registry.../ entries are only the
> keys, subkeys, and kk values names, not the data contained in them.
---
Not exactly. Keys are the fs-equivalent of directories,
subkeys are the equivalent of subdirectories, and values are filenames
that usually contain content. Any util that would normally read
file-content (or scan through it, like grep) will read the content in
registry values.
> You are doing the equivalent of:
> $ fgrep -r .dll
---
Correct. Which is almost the same as
fgrep -r .dll .
with the difference that results with the "." will have a "./" on
the front of the names, i.e.
>> /bin/fgrep -r .dll .
>> /bin/fgrep: ./Group: Is a directory
>> /bin/fgrep: ./ImagePath: Is a directory
I'm not sure, but it looks like you may be confusing
the function & output of 'find' and grep? Where find looks only
at the names, whereas 'grep' scans for the text string in the
content of the files. Given the '-r' param, 'grep' will descend
into directories -- not attempt to scan them as text files.
> producing nothing but error messages.
---
Normally text files are not classified as directories.
Both 'ls' and 'bash' classify keys as 'directories', while values,
of every sort are classified as files.
linda
--
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
Weird behavior in 'grep'ing for string in /proc/registry...
In directory /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog I wanted to list all the ".dll"s that handled various types of events. I tried /bin/grep -Pr '\.dll' but got a load of bogus error messages: /bin/grep: Group: Is a directory /bin/grep: ImagePath: Is a directory /bin/grep: Description: Is a directory /bin/grep: ObjectName: Is a directory --- looking at ImagePath: > ll ImagePath -r--r- 1 65 Sep 6 22:06 ImagePath > read -r x echo $x C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted --- Doesn't look like a directory. So, bug in 'grep'? I'm hoping this isn't limited to my machine... Thanks! linda -- 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
How can I access & save reg acls? RFE-/proc/registry passthrough ACL's?
If you look in the registry editor, entry permissions similar to those found on files -- complete access control lists for permissions, auditing and integrity levels (MEDIUM, HIGH, SYSTEM 'Mandatory Levels') are shown. Also, a creation or last-mod time is stored that may be the timestamp shown in /proc/registry. I tried running getfacl on the /proc/registry entries, but it said it wasn't supported. Could, at least, R/O access to the ACL's be allowed through the proc/reg FS? Is there some other way other than using the registry editor to look at them? Thanks, -- 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: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash
On 2020/04/02 06:43, Andrey Repin wrote: That's not what actually happens. ...\Documents> ls -1 *.pdf 21927-ticket.pdf 'Stars! Universe Map.pdf' --- Thank you for your update. -- 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: bug report: shell expansion in argv[] processing sensitive to LANG, e.g. "ls: cannot access '*.pdf': No such file or directory", but works okay in bash
On 2020/03/24 00:18, Jay Libove via Cygwin wrote:
Problem:
Under certain circumstances (see Steps to Reproduce, below) Cygwin programs'
built-in argv[] globbing will produce unexpected:
"{programName}: cannot access '{glob pattern}: No such file or directory"
e.g.
"ls: cannot access '*.pdf': No such file or directory"
.. despite the fact that e.g. *.pdf definitely exists.
This isn't a bug or a problem, it is working normally as expected.
Cygwin programs don't have built-in argv[] globbing or processing.
The problem you are seeing is because you are calling cygwin programs
from a windows shell.
On windows, every program has to be built with glob processing.
On unix, glob processing happens in the shell, so all unix
(linux+cygwin)
type programs have no glob processing because they know that globbing is
built
into the shell (like bash or csh, or dash, etc).
If you run 'ls' *.pdf in bash, bash expands the *.pdf into arguments
that don't contain a glob (if the glob matches a file). So 'ls' sees
only fixed filenames and no globs.
When you run 'ls from the Windows shell, Windows cmd.exe doesn't expand
glob chars into anything. so 'ls' sees a literal file name of '*.pdf'.
On linux you can name a file '*.pdf' (using an asterisk as a valid
character).
Unless you have a file named, literally '*.pdf', ls won't see it.
Cygwin does simulate this: example:
cd /tmp
/tmp> touch \*.pdf
/tmp> ls *.pdf
*.pdf
/tmp cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\tmp>ls *.pdf
ls *.pdf
'*.pdf'
^^ note that now windows find *.pdf because there is a file named '*.pdf'
(quotes added by 'ls').
Does this explain your issue, or am I not understanding it?
Thanks (I'm not a cygwin author; just answering the question)
Linda
Steps to Reproduce:
* Have some files in the local director with accented characters in the names,
e.g.:
C:> mkdir c:\temp\test
C:> cd c:\temp\test
C:> touch h�llo.pdf
C:> touch g�odbye.pdf
C:> touch normal.pdf
* DON'T have the LANG= environment variable set to anything
* NOT in bash or Cygwin Terminal, but rather within Windows CMD.exe, execute a
Cygwin command which needs to do file name globbing because the Windows CMD.exe
shells does not do so for it, e.g.
C:> ls *.pdf
C:> cat *.pdf
These will produce "ls: cannot access '*.pdf': No such file or directory"
Although, curiously,
C:> ls *or*
does correctly produce:
normal.pdf
Also, display output of the �cc�nted characters is incomplete:
C:> ls
'g'$'\303\262''odbye.pdf' 'h'$'\303\251''llo.pdf' normal.pdf
C:> bash
jay_l@DESKTOP-I9MRIE3 /cygdrive/c/Temp
$ ls
'g'$'\303\262''odbye.pdf' 'h'$'\303\251''llo.pdf' normal.pdf
Analysis:
I've verified that it's not about case sensitivity. That is, it's not a matter
of ls *.pdf vs. ls *.PDF.
If these test commands are run either under bash.exe or within a Cygwin
Terminal window, the problem does not occur.
I've verified that the Windows system locale (per Windows' Region setting)
actually doesn't matter. (I've reproduced this both on systems in Region Spain
with language English-International and English-Ireland, and in a VM with a bog
standard vanilla US English Windows).
Credits to Paul for suggesting deleting files one by one until the problem goes
away, and to Andrey for pointing out `locale` and the LANG= setting.
Set LANG=en_US.UTF-8, e.g.
C:> set LANG=en_US.UTF-8
.. and the problem goes away.
C:> ls *.pdf
g�odbye.pdf
h�llo.pdf
normal.pdf
C:> ls
g�odbye.pdf
h�llo.pdf
normal.pdf
Interestingly, Andrey mentioned that he sets LANG=ru_RU.CP866 and he doesn't
see the problem. When I tried that exact setting, I still had the problem.
So it's maybe not just that LANG must be set to *something*, but that somehow
LANG must be set to something that matches something in Windows? (Sorry, I know
that's nearly uselessly vague).
In summary, it appears that the way that the argv[] globbing code which gets
compiled in to Cygwin programs functions a bit differently than the way the
shell globbing code works within bash.exe.
And this produces unexpected globbing failures.
Thanks to all the Cygwin maintainers for this amazing software, for so many
years!
-Jay
--
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 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: Cygwin-OpenSSH 8.2.2.2
On 2020/02/27 14:30, Brian Inglis wrote: No, you must backport all sources to the current and all previous versions What all previous versions? Going back to year 2000 or before? That sounds a bit onerous. -- 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: Has rename syntax changed?
On 2020/03/03 15:45, Hans-Bernhard Bröker wrote:
Am 04.03.2020 um 00:25 schrieb L A Walsh:
On 2020/02/28 04:38, Fergus Daly wrote:
I am almost certain that the command
$ rename "anything" "AnyThing" *.ext
would alter the string from lc to uc as shown, anywhere it occurred in
any filename in *.ext in the current directory.
isn't that they same as "mv anything.xxx Anything.xxx" ?
No. For three reasons:
*) it's .ext, not .xxx :-)
*) it will find and replace 'anything' _anywhere_in_ the filename, not
just in the basename.
I'm confused about your terminology. If you type 'man basename', you'll
see something that is essentially this:
basename = [optional directory name '/'] basename [. extension (or
suffix)]
You said we are only working in 'cwd' so there is no directory name.
You said all of the filenames must match '*.ext'. The only part
left after the extension, ".ext", is removed is the basename. So while
your replacement can match _anywhere_in_ the filename, the filename and
basename
are the same after it matched the listed 'extension', no?
Second, rename doesn't replace the string '_anywhere_' in the filename,
but only
the first occurance:
rename anything AnyThing *.ext
ll *.ext
-rw-rw-rw-+ 1 0 Mar 3 19:24 oneAnyThingtwo.ext
-rw-rw-rw-+ 1 0 Mar 3 19:25 oneAnyThingtwoanythingthree.ext
While bash only works on 1 file at a time,
it can replace 1 or multiple occurances:
for f in *.ext;do
mv "$f" "${f//anything/AnyThing}"
done
ll *.ext
-rw-rw-rw-+ 1 0 Mar 3 19:24 oneAnyThingtwo.ext
-rw-rw-rw-+ 1 0 Mar 3 19:25 oneAnyThingtwoAnyThingthree.ext
If one wants to replace 1 occurance in multiple files, I would
still use 'mmv', as rename will overwrite files if there is a collision
whereas 'mmv' won't.
--
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: Has rename syntax changed?
On 2020/02/28 04:38, Fergus Daly wrote: I am almost certain that the command $ rename "anything" "AnyThing" *.ext would alter the string from lc to uc as shown, anywhere it occurred in any filename in *.ext in the current directory. isn't that they same as "mv anything.xxx Anything.xxx" ? What I remember as past behaviour now fails, leaving he filename unaltered. /tmp> ll *.xxx -rw-rw-rw-+ 1 0 Mar 3 14:30 anything.xxx /tmp> rename any Any *.xxx /tmp> ll *.xxx -rw-rw-rw-+ 1 0 Mar 3 14:30 Anything.xxx --- Works here on a local NTFS file system. (Failure in much the same way as mv would fail if the similar attempt was made.) ??? Like this?: /tmp> touch anything.xxx /tmp> mv anything.xxx Anything.xxx /tmp> ll *.xxx -rw-rw-rw-+ 1 0 Mar 3 14:30 Anything.xxx /tmp> rename Any any *.xxx (Good old DOS command rename (or the abbreviation ren) used to achieve multiple-rename in an easy manner that just eludes bash.) --- 'rename' is not a bash builtin or feature, neither is 'mv' nor my preference: 'mmv': /tmp> ll *.xxx -rw-rw-rw-+ 1 0 Mar 3 14:30 anything.xxx /tmp> mmv 'a*.xxx' 'A#1.xxx' #(same as "mmv a\*.xxx A\#1.xxx' ) /tmp> ll *.xxx -rw-rw-rw-+ 1 0 Mar 3 14:30 Anything.xxx FWIW: w/mmv, meta chars like '*' in source and '#' in target need to be quoted to protect from shell expansion. Anyway: has something altered (and quite recently, i think), or am I just mis-remembering the versatility of the command rename? I think that the 'whatever' that has changed is likely a different file system. Besides the above tests/examples on Win7/NTFS, I got similar results on a network share from a Linux-Samba server. Oh -- one more potential gotcha: the '*.xxx' pattern you are giving to rename is subject to shell expansion (shell being bash in this case). If the *.xxx doesn't match all your targets and bash doesn't have 'nocaseglob' set, you can get: /tmp> shopt -u nocaseglob nocasematch /tmp> rename Anything anything *.xxx rename: *.xxx: not accessible: No such file or directory /tmp> shopt -s nocaseglob nocasematch /tmp> rename Anything anything *.xxx Why?: because my filename was 'Anything.Xxx' (Anything.XXX would do the same). Even though the file system ignores case, if bash is told not to ignore case, the '*.xxx' won't match anything but all lower case extensions. It's a contrived case, but illustrates that the pattern at the end isn't seen by 'rename' because it is 1st expanded by bash. Hope this helps, and isn't overkill! ;-) -- 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: rsync and ls -lR slow for directories with many files
On 2020/01/08 08:43, Frank-Ulrich Sommer wrote: but rsync did not get faster. I'm sorry to admit that the ultimate solution does not use Cygwin any more. I'm now using a Windows share and connect to that share from my Linux server with cifs and autofs. rsync then runs on the linux machine and accesses that share (due to --whole-file this should not cause problems). rsync without any changed files directly after booting both systems (both caches are empty) now takes 91s instead of 42m. --- I won't go into the many reasons I know of (which are very incomplete compared to those who actually created cygwin), but in situations like you describe, I almost never use rsync unless I don't care about time and desperately need a feature it has. Instead I'll find it's faster to create an uncompressed tar on windows, copy it to linux and expand it there to work locally with it. Any compression/signing/encrypting of data will slow down data transfer on my home network where max CIFS transfer speeds are in the 300-700MB/s range. Am 5. Januar 2020 22:22:35 MEZ schrieb Stephen John Smoogen : On Sat, 4 Jan 2020 at 17:16, wrote: I am running rsync on a small linux server to synchronize files in one directory and its subdirectories from Windows (using sshd from Cygwin) to this server for backup purposes. The directory contains almost 1 TB of images and videos in about 160k files on a slow disk (Seagate Archive 8TB with SMR) with NTFS. I am not sure if the Linux box has the slow disk or the Windows box has the slow disk. Even if there are no changes and whith whole file transfers rsync takes about 45 minutes to come to this conclusion. I am using the following command line on the linux server: rsync -avx --stats --whole-file --no-perms --no-owner --no-group @: As rsync was only transferring a small number of bytes and gave no clue to the cause for being so slow and as rsync should only need filenames, dates and sizes I did a "ls -lR|wc" on both systems. On the linux server this took about 1 minute (only slightly faster magnetic disk, empty read cache at start) and doing the same on cygwin took almost as long as rsync (over 40 minutes). Using Windows Explorer (after a reboot to guarantee that the cache is empty) to get the total number of files and the total size took only a few seconds. Reading all file sizes with Treesize also took less than one minute. As ls -lR needs the same information I would have expected it to take the same time. I would add a bunch of verbose to the rsync to see what it is doing. (I don't recommend sending that to the list as it will be a lot of data.. but maybe an excerpt) I am expecting it is spending a lot of time getting the metadata off of one of the disks and mapping it to Unix permissions then comparing if those items are the same on the other side. Each one of those is going to be a separate action which on a slow drive may be a spinup/get-data/spindown cycle to make it even slower. I would then check to see if perms and metadata on that directory 'look sane' (this is highly dependent on your environment.. if you have an AD server giving out perms it will look different from other things.) If the lookups for mapping metadata permissions is having to ping an AD server or some sort of other network lookup that is going to also slow down things. Sorry I don't have any 'fixes'. I have always found large rsync between Windows and Unix to be slow. Runnin "ls -lR" a second time on Cygwin is fast as lightning as it only takes less than 30s. Is there any way to get ls -lR or better rsync as fast as listing the directory with Windows tools? Frank -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- 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 -- Stephen J Smoogen. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git on mounted CIFS is it Git or Cygwin
On 2020/01/28 14:56, Jason Pyeron wrote:
Two short details,
ll is an alias commonly used on unix/linux/cygwin
most often standing for "ls -l" in its simplest form.
Mine does a few other things
alias llg='ls -l' #long listing
alias ll='llg -gG'# same with user+group turned off
lsacl is a shell script I use to get a more convenient and
compact form of acl's on linux; laster ported it to cygwin to do the same:
Here it is -- feel free to pass it along:
---
lsacl
---
cat ~/bin/lsacl
#!/bin/bash
## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp $
# Version 2 -- try to work with getfacl on cygwin
#
shopt -s expand_aliases
alias int=declare\ -i sub=function string=declare
gfacl=$(type -P getfacl)
#add cygwin function to return true/false
if ! type -f cygwin 2>/dev/null ; then
_un_=$(type -P uname)
if[[ $_un_ ]] ; then _os_=$($_un_ -o);
elif [[ -e /proc/sys/kernel ]]; then _os_=Linux;
else _os_=Cygwin;
fi
if[[ $_os_ =~ Cygwin ]]; then function cygwin () { return 0; }
else function cygwin () { return 1; }
fi
unset _un_ _os_
export -f cygwin
fi
if cygwin 2>/dev/null ;then
[[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n"; exit 1; }
sub gfacl () { "$gfacl" "$@"; }
else## linux version has broken semantics requiring "-p"
sub gfacl () { "$gfacl" -p "$@" ; }
fi
export -f gfacl
sub facl2str {
string fn=${1:?"Need pathname"}
string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//;
s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/'
string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",")
facl=${facl%,}
string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n" ",")
dacl=${dacl%,}
printf "[%s/%s]\n" "$facl" "$dacl"
}
int acllen=0 maxfnln=0
#for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done
sub acl_str () {
if cygwin ;then
perm=$(facl2str "$fn")
else
qfn=$(printf "%q " "$fn")
out="$(chacl -l "$fn")"
perm="${out#$qfn}"
fi
printf "%s\n" "$perm"
}
for fn in "$@"; do
int max=40
perm=$(acl_str "$fn")
int len=${#perm}
if ((len>_acl_len_)); then acllen=len; fi
if ((acllen>max));then acllen=max; fi
printf "%-${acllen}s %s\n" "$perm" "$fn"
done
--
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: git on mounted CIFS is it Git or Cygwin
On 2020/01/26 13:56, Jason Pyeron wrote: I have an issue with git in Cygwin on windows shares - this is recent (worked months ago). Just to be clear, you are running 'git' on Cygwin and not on linux or some other OS? There is a 'git' that runs on window natively. Have you thought about why you'd want to use the cygwin version of git vs. the windows version since you are running 'git' on the windows machine? I tend to like the cygwin version of things because often it will use the same sources and act the same way as a version on linux, so that's just a comfort and familiarity thing. Depending on your use case, you might want to run git natively using a Win version. Now another question, you say you are running git in Cygwin. Now you say you are running this on a "windows share". What that implies is that the files are being stored on another machine on the network (not locally) that might be a windows machine exporting part of its file system as a 'share', or it could be another OS (like linux) running something like "Samba" to export the disks with a Windows-type network interface (like CIFS). Is there a 3rd machine that is exporting its disks as windows-shares so they can be mounted by windows machines (or other OS's using the CIFS protocol) -- since that is what a 'share' is -- a view of part of a filesystem on that 3rd system. ==OR== is it a local (to the windows machine) disk or partition that most likely has the disk formatted with NTFS. CIFS is a network filesystem interface and has little or nothing to do with cygwin. It can be used between other OS's (linux<->linux for example) to share files or windows<->windows or between different OS's. A guess on my part -- CIFS isn't party of this -- and you are running git storing files on a local hard disk running NTFS and cygwin is emulating posix permissions (ex. 0644) on NTFS. My first guess was something in git had changed, but in writing this out, I think it more likely that it has something to do with 1) your umask settings being set overly restrictively. Created a testdir w/no acls on it. By default it had acls on my system: cd /tmp; mkdir testdir lsacl testdir [u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx/u::rwx,g::rwx,g:Untrusted:r-x,m::rwx,o::rwx] testdir # of note: my system created those acls by defaults setup on my system. # Simply creating a directory anywhere on my system will likely have some # ACL's applied by default # so for this test, I removed them: chacl -B testdir lsacl testdir [u::rwx,g::rwx,o::rwx] testdir # above acl corresponds to: ll -da testdir drwxrwxrwx 2 36 Jan 27 03:34 testdir/ (user, group and other all have full access) That was with a umask of 0. Then I created 3 files with my umask set to different settings: umask 0; touch u0 umask 02; touch u02 umask 0377; touch u377 #looking at permission settings: ll testdir total 0 -rw-rw-rw- 1 0 Jan 27 03:33 u0 -rw-rw-r-- 1 0 Jan 27 03:33 u02 -r 1 0 Jan 27 03:34 u377 # Note the last case, gave the user read-only access and nothing to group and other. So something that changed the umask could duplicate your symptoms. So a setting in 'git' might have changed to change the bits in the permissions or in the umask (aside from something changing your default umask value). Depending on where you create a directory it can affect the permissions -- like /tmp is usually set to allow users to create, modify and delete their own files, but not those of other users. Those permissions can change how the file permissions are enforced -- like under tmp, you'd retain write access despite what permissions were on the file, but under a git dir owned by another user, permissions denying write access would be more likely to be strictly enforced. I have narrowed it down to a component of git creating a file as 04xx instead of 06xx permissions. When I do the same with mktemp, I am able to write the file, but git gets a permission denied. I can chmod +w the temp file and then writing works, albeit too late. --- So what umask is there when the file is created, and what permissions does git try to create the file with? Possibly using 'strace' would allow you to see how or why the file is created with the wrong permissions. Also, if you really are working on a network disk -- how you mount and how the disk is exported can also set default permissions and umask effects. There can be ALOT of things that could be causing your problem, BUT, the simplest, and easiest to break w/o knowing it, would be something changing somethign like the umask or default permissions on the directory (i.e. the same symptom could be created by ACLs). Hope this gives you some ideas on what to check -- if lucky it's an easy find, if not, well, could take alot more investigation. good luck! Linda Renaming the file works in either case. What I need help in is determining if this is a bug or a special case of mounti
Re: non-persistant storage?
On 2019/12/12 22:26, Brian Inglis wrote: I've been using /run, with /var/run as a symlink to that, created in a permanent postinstall script /etc/postinstall/zp_mk_run_var_links.dash (with some others), for some time. It's currently using ~28KB. Is it feasible to mount /run on say /dev/shm/run and create and use files there? I don't see why you would need to change what you are doing unless your application whines about the symlink. I.e. VirtualBox didn't like me using a symlink in /opt to /home/opt on linux, so I mounted it w/a line in fstab. /home/opt /opt none rbind 0 0 Or would it be more feasible to use say Cyg/WinFUSE to provide that function? I don't know the state of cyg's support in those areas, so if you were forced to change, you'd get to do your own testing to see what worked, etc. I went one further under 'run' and 'tmp' -- I left those as public directories and put my UID or login name as my own directory under the common name. yeah 28k is nothing. I was using files measured in MBytes though the [server] system has over 100GB mem. The communication goes through unix-sockets, which also goes through /dev/shm, but its cleanup is technically the responsibility of the OS, so, if lucky -- it cleans it up, if not, no worse off than before. I don't run many OS progs on my Win machine cuz Win tended to flake out in running tasks and wouldn't say anything when it went wrong. So now, I just have a cronjobs on my linux server that use ssh to login to run jobs on windows... -- 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 "factor" (coreutils: GNU core utilities (8.26-2), 64bit edition)
On 2019/12/11 23:36, Bernd Eggen wrote: Hello, Some time ago I found that the Cygwin-64 "factor" command did not seem to terminate with certain numbers, eg try: -> echo '3401347*3861211*12099721' | bc | factor The developers provided a fix (in GNU coreutils 8.29), however, after some two years I still find the faulty factor command in the current Cygwin distribution. When are you planning to upgrade ? Cheers, Bernd PS I think this only affects 64bit version Wow... The source for factor should be easy to build .. like grab from gnu's website...(goog) tells me this link should work: https://ftp.gnu.org/gnu/coreutils/coreutils-8.31.tar.xz untar it and run configure in the dir where it was extracted, then run "make" in the same dir. You'll find factor in "src/factor". Or you could also get the cygwin source package (in setup checkmark the src package) and substitute in the new coreutils package, and adjust any needed paths in the cygwin make package, then you'd have an installable cygwin package rather than just a binary of factor... Just thinking out-loud, mostly, if I really needed it that is... But dunnow how complicated their packaging is... -linda -- 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: non-persistant storage?
On 2019/12/12 13:40, Eliot Moss wrote: Ah! I think what you want is a tmpfs or ramfs. Not sure if cygwin supports that ... Easiest thing might be to use /dev/shm. I used it during development to store intermediate data that was later to be transfered via a fifo... Basically check for existence of "/dev/shm" (exists on my cygwin). if "tmp" didn't already exist, create it w/options similar to /tmp (only owner can delete/edit): mkdir -m 1777 /tmp/shm/tmp **Warning, "writes" to /dev/shm/tmp (or /dev/mem) can fill up your system's memory, so its only good for "small files" (small being well under your system's free memory amount). -- 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: bashdb-3.1_0.09-1 is obsolete; pkg bashdb w/bash?
cygcheck -p bashdb Found 2 matches for bashdb bashdb-3.1_0.09-1-src - bashdb-src: Debugger for bash scripts (source) bashdb-3.1_0.09-1 - bashdb: debugger for bash scripts (installed binaries and support files) Current version of bash on Cygwin download site is bash-4.4.12-3 So for bashdb, a 4.4 version is needed: i.e. bashdb-4.4 Who is the maintainer for bash and bashdb? Maybe bashdb & bash should be packaged together so they can't get out of sync? tnx, Linda -- 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 in Cygwin program offering: Bashdb is for Bash 3.1.9; Bash is at 4.4.12 (or 5.x).
Bashdb doesn't work very well (many things don't work) on Cygwin, -- figured out that Bashdb is from 2012, while bash is from 2017. If bashdb was upgraded to a compatible version it might run a bit better. Table from page @ https://sourceforge.net/projects/bashdb/files/bashdb/5.0-1.1.1/ Selecting which version of bashdb to use The version of bashdb to use has to be compatible with the version of bash used. Run bash --version to see what version of bash you are using. If bash is 5.0 or higher, use folder 5.0-1.1.1 If bash is 4.4 or higher, use folder 4.4-1.0.1 If bash is 4.3 or higher, use folder 4.3-0.91 If bash is 4.2 or higher, use folder 4.2-0.8 If bash is 4.1 or higher but less than 4.2 use folder 4.1-0.5 If bash is 4.0 or higher but less than 4.1 use folder 4.0-0.4 If bash is 3.1 or higher and less than 4.0, use folder 3.1-0.09. If bash is 3.0 or higher but less than 3.1, use the folder 3.00-0.05. FYI, it appears to also work with ksh and zsh. Thanks! -linda -- 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: XWin can't hold OpenGL picture, has WS_DISABLED and WS_EX_TRANSPARENT styles?
On 2019/11/09 01:21, Mick Pearson wrote: > XWin has never had a permanent picture with OpenGL. ??? Not sure what thing you are talking about -- but some/many opengl progs seem to work with XWin across a local network (using programs on my linux box, and display via Cygwin X). Many of them operate at full speed, but depends on application: > glxspheres Polygons in scene: 62464 libGL error: failed to load driver: swrast *** Visual ID of window: 0x2c6 Context is Indirect OpenGL Renderer: GeForce GTX 1080/PCIe/SSE2 3220.365264 frames/sec - 3593.927634 Mpixels/sec 59.853303 frames/sec - 66.796286 Mpixels/sec 59.854641 frames/sec - 66.797779 Mpixels/sec 43.856578 frames/sec - 48.943941 Mpixels/sec 150.846871 frames/sec - 168.345108 Mpixels/sec 36.137460 frames/sec - 60.207032 Mpixels/sec --- different values were for different window sizes. *** - this failed to load driver is a bogus msg that comes out with any/all programs that use an indirect context... The screen's refresh is 60Hz. > Any movement "damages" all windows. --- I don't understand what you mean by this -- I can move the rendering window around and resize it and don't see any other windows needing a refresh (most are Xwin from my linux box). Anyway, thought I'd chime in. Of note -- glxgears sometimes works but is often frozen upon startup. -l -- 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: Configurable stack trace please
On 2019/11/07 13:00, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > When Cygwin generates a stacktrace (coredump) is it possible to get more than > 16 frames printed out? > Looking at exceptions.cc, seems like not. Can it please be increased to 32, > for example? > --- "For example". I'm guessing it's a first stab at an amount that might be right for the program you are debugging? Would it be possible to put that limit in an ENV var? Like if "not set", or the #frames > (what? 128? 256? 512?) "some limit that is way above what would be used or wanted", then use 16 frames, else use value in an ENV VAR like CYGWIN_DBG_UNWIND_STACKFRAMES=32. Looking through several progs just now, the max stack size I saw was about 32 frames, though in a program that was 'hung' (like Firefox et al) I've seen over 100 frames -- but how many are valid... But this was a longer trace for syslogd's main thread. 0, ntoskrnl.exe!RtlNumberOfSetBitsUlongPtr+0x1093 1, ntoskrnl.exe!KeReleaseSpinLock+0x81d 2, ntoskrnl.exe!KeWaitForMultipleObjects+0x272 3, ntoskrnl.exe!NtRequestWaitReplyPort+0x434 4, ntoskrnl.exe!FsRtlMdlWriteCompleteDev+0x1ec1 5, ntoskrnl.exe!longjmp+0x5b93 6, ntdll.dll!NtWaitForMultipleObjects+0xa 7, KernelBase.dll!GetCurrentProcess+0x40 8, kernel32.dll!WaitForMultipleObjects+0xb0 9, cygwin1.dll!acl_get_perm+0x4a8c 10, cygwin1.dll!acl_get_perm+0x51b4 11, cygwin1.dll!acl_get_perm+0x5668 12, cygwin1.dll!acl_get_perm+0x5ae7 13, cygwin1.dll!dirname+0x4acc 14, cygwin1.dll!acl_get_perm+0x99da 15, 0x60750 16, 0x2 17, 0x 18, 0x1 19, 0xc330 20, 0xc300 21, 0x44 22, 0x60750 23, 0x2 24, 0xc300 25, syslogd.exe+0x156e8 26, 0xc2e0 27, 0x4f3 28, 0xc7c0 29, 0x450230 30, 0x109 31, syslogd.exe+0x107f --- BTW, for frames 15-31, I'm guessing those are maybe from inside syslogd(?). The above is from the tool 'Process Hacker' (it's Hacker in the exploring/curiosity sense, not in the Cracking sense) with Win binaries and source downloadable from https://processhacker.sourceforge.io/. (V2.39) It's an enhanced replacement for sysinternals ProcessExplorer, which is an enhanced replacement for 'Windows Task Manager'. and uses the same debug info that they use (?pdb?) -- that can dynamically download symbol table mappings from MS and optionally cache them locally. Anyway, seems having a configurable limit might come in handy now and then? -- 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: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On 2019/08/28 07:22, Corinna Vinschen wrote: > One problem here is, what to do about border cases like > > $ mkdir a\/\/\/ > > In theory slashes and backslashes should both be treated as dir > separators. Handling a case like this so that all expectations > are satisfied is next to impossible, I guess. > In a shell or as a quoted literal? Under POSIX or under Windows? In a shell it ends up as: > pathcat a\/\/\/\/ b a/b > pathcat a\/\/ b a/b But as a quoted string, things don't get reduced unless last of first + first of second are same: > pathcat 'a\/\/' 'b' a\/\/b # cuddled > pathcat 'a\/\/' '/b' a\/\/b # slash reduced pathcat 'a\/\/' '\/b' a\/\/\/b# concat pathcat 'a\/\' '\/b' a\/\/\/b # slash added as "\/b is assumed to be at ./\/b Note that while posix may specify that mkdir 'a' and 'a/' should be the same, 'a:' and 'a:\' are not (and would not be POSIX compliant). -- 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
change in pattern matching in pager /usr/bin/less
For some reason, the behavior of less has changed recently in regards to how it interprets characters like '\s' (whitespace). Unlike previous versions which worked to use '\s' for whitespace and use '+' for '1 or more', there seems to be nothing for \s and to use '+' you would need *. This puts the cygwin 'less' at variance with the version I'm using on linux. part of this is that the new cygwin less appears to use Obsolete REs that don't support '+'. That may be a compile flag. I don't know why \s is not working, however, 'awk' used to be the definitive Extended (modern) RE reference and does use \s for whitespace. My linux less is at version 458 (POSIX RegEx) my cygwin less is at version 530 (POSIX RegEX) It could be the libraries they are linking into for RE's. Though both appear to use the Gnu regex stuff. Note, I'm not just saying cygwin less is different from linux less, but also that the cygwin less is different from how it used to be. Regularly when looking at a manpage, I use the search string: ^\s+topic\s to find header words or cmds, etc. I.e. it starts on a line by itself and has multiple whitespace characters before it and 1 after. I may need to repeat the search a few times, as the word searched for can also be 1st on a line. Like to find 'typeset', I'd use '^\s+typeset\s'. That no longer works in cygwin. Idea? Fix please? -- 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
Cygcheck.out sent to list causes email to get blocked (was Re: unset TMP Variable issue)
On 2019/07/20 16:30, Nikos Balkanas wrote: >> >> Attached is the zipped cygcheck output with user names crossed out >> Worry, but your attachment of the output never came through. Neither did mind. Looks like the mailing list software discards cygcheck.out output now, which seems to make the error reporting process a bit broken? -- 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
retry: Problem transfering X11 cut/copy buffer to windows and back
Original Message
Subject:Problem transfering X11 cut/copy buffer to windows and back
Date: Sun, 25 Aug 2019 11:51:18 -0700
Starting a few days ago, after an update to cygwin,
I'm finding it impossible to transfer
my xselection from cygwin X to any Win application or vice versa.
I've tried multpile Windows apps (Windows 7 SP1 x64)
and multiple X apps and no go.
I first noticed it in gvim -- which I run on my linux box
and display via 'X' locally.
The only thing I noticed w/X,u has been a checkmarked value about
Clipboard may use primary selection (which is checked, though I tried both
ways).
My cygwin start script is the same as it has been since
Mar23, 2018 and is below.
Having to write things out ot files is royal pain, so any ideas
would be very appreciated.
Thanks much!
Linda
Had my cygcheck.out attached, but if this gets through
perhaps such isn't allowed?
startxwin.sh---
#!/bin/bash
# (c) LA Walsh 2004-2014, licenced under GPLv2
#export DISPLAY=:0
#export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
#export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
#export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
#export XNLSPATH=/usr/X11R6/lib/X11/locale
#unexport XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH
# see cygwin Xwin for more option examples
# relevant ops:
# -multiwindow = use windows manage; not w/(-rootless|-fullscreen)
# -clipboard = use built-in version (integrated w/windows)
# -unixkill = Enable Ctrl-Alt-BS as X-server shutdown cmnd
# -nowinkill = Disable Alt+F4 as a server shutdown key combination.
# -trayicon = (default) windows tray icon enabled
#set -x
export LIBGL_USE_WGL=1
mount -c /
export PATH=/bin:$(/bin/cygpath "$USERPROFILE")/bin:$PATH #ensure our
bin is 1st
shopt -s expand_aliases extglob
alias my=declare int=my\ -i sub=function array=my\ -a
alias xset=$(type -P xset);
alias notify=$(type -P notifu)
my HKLM='HKEY_LOCAL_MACHINE' MsWinNT='SOFTWARE/Microsoft/Windows NT'
my DPI_Px='FontDPI/LogPixels' proc_reg='/proc/registry'
my pixels_key="$HKLM/$MsWinNT/CurrentVersion/$DPI_Px"
my pixels_path="$proc_reg/$pixels_key"
export DISPLAY="${DISPLAY:-":0"}"
sub xup {
local stat
read -t .1 stat <<<$(xset q >&/dev/null; echo $?) &&
return $stat
((-1))
}
Xwin_pids() {
( cd /proc && for exe in [0-9]*/exename; do
read ln<"$exe"
((${#ln})) && [[ $ln =~ Xwin ]] && printf "%d %s\n" "${i%/*}" "$ln"
done
)
}
Xwin_running() {
my nam; int pid
read pid nam< <(Xwin_pids)
return $((!pid))
}
kill_Xwin() {
array sigs=(TERM TERM KILL) # try 2 TERMs then KILL upto maxsigs
int pd; my pg
int maxsigs=3 lastsig=${#sigs[*]}
while ((maxsigs)) && read pd pg; do
((pd)) && kill -${sigs[--maxsigs>lastsig ? lastsig : maxsigs]} $pd
sleep 1
done < <(Xwin_pids)
}
tidy_old_Xwin() {
rm -fr /tmp/.X11-unix
}
function ord() { printf "%d" "'$1" ; }
sub get_dpi {
my dw=""; read -d '' dw< <(<"$pixels_path" cat)
int dpi=$(ord "$dw")
# check for insane values
((dpi<50||dpi>>400)) && dpi=107
printf ${1:+-v $1} "%d\n" $dpi
}
sub get_fontpath {
printf "%s"
"/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts"
}
sub start_XWin {
my fontpath=$(get_fontpath)
int dpi=$(get_dpi)
cmd="/bin/run /bin/XWin ${dpi:+-dpi $dpi} -listen tcp +iglx -wgl
-compositealpha -compositewm -lesspointer -clipboard -ac -unixkill
-nowinkill -multiwindow -wm -ardelay 150 -arinterval 30 +bs
-nomultimonitors -noreset -fp \"$fontpath\" "
echo cmd="$cmd"
$cmd
}
sub start_syslogd {
cygrunsrv -n -O -S syslogd
}
sub start_cygserver {
cygrunsrv -n -O -S -d messagebus cygserver
}
sub start_msgbus {
cygrunsrv -n -O -S -d syslogd messagebus
}
sub start_sess_dbus {
/bin/run /bin/dbus-launch --exit_with_session ~/.Xsession
}
sub _in {
local x=${1:?};shift
for ((;$#>0;)); do [[ $x == $1 ]] && return 0;shift; done
return 1
}
int tries=3
if Xwin_running && xup; then
notify /t info /m "Xserver already running and ready" /d 5000
else
#echo "No Xserver detected"
tidy_old_Xwin
while ((1)); do
start_cygserver
start_XWin
sleep 1
for ((i=0;i<5;++i)); do
xup && break 2
sleep 1
done
if ((--tries<=0)); then
m="^GEXITING: Timeout Waiting for Xserver Startup!!"
echo "$m"
notify /t error /m "$m"
exit 1;
fi
done
start_sess_dbus
#start_dbus || { m="^GError Starting Dbus"; echo "$m"; notify /t error
/m "$m"; }
fi
# vim: ts=2:sw=2
--
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
