Re: Why is taskset still not in util-linux?
Eliot Moss wrote: Dear cygwin-ers -- Something I had asked about a while ago was the absence os taskset in cygwin's util-linux. At the time, it was pointed out that the necessary get/set affinity library/system calls were not yet supported. These were added a while ago, so it would seem that taskset ought to work. In fact, I think someone got it going on their own. Can we add it to util-linux now, officially? I think this was intended but perhaps was overlooked or something. Report noted; thanks. A solution is being worked. ..mark -- 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/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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
On Tue, 3 Mar 2020 21:03:38 +0100
Hans-Bernhard Bröker wrote:
> OTOH the MS documentation calls this DWORD* an "optional output"
> argument. If I'm reading that right, it means it should be fine to just
> pass NULL to indicate that we don't need it:
>
> inline void sendOut (HANDLE )
> {
>WriteConsoleA (handle, buf, ixput, 0, 0);
> }
>
> The same would apply to all the other calls of WriteConsoleA, it seems.
Yeah, it could be. However, please note that it should be
saparate patch if you remove wn from WriteConsoleA() other
than wpbuf related.
--
Takashi Yano
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 3/3/2020 7:59 AM, Takashi Yano wrote: On Tue, 03 Mar 2020 12:40:17 + "Henry S. Thompson" wrote: Takashi Yano writes: This bug was already fixed in current git head. Current git head for Cygwin? Or mintty? I mean cygwin. Because I have another box, and now see that the bug does _not_ occur with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is with Cygwin 3.1.4 _and_ mintty 3.1.4. In my environment, your problem does not occur even with cygwin 3.1.4 and mintty 3.1.4. So I am not sure what is the real cause. Well, for me it *does* happen with cygwin 3.1.4 and mintty 3.1.4. I tried rolling back just mintty to 3.1.0 and it still happened. Then I rolled both of them back and it no longer happens, at least on one of my systems where I am *not* running sshd. Now to go try the other one roland -- 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?
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. *) it will do so on _all_ files in the cwd matching '*.ext', not just a single one --- that's its entire purpose. -- 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: Cygwin/X XWinrc menu no longer launches after recent updates
Brian Inglis writes: >> 2) There are some hints that cygrunsrv/cygserver might be implicated. >> Two cygchecks on one of my machines (which did run to completion) >> differ in that the one taken while XWin had started successfully >> differed from the other in that all my Cygwin services (cron, >> cygserver, sshd, and exim) were stopped, >> In the other, a case of XWin hang, they were all running. >> >> On my other system after several fails in a row, I stopped all my >> services and XWin launched successfully. >> >> Grasping at straws here, but I have one machine sitting in a hung state, >> and other debugging ideas welcome... > > XWin startup takes different paths depending on whether you have sshd > running or not. Ah, interesting. > I also have cygserver defined with max supported threads, as I have > cron jobs which need them. I can often get multiwindow X to launch > from mintty with sshd disabled, after deleting: > $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- > srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= > ... Just stopping sshd didn't do it, I did eventually have to kill all 4 of my services (cron, cygserver, exim, sshd). But, I only did one trial after stopping each one, starting with sshd, so this isn't definitive... ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 10:21, Henry S. Thompson wrote: > Takashi Yano writes: > >> On Tue, 03 Mar 2020 12:40:17 + >> "Henry S. Thompson" wrote: >>> Takashi Yano writes: This bug was already fixed in current git head. >>> >>> Current git head for Cygwin? Or mintty? >> >> I mean cygwin. > > OK, this is now getting very weird. As at least one other person > reported, the problem is intermittent, with both my systems, both on > 3.1.4 Cygwin and 3.1.4 mintty. > > Two further shots in the dark: > > 1) I tried to run cygcheck -s while there was an XWin + sh hang, as > previously reported. It hung also. Process Explorer shows > > bash.exe > bash.exe > cygcheck.exe >id.exe > > I can use strace to attach to it, and it is indeed > [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being > created and exiting happily, last two lines are > > thread nnn created > _cygtls::remove: wait 0 > > Mystery > > So, try connecting strace to the hung sh process... > > [Nothing :-[ > > Connecting to it with gdb shows various threads, but ^C doesn't > achieve anything. > > 2) There are some hints that cygrunsrv/cygserver might be implicated. > Two cygchecks on one of my machines (which did run to completion) > differ in that the one taken while XWin had started successfully > differed from the other in that all my Cygwin services (cron, > cygserver, sshd, and exim) were stopped, > In the other, a case of XWin hang, they were all running. > > On my other system after several fails in a row, I stopped all my > services and XWin launched successfully. > > Grasping at straws here, but I have one machine sitting in a hung state, > and other debugging ideas welcome... XWin startup takes different paths depending on whether you have sshd running or not. I also have cygserver defined with max supported threads, as I have cron jobs which need them. I can often get multiwindow X to launch from mintty with sshd disabled, after deleting: $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- -r--r--r-- 1 11 Mar 2 00:20 /tmp/.X0-lock srwxrwxrwx 1 0 Mar 2 14:27 /tmp/dbus-5P1mCxSjEA= srwxrwxrwx 1 0 Mar 2 00:20 /tmp/dbus-JEIRS3qks6= srwxrwxrwx 1 0 Mar 2 12:34 /tmp/dbus-K5HWAHFshg= srwxrwxrwx 1 0 Mar 3 10:34 /tmp/dbus-pvf4OTaHDu= srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= srwxrwxrwx 1 0 Mar 2 14:01 /tmp/dbus-TFjEzRHU4c= srwxrwxrwx 1 0 Mar 2 14:26 /tmp/dbus-VsXRfGI5GT= srwxrwxrwx 1 0 Mar 2 12:37 /tmp/dbus-Zo1S6Q5MSG= srw--- 1 0 Mar 2 00:20 /tmp/fam-$USER/fam-= /tmp/.X11-unix: total 1.0K srw-rw-rw- 1 0 Mar 2 00:20 X0= -rw--- 1 0 Mar 2 00:20 X0.lock -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On 2020-03-03 10:21, Henry S. Thompson wrote: > Takashi Yano writes: > >> On Tue, 03 Mar 2020 12:40:17 + >> "Henry S. Thompson" wrote: >>> Takashi Yano writes: This bug was already fixed in current git head. >>> >>> Current git head for Cygwin? Or mintty? >> >> I mean cygwin. > > OK, this is now getting very weird. As at least one other person > reported, the problem is intermittent, with both my systems, both on > 3.1.4 Cygwin and 3.1.4 mintty. > > Two further shots in the dark: > > 1) I tried to run cygcheck -s while there was an XWin + sh hang, as > previously reported. It hung also. Process Explorer shows > > bash.exe > bash.exe > cygcheck.exe >id.exe > > I can use strace to attach to it, and it is indeed > [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being > created and exiting happily, last two lines are > > thread nnn created > _cygtls::remove: wait 0 > > Mystery > > So, try connecting strace to the hung sh process... > > [Nothing :-[ > > Connecting to it with gdb shows various threads, but ^C doesn't > achieve anything. > > 2) There are some hints that cygrunsrv/cygserver might be implicated. > Two cygchecks on one of my machines (which did run to completion) > differ in that the one taken while XWin had started successfully > differed from the other in that all my Cygwin services (cron, > cygserver, sshd, and exim) were stopped, > In the other, a case of XWin hang, they were all running. > > On my other system after several fails in a row, I stopped all my > services and XWin launched successfully. > > Grasping at straws here, but I have one machine sitting in a hung state, > and other debugging ideas welcome... XWin startup takes different paths depending on whether you have sshd running or not. I also have cygserver defined with max supported threads, as I have cron jobs which need them. I can often get multiwindow X to launch from mintty with sshd disabled, after deleting: $ llgo -AR /tmp/.X* /tmp/dbus-* /tmp/fam-$USER/fam- -r--r--r-- 1 11 Mar 2 00:20 /tmp/.X0-lock srwxrwxrwx 1 0 Mar 2 14:27 /tmp/dbus-5P1mCxSjEA= srwxrwxrwx 1 0 Mar 2 00:20 /tmp/dbus-JEIRS3qks6= srwxrwxrwx 1 0 Mar 2 12:34 /tmp/dbus-K5HWAHFshg= srwxrwxrwx 1 0 Mar 3 10:34 /tmp/dbus-pvf4OTaHDu= srwxrwxrwx 1 0 Mar 2 08:47 /tmp/dbus-QdAWXiPC8F= srwxrwxrwx 1 0 Mar 2 14:01 /tmp/dbus-TFjEzRHU4c= srwxrwxrwx 1 0 Mar 2 14:26 /tmp/dbus-VsXRfGI5GT= srwxrwxrwx 1 0 Mar 2 12:37 /tmp/dbus-Zo1S6Q5MSG= srw--- 1 0 Mar 2 00:20 /tmp/fam-$USER/fam-= /tmp/.X11-unix: total 1.0K srw-rw-rw- 1 0 Mar 2 00:20 X0= -rw--- 1 0 Mar 2 00:20 X0.lock -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
Am 03.03.2020 um 01:35 schrieb Takashi Yano:
The second argument DWORD *wn of sendOut() is not used
outside sendOut(), so it can be covered up like:
inline void sendOut (HANDLE )
{
DWORD wn;
WriteConsoleA (handle, buf, ixput, , 0);
}
I doubt that will improve much, if anything. There are still direct
calls to WriteConsoleA() left, working on other buffers, and those still
use the DWORD wn defined near the top of
fhandler_console::char_command(). So that the existing varialbe would
have to be kept anyway. That means the variables local to each
invocation (!) of wpbuf.sendOut would just clutter the stack for no gain.
OTOH the MS documentation calls this DWORD* an "optional output"
argument. If I'm reading that right, it means it should be fine to just
pass NULL to indicate that we don't need it:
inline void sendOut (HANDLE )
{
WriteConsoleA (handle, buf, ixput, 0, 0);
}
The same would apply to all the other calls of WriteConsoleA, it seems.
Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory
On 3/2/20 3:53 PM, Marco Atzeri wrote: Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin: Details in attached file better in line next time. Are you sure that the disk J is mounted in a Administrator account ? Regards Marco USB drive Windows mounted on login. emacs shows the owner as whoever is looking at the drive. I don't know what the "s" in the directory permissions means. Played with changes to no effect. -- 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: Change in logical link behaviour
Am 03.03.2020 um 17:41 schrieb Corinna Vinschen: > On Mar 3 17:05, Rainer Emrich wrote: >> Am 03.03.2020 um 16:49 schrieb Corinna Vinschen: >>> On Mar 3 15:31, Corinna Vinschen wrote: On Mar 3 15:19, Rainer Emrich wrote: > Am 03.03.2020 um 14:39 schrieb Corinna Vinschen: >> Aha! So powershell does not show the 'l'. > The most important thing is the difference between cygwin 3.0.7 and > cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in > powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the > only difference is the cygwin version. I may believe you, but believe me that Cygwin has no influence on what powershell shows. See the output of cmd /c dir /a. The file is a native symlink. >>> >>> ...and for kicks I just tried this on W7 under Cygwin 3.0.7. The output >>> is the same as I pasted in >>> https://cygwin.com/ml/cygwin/2020-03/msg00043.html >>> >>> No 'l' mode flag, no 6th column in the mode output: >>> >>> ModeLastWriteTime Length Name >>> - -- >>> -a---03.03.2020 16:47 0 bar >>> >>> >> For me it's different. That's realy strange. >> >> Ok, so I can't rely on powershell here. Is there a recommended procedure >> for what I try in a script? >> >> Check if the current cygwin environment is able to create native symlinks. > > Unless I'm missing some new and shiny Windows onboard tool, that's > surprisingly tricky without creating your own executable checking just > that. Off the top of my head I don't see any other way than calling cmd > /c dir and some awk or sed hacking. Thank you, that's what I thought. Rainer signature.asc Description: OpenPGP digital signature
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > On Tue, 03 Mar 2020 12:40:17 + > "Henry S. Thompson" wrote: >> Takashi Yano writes: >> > This bug was already fixed in current git head. >> >> Current git head for Cygwin? Or mintty? > > I mean cygwin. OK, this is now getting very weird. As at least one other person reported, the problem is intermittent, with both my systems, both on 3.1.4 Cygwin and 3.1.4 mintty. Two further shots in the dark: 1) I tried to run cygcheck -s while there was an XWin + sh hang, as previously reported. It hung also. Process Explorer shows bash.exe bash.exe cygcheck.exe id.exe I can use strace to attach to it, and it is indeed [cygdir]\bin\id.exe, showing lots of dll loads, then a thread being created and exiting happily, last two lines are thread nnn created _cygtls::remove: wait 0 Mystery So, try connecting strace to the hung sh process... [Nothing :-[ Connecting to it with gdb shows various threads, but ^C doesn't achieve anything. 2) There are some hints that cygrunsrv/cygserver might be implicated. Two cygchecks on one of my machines (which did run to completion) differ in that the one taken while XWin had started successfully differed from the other in that all my Cygwin services (cron, cygserver, sshd, and exim) were stopped, In the other, a case of XWin hang, they were all running. On my other system after several fails in a row, I stopped all my services and XWin launched successfully. Grasping at straws here, but I have one machine sitting in a hung state, and other debugging ideas welcome... ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- 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: cat /proc/partitions shows only devices, not partitions
On Mar 3 16:32, Hashim Aziz wrote: > Yes, this was what I expected you meant by elevated shell. I tried that > earlier and got no luck (though I tried the link to the Cygwin terminal in my > start menu > not a desktop shortcut), and I just tried again after attempting several > permissions fixes but still no luck. > > The permissions fixed I tried were: > > - Right-clicking and deselecting Read-Only on the cygwin64 folder > - Resetting permissions with the CMD command: icacls c:\cygwin64 /reset /t /l > /c > - Taking control of the Cygwin folder with the following command (itself run > from an elevated window): > [...] When I was talking about permissions, I was talking about permissions on the native Windows devices, not any permissions on Cygwin files. The strace output shows that you don't have permissions to call DeviceIoControl(IOCTL_DISK_GET_PARTITION_INFO) or DeviceIoControl(IOCTL_DISK_GET_PARTITION_INFO_EX) on the devices representing the partitions in the native NT device namespace, i.e., \Device\Harddisk0\Partition0, etc. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Change in logical link behaviour
On Mar 3 17:05, Rainer Emrich wrote: > Am 03.03.2020 um 16:49 schrieb Corinna Vinschen: > > On Mar 3 15:31, Corinna Vinschen wrote: > >> On Mar 3 15:19, Rainer Emrich wrote: > >>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen: > Aha! So powershell does not show the 'l'. > >>> The most important thing is the difference between cygwin 3.0.7 and > >>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in > >>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the > >>> only difference is the cygwin version. > >> > >> I may believe you, but believe me that Cygwin has no influence on > >> what powershell shows. See the output of cmd /c dir /a. The file > >> is a native symlink. > > > > ...and for kicks I just tried this on W7 under Cygwin 3.0.7. The output > > is the same as I pasted in > > https://cygwin.com/ml/cygwin/2020-03/msg00043.html > > > > No 'l' mode flag, no 6th column in the mode output: > > > > ModeLastWriteTime Length Name > > - -- > > -a---03.03.2020 16:47 0 bar > > > > > For me it's different. That's realy strange. > > Ok, so I can't rely on powershell here. Is there a recommended procedure > for what I try in a script? > > Check if the current cygwin environment is able to create native symlinks. Unless I'm missing some new and shiny Windows onboard tool, that's surprisingly tricky without creating your own executable checking just that. Off the top of my head I don't see any other way than calling cmd /c dir and some awk or sed hacking. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: cat /proc/partitions shows only devices, not partitions
Yes, this was what I expected you meant by elevated shell. I tried that earlier and got no luck (though I tried the link to the Cygwin terminal in my start menu not a desktop shortcut), and I just tried again after attempting several permissions fixes but still no luck. The permissions fixed I tried were: - Right-clicking and deselecting Read-Only on the cygwin64 folder - Resetting permissions with the CMD command: icacls c:\cygwin64 /reset /t /l /c - Taking control of the Cygwin folder with the following command (itself run from an elevated window): $ chown $USER /* -v ownership of '/bin' retained as Hashim chown: changing ownership of '/cygdrive': Permission denied failed to change ownership of '/cygdrive' from Hashim to Hashim chown: changing ownership of '/Cygwin.bat': Permission denied failed to change ownership of '/Cygwin.bat' from Hashim to Hashim chown: changing ownership of '/Cygwin.ico': Permission denied failed to change ownership of '/Cygwin.ico' from Hashim to Hashim chown: changing ownership of '/Cygwin-Terminal.ico': Permission denied failed to change ownership of '/Cygwin-Terminal.ico' from Hashim to Hashim ownership of '/dev' retained as Hashim ownership of '/etc' retained as Hashim ownership of '/home' retained as Hashim ownership of '/lib' retained as Hashim ownership of '/opt' retained as Hashim chown: changing ownership of '/proc': Operation not permitted failed to change ownership of '/proc' from Hashim to Hashim ownership of '/sbin' retained as Hashim ownership of '/srv' retained as Hashim ownership of '/tmp' retained as Hashim ownership of '/usr' retained as Hashim ownership of '/var' retained as Hashim Whether the above output is normal or not I'm unsure. From: Corinna Vinschen Sent: Tuesday, March 03, 2020 10:44 AM To: Hashim Aziz Cc: cygwin@cygwin.com Subject: Re: cat /proc/partitions shows only devices, not partitions On Mar 3 00:54, Hashim Aziz wrote: > Hey Corinna, thanks for your quick reply. > > Regarding the elevated shell - I'm unsure of exactly how to run an > elevated Cygwin shell? Right click on the Cygwin Terminal icon on the desktop, choose the item "Run as administrator". I have no idea why your system has different permissions, but at least you should be able to see the info in an elevated shell. Corinna -- Corinna Vinschen Cygwin Maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Change in logical link behaviour
Am 03.03.2020 um 16:49 schrieb Corinna Vinschen: > On Mar 3 15:31, Corinna Vinschen wrote: >> On Mar 3 15:19, Rainer Emrich wrote: >>> Am 03.03.2020 um 14:39 schrieb Corinna Vinschen: Aha! So powershell does not show the 'l'. >>> The most important thing is the difference between cygwin 3.0.7 and >>> cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in >>> powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the >>> only difference is the cygwin version. >> >> I may believe you, but believe me that Cygwin has no influence on >> what powershell shows. See the output of cmd /c dir /a. The file >> is a native symlink. > > ...and for kicks I just tried this on W7 under Cygwin 3.0.7. The output > is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html > > No 'l' mode flag, no 6th column in the mode output: > > ModeLastWriteTime Length Name > - -- > -a---03.03.2020 16:47 0 bar > > For me it's different. That's realy strange. Ok, so I can't rely on powershell here. Is there a recommended procedure for what I try in a script? Check if the current cygwin environment is able to create native symlinks. Thanks Rainer signature.asc Description: OpenPGP digital signature
Re: Change in logical link behaviour
On Mar 3 15:31, Corinna Vinschen wrote: > On Mar 3 15:19, Rainer Emrich wrote: > > Am 03.03.2020 um 14:39 schrieb Corinna Vinschen: > > > Aha! So powershell does not show the 'l'. > > The most important thing is the difference between cygwin 3.0.7 and > > cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in > > powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the > > only difference is the cygwin version. > > I may believe you, but believe me that Cygwin has no influence on > what powershell shows. See the output of cmd /c dir /a. The file > is a native symlink. ...and for kicks I just tried this on W7 under Cygwin 3.0.7. The output is the same as I pasted in https://cygwin.com/ml/cygwin/2020-03/msg00043.html No 'l' mode flag, no 6th column in the mode output: ModeLastWriteTime Length Name - -- -a---03.03.2020 16:47 0 bar Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Change in logical link behaviour
On Mar 3 15:19, Rainer Emrich wrote: > Am 03.03.2020 um 14:39 schrieb Corinna Vinschen: > > Aha! So powershell does not show the 'l'. > The most important thing is the difference between cygwin 3.0.7 and > cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in > powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the > only difference is the cygwin version. I may believe you, but believe me that Cygwin has no influence on what powershell shows. See the output of cmd /c dir /a. The file is a native symlink. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory
On Mon, Mar 2, 2020 at 11:08 PM Robert McBroom wrote: Details in attached file Hint: When asking for help in a mailing list, the less effort respondents have to go through, the better. It is better to put your information directly in the message rather than attaching a file. (Why attach a file at all? Just put your text directly in the message.) Bill -- 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: Change in logical link behaviour
Am 03.03.2020 um 14:39 schrieb Corinna Vinschen:
> On Mar 3 14:17, Rainer Emrich wrote:
>> Dear Corinna,
>>
>> Am 02.03.2020 um 17:48 schrieb Corinna Vinschen:
>>> On Feb 29 14:10, Rainer Emrich wrote:
I try to reliably determine if native Windows symlink are working for a
current cygwin environment in a shell script.
[...]
On cygwin 3.1.4 I get:
Directory: D:\cygwin\home\rainer\temp
ModeLastWriteTime Length Name
- --
d29.02.2020 13:58asdfgh-1
So now there is no indication that this is a link. Is this new behaviour
intended or a bug?
I did not try on Windows 10, I'm still on windows 7.
>>>
>>> I can't reproduce this behaviour. Keep in mind that, [bla]
>> I know all the implications. I have to test in an unknown cygwin
>> environment if it is possible to set native symlinks.
>>>
>>> So, on Windows 7 in an elevated shell:
>>>
>>> # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
>>> elevated
>>> # uname -a
>>> CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
>>> # mkdir qwe
>>> # cd qwe
>>> # export CYGWIN="winsymlinks:nativestrict"
>>> # touch foo
>>> # ln -s foo bar
>>> # cmd /c dir /a
>>>Volume in drive C has no label.
>>>Volume Serial Number is A8E0-A24E
>>>
>>>Directory of C:\cygwin64\home\corinna\qwe
>>>
>>> 2020-03-02 17:31 .
>>> 2020-03-02 17:31 ..
>>> 2020-03-02 17:31 bar [foo]
>>> 2020-03-02 17:31 0 foo
>>> 2 File(s) 0 bytes
>>> 2 Dir(s) 7.907.352.576 bytes free
>>>
>> Yes, this is the same for me, but if you use the powershell
>>
>> # powershell "& {Get-Item -Path bar | Select-Object}"
>>
>> on cygwin 3.0.7 you get
>>
>> Directory: D:\cygwin\home\rainer\temp
>>
>> ModeLastWriteTime Length Name
>> - --
>> -a---l 03.03.2020 14:09 0 bar
>>
>> and on cygwin 3.1.4 you get
>>
>> Directory: D:\cygwin\home\rainer\temp
>>
>> ModeLastWriteTime Length Name
>> - --
>> -a---03.03.2020 14:09 0 bar
>>
>>
>> The only difference is the used cygwin version. So, I don't understand
>> what has changed.
>
> Nothing has changed in terms of symlink handling. Are you saying that
> `cmd /c dir /a' shows
>
> 2020-03-03 14:21 bar [foo]
>
> but powershell shows
>
> -a---03.03.2020 14:21 0 bar
>
> for the same file? That would be most puzzeling but certainly outside
> of Cygwin's control.
>
> So I created a symlink again on W7 with Cygwin 3.1.4 and `export
> CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
> (which I usually don't touch) and I see
>
> # uname -a
> CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> # setenv CYGWIN winsymlinks:nativestrict
> # ln -s foo bar
> # cmd /c dir /a bar
>Volume in drive C has no label.
>Volume Serial Number is A8E0-A24E
>
>Directory of C:\cygwin64\home\corinna\qwe
>
> 03.03.2020 14:30 bar [foo]
>1 File(s) 0 bytes
>0 Dir(s) 7.929.241.600 bytes free
> # powershell "& {Get-Item -Path bar | Select-Object}"
>
>
> Directory: C:\cygwin64\home\corinna\qwe
>
>
> ModeLastWriteTime Length Name
> - --
> -a---03.03.2020 14:30 0 bar
>
> Aha! So powershell does not show the 'l'.
The most important thing is the difference between cygwin 3.0.7 and
cygwin 3.1.4. For cygwin 3.0.7 the link indicator is shown even in
powershell on Windows 7 but not with cygwin-3.1.4. And believe me, the
only difference is the cygwin version.
Rainer
signature.asc
Description: OpenPGP digital signature
Re: Change in logical link behaviour
On Mar 3 14:17, Rainer Emrich wrote:
> Dear Corinna,
>
> Am 02.03.2020 um 17:48 schrieb Corinna Vinschen:
> > On Feb 29 14:10, Rainer Emrich wrote:
> >> I try to reliably determine if native Windows symlink are working for a
> >> current cygwin environment in a shell script.
> >> [...]
> >> On cygwin 3.1.4 I get:
> >>
> >>
> >> Directory: D:\cygwin\home\rainer\temp
> >>
> >>
> >> ModeLastWriteTime Length Name
> >> - --
> >> d29.02.2020 13:58asdfgh-1
> >>
> >> So now there is no indication that this is a link. Is this new behaviour
> >> intended or a bug?
> >>
> >> I did not try on Windows 10, I'm still on windows 7.
> >
> > I can't reproduce this behaviour. Keep in mind that, [bla]
> I know all the implications. I have to test in an unknown cygwin
> environment if it is possible to set native symlinks.
> >
> > So, on Windows 7 in an elevated shell:
> >
> > # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
> > elevated
> > # uname -a
> > CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> > # mkdir qwe
> > # cd qwe
> > # export CYGWIN="winsymlinks:nativestrict"
> > # touch foo
> > # ln -s foo bar
> > # cmd /c dir /a
> >Volume in drive C has no label.
> >Volume Serial Number is A8E0-A24E
> >
> >Directory of C:\cygwin64\home\corinna\qwe
> >
> > 2020-03-02 17:31 .
> > 2020-03-02 17:31 ..
> > 2020-03-02 17:31 bar [foo]
> > 2020-03-02 17:31 0 foo
> > 2 File(s) 0 bytes
> > 2 Dir(s) 7.907.352.576 bytes free
> >
> Yes, this is the same for me, but if you use the powershell
>
> # powershell "& {Get-Item -Path bar | Select-Object}"
>
> on cygwin 3.0.7 you get
>
> Directory: D:\cygwin\home\rainer\temp
>
> ModeLastWriteTime Length Name
> - --
> -a---l 03.03.2020 14:09 0 bar
>
> and on cygwin 3.1.4 you get
>
> Directory: D:\cygwin\home\rainer\temp
>
> ModeLastWriteTime Length Name
> - --
> -a---03.03.2020 14:09 0 bar
>
>
> The only difference is the used cygwin version. So, I don't understand
> what has changed.
Nothing has changed in terms of symlink handling. Are you saying that
`cmd /c dir /a' shows
2020-03-03 14:21 bar [foo]
but powershell shows
-a---03.03.2020 14:21 0 bar
for the same file? That would be most puzzeling but certainly outside
of Cygwin's control.
So I created a symlink again on W7 with Cygwin 3.1.4 and `export
CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
(which I usually don't touch) and I see
# uname -a
CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
# setenv CYGWIN winsymlinks:nativestrict
# ln -s foo bar
# cmd /c dir /a bar
Volume in drive C has no label.
Volume Serial Number is A8E0-A24E
Directory of C:\cygwin64\home\corinna\qwe
03.03.2020 14:30 bar [foo]
1 File(s) 0 bytes
0 Dir(s) 7.929.241.600 bytes free
# powershell "& {Get-Item -Path bar | Select-Object}"
Directory: C:\cygwin64\home\corinna\qwe
ModeLastWriteTime Length Name
- --
-a---03.03.2020 14:30 0 bar
Aha! So powershell does not show the 'l'.
Let's try the same on Windows 10:
# uname.ORIG -a
CYGWIN_NT-10.0 vmbert10 3.1.5(0.340/5/3) 2020-03-02 18:46 x86_64 Cygwin
# setenv CYGWIN winsymlinks:nativestrict
# ln -s foo bar
# cmd /c dir /a bar
Volume in drive C has no label.
Volume Serial Number is C65C-2A36
Directory of C:\cygwin64\home\corinna\tmp
2020-03-03 14:33 bar [foo]
1 File(s) 0 bytes
0 Dir(s) 23,112,925,184 bytes free
# powershell "& {Get-Item -Path bar | Select-Object}"
Directory: C:\cygwin64\home\corinna\tmp
ModeLastWriteTime Length Name
- --
-a---l 2020-03-03 14:33 0 bar
Aha! powershell shows the 'l'. Also, notice how the number of
mode bits seem to be only 5 on Windows 7:
-a---
^
12345
but *6* on Windows 10:
-a---l
^^
123456
On Windows 10 it shows 6 mode bits for non-symlinks as well, so the 'l'
mode is not just missing on Windows 7 in this specific case, but a
generic difference. From my POV, this is just a shortcoming of W7
powershell. Keep in mind that the output of powershell has nothing to
do with Cygwin itself.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: Change in logical link behaviour
Dear Corinna,
Am 02.03.2020 um 17:48 schrieb Corinna Vinschen:
> On Feb 29 14:10, Rainer Emrich wrote:
>> I try to reliably determine if native Windows symlink are working for a
>> current cygwin environment in a shell script.
>>
>> Therefor I used a powershell snipped:
>>
>> mkdir asdfgh
>> ln -s asdfgh/ asdfgh-1
>> powershell "& {Get-Item -Path asdfgh-1 | Select-Object}"
>>
>> On cygwin 3.0.7 the output is as follows:
>>
>>
>> Directory: D:\cygwin\home\rainer\temp
>>
>>
>> ModeLastWriteTime Length Name
>> - --
>> dl 29.02.2020 13:58asdfgh-1
>>
>> On cygwin 3.1.4 I get:
>>
>>
>> Directory: D:\cygwin\home\rainer\temp
>>
>>
>> ModeLastWriteTime Length Name
>> - --
>> d29.02.2020 13:58asdfgh-1
>>
>> So now there is no indication that this is a link. Is this new behaviour
>> intended or a bug?
>>
>> I did not try on Windows 10, I'm still on windows 7.
>>
>> Rainer
>>
>
> I can't reproduce this behaviour. Keep in mind that, by default, you
> *have to* run in an elevated shell to be able to create native NTFS
> symlinks, *and* you *have to* set the environment variable CYGWIN(*) to
> contain "winsymlinks:native" or "winsymlinks:nativestrict". The latter
> is nice for testing, it refuses to fall back silently to the default
> Cygwin-only symlinks but fails instead if it can't create a native
> NTFS symlink.
I know all the implications. I have to test in an unknown cygwin
environment if it is possible to set native symlinks.
>
> So, on Windows 7 in an elevated shell:
>
> # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
> elevated
> # uname -a
> CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> # mkdir qwe
> # cd qwe
> # export CYGWIN="winsymlinks:nativestrict"
> # touch foo
> # ln -s foo bar
> # cmd /c dir /a
>Volume in drive C has no label.
>Volume Serial Number is A8E0-A24E
>
>Directory of C:\cygwin64\home\corinna\qwe
>
> 2020-03-02 17:31 .
> 2020-03-02 17:31 ..
> 2020-03-02 17:31 bar [foo]
> 2020-03-02 17:31 0 foo
> 2 File(s) 0 bytes
>2 Dir(s) 7.907.352.576 bytes free
>
Yes, this is the same for me, but if you use the powershell
# powershell "& {Get-Item -Path bar | Select-Object}"
on cygwin 3.0.7 you get
Directory: D:\cygwin\home\rainer\temp
ModeLastWriteTime Length Name
- --
-a---l 03.03.2020 14:09 0 bar
and on cygwin 3.1.4 you get
Directory: D:\cygwin\home\rainer\temp
ModeLastWriteTime Length Name
- --
-a---03.03.2020 14:09 0 bar
The only difference is the used cygwin version. So, I don't understand
what has changed.
Cheers
Rainer
signature.asc
Description: OpenPGP digital signature
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 03 Mar 2020 12:40:17 + "Henry S. Thompson" wrote: > Takashi Yano writes: > > This bug was already fixed in current git head. > > Current git head for Cygwin? Or mintty? I mean cygwin. > Because I have another box, and now see that the bug does _not_ occur > with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is > with Cygwin 3.1.4 _and_ mintty 3.1.4. In my environment, your problem does not occur even with cygwin 3.1.4 and mintty 3.1.4. So I am not sure what is the real cause. -- Takashi Yano -- 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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
On Tue, 3 Mar 2020 12:14:00 +0100
Corinna Vinschen wrote:
> Btw., looking through the code with this change I wonder about ixput not
> being set to 0 in sendOut, right after calling WriteConsoleA. That
> would drop the need to call empty after calls to sendOut and thus clean
> up the code, no?
This sounds reasonable. However, for the current console code,
most of wpixput = 0 can not be omitted by this.
For example,
else if (*src == '7') /* DECSC Save cursor position */
{
if (con.screen_alternated)
{
/* For xterm mode only */
DWORD n;
/* Just send the sequence */
wpbuf_put (*src);
WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
}
else
cursor_get (, );
con.state = normal;
wpixput = 0; // <--- This can not be omitted.
}
This can drop only two wpixput = 0.
/* Substitute "CSI Ps T" */
wpbuf_put ('[');
wpbuf_put ('T');
}
else
wpbuf_put (*src);
WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
con.state = normal;
wpixput = 0; // <--- Here
[...]
/* ESC sequences below (e.g. OSC, etc) are left to xterm
emulation in xterm compatible mode, therefore, are not
handled and just sent them. */
wpbuf_put (*src);
/* Just send the sequence */
DWORD n;
WriteConsoleA (get_output_handle (), wpbuf, wpixput, , 0);
con.state = normal;
wpixput = 0; // <--- Here
So, this might not be worth much...
--
Takashi Yano
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > On Tue, 03 Mar 2020 12:18:44 + > "Henry S. Thompson" wrote: >> Takashi Yano writes: >> >> > Does reverting cygwin1.dll to 3.1.2 help? >> >> In my case, yes it does. The resulting view from pstree is >> >> `-sh,1614 /usr/bin/startxwin >> `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... >> |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 >> `-sh,1652 /home/ht/.Xclients >> |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients >> `-xterm,1665 -geometry +0+60 -ls >> `-bash,1666 >> `-sh,1684 /home/ht/bin/goE -Y >> `-ssh,1685 ecclerig.inf.ed.ac.uk -Y >> >> Compare this to the 3.1.4 result: >> >> `-sh,2027 /usr/bin/startxwin >> `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow >> -auth ... >> |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 >> `-sh,2065 > > Then, this may be caused by the same bug as > https://www.cygwin.com/ml/cygwin/2020-02/msg00197.html > > This bug was already fixed in current git head. Current git head for Cygwin? Or mintty? Because I have another box, and now see that the bug does _not_ occur with Cygwin 3.1.4 and mintty 3.1.0 -- the above error labelled 3.1.4 is with Cygwin 3.1.4 _and_ mintty 3.1.4. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 03 Mar 2020 12:18:44 + "Henry S. Thompson" wrote: > Takashi Yano writes: > > > Does reverting cygwin1.dll to 3.1.2 help? > > In my case, yes it does. The resulting view from pstree is > > `-sh,1614 /usr/bin/startxwin > `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... > |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 > `-sh,1652 /home/ht/.Xclients > |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients > `-xterm,1665 -geometry +0+60 -ls > `-bash,1666 > `-sh,1684 /home/ht/bin/goE -Y > `-ssh,1685 ecclerig.inf.ed.ac.uk -Y > > Compare this to the 3.1.4 result: > > `-sh,2027 /usr/bin/startxwin > `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth > ... > |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 > `-sh,2065 Then, this may be caused by the same bug as https://www.cygwin.com/ml/cygwin/2020-02/msg00197.html This bug was already fixed in current git head. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X XWinrc menu no longer launches after recent updates
Takashi Yano writes: > Does reverting cygwin1.dll to 3.1.2 help? In my case, yes it does. The resulting view from pstree is `-sh,1614 /usr/bin/startxwin `-xinit,1645 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow ... |-XWin,1646 :0 -multiwindow -auth /home/ht/.serverauth.1614 `-sh,1652 /home/ht/.Xclients |-ssh-agent,1664 /bin/env TMPDIR=/tmp /home/ht/.Xclients `-xterm,1665 -geometry +0+60 -ls `-bash,1666 `-sh,1684 /home/ht/bin/goE -Y `-ssh,1685 ecclerig.inf.ed.ac.uk -Y Compare this to the 3.1.4 result: `-sh,2027 /usr/bin/startxwin `-xinit,2058 /home/ht/.startxwinrc -- /usr/bin/XWin :0 -multiwindow -auth ... |-XWin,2059 :0 -multiwindow -auth /home/ht/.serverauth.2027 `-sh,2065 ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- 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: [PATCH 1/1] Collect handling of wpixput and wpbuf into a helper class.
Hi Hans-Bernhard,
On Mar 3 00:07, Hans-Bernhard Bröker wrote:
> Replace direct access to a pair of co-dependent variables
> by calls to methods of a class that encapsulates their relation.
>
> Also replace C #define by C++ class constant.
> ---
> winsup/cygwin/fhandler_console.cc | 135 --
> 1 file changed, 70 insertions(+), 65 deletions(-)
>
> diff --git a/winsup/cygwin/fhandler_console.cc
> b/winsup/cygwin/fhandler_console.cc
> index c5f269168..af2fb11a4 100644
> --- a/winsup/cygwin/fhandler_console.cc
> +++ b/winsup/cygwin/fhandler_console.cc
> @@ -59,17 +59,22 @@ static struct fhandler_base::rabuf_t con_ra;
> /* Write pending buffer for ESC sequence handling
> in xterm compatible mode */
> -#define WPBUF_LEN 256
> -static unsigned char wpbuf[WPBUF_LEN];
> -static int wpixput;
> static unsigned char last_char;
> -static inline void
> -wpbuf_put (unsigned char x)
This patch won't apply since commit ecf27dd2e0ed. Can you please
recreate the patch on top of current master?
Also, a few style issues:
> +// simple helper class to accumulate output in a buffer
> +// and send that to the console on request:
The /* */ style of comments is preferred. Please use it always
for multiline comments.
> +static class WritePendingBuf
No camelback, please. Make that `static class write_pending_buf'.
> {
> - if (wpixput < WPBUF_LEN)
> -wpbuf[wpixput++] = x;
> -}
> +private:
> + static const size_t WPBUF_LEN = 256u;
> + unsigned char buf[WPBUF_LEN];
> + size_t ixput;
> +
> +public:
> + inline void put(unsigned char x) { if (ixput < WPBUF_LEN) { buf[ixput++]
> = x; } };
Please put a space before an opening parenthesis, i.e.
inline void put (...)
The semicolon after the closing brace is obsolete.
Line length > 80 chars. Also, it's an expression which is multiline
by default. Make that
inline void put (unsigned char x)
{
if (ixput < WPBUF_LEN)
buf[ixput++] = x;
}
> + inline void empty() { ixput = 0u; };
> + inline void sendOut(HANDLE , DWORD *wn) { WriteConsoleA (handle,
> buf, ixput, wn, 0); };
Camelback, missing space, line too long, obsolete semicolon:
inline void send_out (HANDLE , DWORD *wn)
{ WriteConsoleA (handle, buf, ixput, wn, 0); }
"send" or "write" or "flush" would be ok as name, too, no underscore :)
Btw., looking through the code with this change I wonder about ixput not
being set to 0 in sendOut, right after calling WriteConsoleA. That
would drop the need to call empty after calls to sendOut and thus clean
up the code, no?
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: cat /proc/partitions shows only devices, not partitions
On Mar 3 00:54, Hashim Aziz wrote:
> Hey Corinna, thanks for your quick reply.
>
> Regarding the elevated shell - I'm unsure of exactly how to run an
> elevated Cygwin shell?
Right click on the Cygwin Terminal icon on the desktop, choose the
item "Run as administrator".
> I have attached the requested strace file.
Here's what I see for all partitions in the trace output:
460 21259 [main] cat 553 format_proc_partitions: DeviceIoControl
(Harddisk0\Partition0, IOCTL_DISK_GET_PARTITION_INFO{_EX}) Win32 error 5
Win32 error 5 is ERROR_ACCESS_DENIED.
So it appears that the OS access is denied for some reason. I tried
again on Windows 7, this time with a non-admin account, just to be sure,
but I still can see the partition info. Yesterday I tried with an admin
account, just not in an elevated shell, so this may have been an
important difference. Apparently not so.
I have no idea why your system has different permissions, but at least
you should be able to see the info in an elevated shell.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: Cygwin/X XWinrc menu no longer launches after recent updates
On Tue, 3 Mar 2020 00:14:12 -0500 Roland Roberts wrote: > I only noticed this in the last week or so, and assumed I'd messed up > something with Windows 10 permission, which is still a possibility. My > first attempt to "fix" this was to reinstall pretty much everything in > Cygwin that was part of X11 or Base. And that seemed to fix > things...until I rebooted Windows. > > There are no errors in the logs, not stackdumps, nothign to indicate > anything is not working. The X log is below. You'll notice it says > > "executing '/bin/mintty', pid 3152" > > but that window never opens. If I start a shell directly via my desktop > shortcut, which has this as it's target > > C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico - > > I can see that there is no PID 3152. Does reverting cygwin1.dll to 3.1.2 help? -- Takashi Yano -- 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: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory
On 2020-03-02 23:08, Robert McBroom via cygwin wrote: > Details in attached file You most likely have Windows permissions problems, if all your tools are Cygwin. Run which on each tool to see what you are actually running, and run cygcheck to ensure they use cygwin1.dll. You need to run against all components of the path to any failing directory: $ ls -dl DIR $ getfacl DIR $ icacls "$(cygpath -m ""DIR"")" [Windows command] and see what the permissions problem is: pay particular attention to the owner and group, and the R[ead], X//list/search, and I[nherited] access permissions. You do not say what your user id is and group memberships are (run id to find out) but the failing directories have groups None or SYSTEM so if your user id does not match, you may have limited access, and inherited access for other than owner and admins excludes write, unless you have additional custom Windows ACLs. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
util-linux update?
Hi Yaakov,
May I update the version of util-linux available on Cygwin? Your cygport
file for the current 2.33.1 seems to work fine for the latest 2.35.1.
I would add a patch file 2.33.1-cygwin-cpuset.patch (see attached) and
update the cygport file to reference this additional patch and remove the
"--disable-schedutils" from CYGCONF_ARGS. With these changes a working
'taskset.exe' will be an additional build output.
I would package the latest util-linux 2.35.1 unless you'd prefer some
intermediate version.
Thank you,
..mark
--- origsrc/util-linux-2.33.1/lib/cpuset.c 2018-06-04 00:57:02.792445800
-0700
+++ src/util-linux-2.33.1/lib/cpuset.c 2020-01-11 00:37:39.126054200 -0800
@@ -60,7 +60,7 @@ static const char *nexttoken(const char
*/
int get_max_number_of_cpus(void)
{
-#ifdef SYS_sched_getaffinity
+#if defined(SYS_sched_getaffinity) || defined(__CYGWIN__)
int n, cpus = 2048;
size_t setsize;
cpu_set_t *set = cpuset_alloc(cpus, , NULL);
@@ -72,7 +72,11 @@ int get_max_number_of_cpus(void)
CPU_ZERO_S(setsize, set);
/* the library version does not return size of cpumask_t */
+#if defined(__CYGWIN__)
+ n = __sched_getaffinity_sys(0, setsize, set);
+#else
n = syscall(SYS_sched_getaffinity, 0, setsize, set);
+#endif
if (n < 0 && errno == EINVAL && cpus < 1024 * 1024) {
cpuset_free(set);
