Input method in cygwin-x ?
Is there a way to use input method in cygwin-x environment? For example, when I invoke emacs with " ssh -X remote-machine emacs "" I can't use either input methods in local windows machine or those in remote linux server. Thanks, Arthur -- 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
[PATCH] cygcheck-dep 2.0-1: Bogus output from -l option
The 'cygcheck-dep -l' output also lists various packages which are actually required by other packages. Testcase: $ cygcheck -f /bin/cygcheck-dep cygcheck-dep-2.0-1 $ cygcheck-dep -c -N ncursesw ncursesw: is recursively needed for ( ) $ cygcheck-dep -c -N ncurses ncurses: is recursively needed for ( ncursesw ) $ cygcheck-dep -c -l | grep '^ ncurses' ncurses ncursesw The attached patch should fix that. Christian --- cygcheck-dep.orig 2013-12-06 22:08:41.0 +0100 +++ cygcheck-dep 2015-03-25 07:25:10.336495900 +0100 @@ -581,7 +581,7 @@ fi if [ "$f_nonleaves_be_necessary" ]; then - nonleaf_pkgs="$(IFS=$'\n' sort -n <<<"${pkg_drequisites[*]}" | sed '/^$/d' | uniq -c | sort -r | sed 's/^.* //')" + nonleaf_pkgs="$(IFS=$'\n'; tr ' ' '\n' <<<"${pkg_drequisites[*]}" | sed '/^$/d' | sort -n | uniq)" fi ### */ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Git thinks files are changed when they aren't
Chloe writes: > Cygwin Git always thinks files are changed even when they > aren't. After a commit with a Windows Git, Cygwin Git shows files as > modified. Then either don't mix Cygwin's and whatever Windows' Git you're using or tell Git to ignore the mode bits altogether (check the documentation for global.filemode in git-config). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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 Git thinks files are changed when they aren't
On 3/24/2015 5:50 PM, Yaakov Selkowitz wrote: > On Tue, 2015-03-24 at 16:42 -0400, Chloe wrote: >> Cygwin Git always thinks files are changed even when they aren't. After >> a commit with a Windows Git, Cygwin Git shows files as modified. > [snip] >> $ git diff .project >> diff --git a/.project b/.project >> old mode 100644 >> new mode 100755 > > This is your answer. On Windows, everything is executable, so changing > a file with any native Windows program is bound to set the executable > bit. A change in permissions is considered a modification in git, hence > the message. > > To avoid this, you'll probably have to git clone with your Windows git > to start with, as Cygwin programs won't change the permissions unless > you tell them to. See http://stackoverflow.com/questions/1580596 git config core.fileMode false -- Jim Garrison (j...@acm.org) PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88 -- 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: update trouble 1.7.35
Corinna Vinschen cygwin.com> writes: > > > from the keyserver hkp://keys.gnupg.net. However, what about my > questions about setting "db" only in nsswitch.conf? Does it help? > Do you have a SID history, too, by any chance? > The last test that I did was with "db" only in nsswitch.conf and unfortunately no, it did not help. I have also checked and I do not have an SID history. I hightly doubted as this is a new account, but double checked and all OK. I have sent trace file and cygcheck -srv to your other specified email address. Thanks again, Steve Johnson -- 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 Git thinks files are changed when they aren't
On Tue, 2015-03-24 at 16:42 -0400, Chloe wrote: > Cygwin Git always thinks files are changed even when they aren't. After > a commit with a Windows Git, Cygwin Git shows files as modified. [snip] > $ git diff .project > diff --git a/.project b/.project > old mode 100644 > new mode 100755 This is your answer. On Windows, everything is executable, so changing a file with any native Windows program is bound to set the executable bit. A change in permissions is considered a modification in git, hence the message. To avoid this, you'll probably have to git clone with your Windows git to start with, as Cygwin programs won't change the permissions unless you tell them to. -- Yaakov -- 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: mkpasswd: option to force the 'primary' domain?
On Mar 24 13:29, Linda Walsh wrote: > Corinna Vinschen wrote: > >On Mar 20 11:58, Tim Magee wrote: > >>Now then, > >> > >>Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us. Our > >>problem is with the way user names pulled from outside the primary domain > >>get decorated. My question is: will there ever be a way to tell > >>mkpasswd/mkgroup "make the one whose users get > >>undecorated names"? > > >I'm not planning this. The idea is that mkpasswd/mkgroup create account > >names compatible with the "db"-based accounts and everyhing else is left > >to post-creation manipulation. > --- > I never quite managed to understand this -- as my pw/grp files on > my client machines were already in sync with my domain setup and > worked as it would in a real Win Domain (i.e. Domain applied when I signed > into a machine that wasn't the domain controller and was using domain > credentials). If I logged into a machine with a local account, there has > never > been a domain name to have to bother with -- so for me user-logins were > prefixed > with the domain only when they were in a domain. > > This has been the way windows has worked for as long as I've run a domain > server -- > if a local machine is not in a domain, then it's username-only, but if it is > in a domain, then I'd need to type-or-add the local-machine name to NOT login > via the domain creds. > > For local accounts, the RID==the UID, for domain accounts the RID==the UID on > the domain controller. > > Do I understand that cygwin is no longer compatible with window's (and > samba's) naming convention? That would be a pain. Did you go to the trouble to read the new documentation under https://cygwin.com/cygwin-ug-net/ntsec.html? It's all explained there. If you don't like it, use passwd and group files with changed user names. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMx06v_5eW3.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 19:43, Steve Johnson wrote: > Corinna Vinschen cygwin.com> writes: > > > > > This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)" > > should only happen if you have /etc/nsswitch.conf is set to "files" > > only, and there's no entry in /etc/passwd with a matching SID. > > That's the only way I can reproduce this behaviour. > > > > Corinna > > > > > Hi Corinna, > > Where could I get the gpg key to send, as you had suggested earlier? I've > tried > posting replies with the requested information many times, but they all have > seemed to fail... from the keyserver hkp://keys.gnupg.net. However, what about my questions about setting "db" only in nsswitch.conf? Does it help? Do you have a SID history, too, by any chance? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfCrHM2mKvH.pgp Description: PGP signature
Cygwin Git thinks files are changed when they aren't
Cygwin Git always thinks files are changed even when they aren't. After a commit with a Windows Git, Cygwin Git shows files as modified. Windows Git -- C:\Users\Chloe\workspace\AffiliateArbitrage>git status On branch master nothing to commit, working directory clean C:\Users\Chloe\workspace\AffiliateArbitrage>git --version git version 1.9.5.msysgit.1 - Cygwin Git - $ git status On branch master Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: .project ... dozens of files $ git --version git version 2.1.4 $ git diff .project diff --git a/.project b/.project old mode 100644 new mode 100755 $ ls -l .project -rwxrwx---+ 1 Chloe None 574 Mar 10 21:28 .project $ uname -a CYGWIN_NT-6.3-WOW xps 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 Cygwin - -- 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: update trouble 1.7.35
On Mar 24 17:56, Lemke, Michael ST/HZA-ZSW wrote: > On Tuesday, March 24, 2015 5:49 PM Corinna Vinschen wrote: > >> Note that "they" did a domain switch here at some point. My installation > >> is really old and the passwd certainly is from before that domain change. > > > >That explains it. Please recreate your /etc/passwd and /etc/group > >files with mkpasswd and mkgroup, or, even better, just discard them. > > > > I just created new ones. I like passwd/group much better than AD, sorry. > Just like real unix before the invention of yellow pages and nis. Yeah, but real unix these days is NIS+ or FreeIPA, or... even AD :) > This > way I can easily give different shells to different users (not that it is > really important at the moment). You can do that in AD as well. Or, as long as all users want the same shell, you can simply use `db_shell: /bin/tcsh'. > In nsswitch.conf I put > passwd: files db > group: files db That's the default setting. You can simply remove nsswitch.conf in this case, which should result in a slightly faster startup because Cygwin doesn't have to scan YA file. > and ls listings seem to look fine. Login is also possible again > with correct tcsh shell. I'm glad to read that. > >The problem is the domain switch which also changed the SID of your user > >account. The old SID, which you also have in your passwd, is not > >returned by the server anymore. But it's stored in your SID history in > >AD and when asking for it you get an answer. > > So, to sort of sum this up: the new cygwin doesn't deal well with > contradicting entries in passwd and AD. Basically, yes. More to the point, your user token and your passwd file contradict each other. The user and owner entry in your user token is your new SID. The old SID only shows up in the token's group list, afaik. > >Downside: Cygwin can't handle the old SIDs from your SID history quite > >correctly. > > Actually, with "files db" it seems to handle it quite well. I get the same > username for both kind of files. There are still lots of files in my > home I created before the domain switch. Ok, I just can't guarantee that it always works. The SID history stuff is a weird solution for a weird problem. > >Trying to support them as well would slow down the user and > >group lookups a lot. If you can live with what we just found out and > >the solution I suggested, I'd be rather happy :} > > > > Yes, I am happy now. Then I am, too :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpECx_4Boib6.pgp Description: PGP signature
Re: mkpasswd: option to force the 'primary' domain?
Corinna Vinschen wrote: On Mar 20 11:58, Tim Magee wrote: Now then, Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us. Our problem is with the way user names pulled from outside the primary domain get decorated. My question is: will there ever be a way to tell mkpasswd/mkgroup "make the one whose users get undecorated names"? I'm not planning this. The idea is that mkpasswd/mkgroup create account names compatible with the "db"-based accounts and everyhing else is left to post-creation manipulation. --- I never quite managed to understand this -- as my pw/grp files on my client machines were already in sync with my domain setup and worked as it would in a real Win Domain (i.e. Domain applied when I signed into a machine that wasn't the domain controller and was using domain credentials). If I logged into a machine with a local account, there has never been a domain name to have to bother with -- so for me user-logins were prefixed with the domain only when they were in a domain. This has been the way windows has worked for as long as I've run a domain server -- if a local machine is not in a domain, then it's username-only, but if it is in a domain, then I'd need to type-or-add the local-machine name to NOT login via the domain creds. For local accounts, the RID==the UID, for domain accounts the RID==the UID on the domain controller. Do I understand that cygwin is no longer compatible with window's (and samba's) naming convention? That would be a pain. -- 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
X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks)
On Mar 24 19:59, Denis Excoffier wrote: > On 2015-02-28 16:30, Corinna Vinschen wrote: > > I can not reproduce this in mintty, nor in a Cygwin xterm started on a > > remote X server running under Linux. I can reproduce this with a local > > xterm started via startxwin. But, and that's the problem, I can > > reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and > > last but not least also with a debug version of the Cygwin DLL in which I > > backed out all PTY-related changes since last November. > > > > I'm not sure this is a giveaway, but from that it seems this problem > > is not directly related to a Cygwin change in the last months. > > > > So, jturney and I are wondering when exactly you encountered this problem > > for the first time. Did it coincide with a certain Cygwin release, > > or a certain X server? Or new X libs, perhaps? > > > > Anything you can provide to narrow down the potential culprit would be > > helpful. > > > Well. Here is some more inputs. > > This is connected with the "min" option of stty. When this occurs, > 'stty -a' says '4' for min. If i change into 'stty min 5' the characters > come by chunks of 5. > > I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and > i definitely don't understand where the 4 comes from. In any case, 4 should > not be > the problem, because 'stty min 4' is perfectly legitimate. > > The doc of stty says that 'min' (and 'time') are used in case of '-icanon'. > However, i found in fhandler_tty.cc that it seems not to be always the case. > After i applied the following patch: > > diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc > cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc > --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc > 2015-03-17 11:42:16.0 +0100 > +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc > 2015-03-24 19:32:42.0 +0100 > @@ -715,7 +715,7 @@ > >if (is_nonblocking () || !ptr) /* Indicating tcflush(). */ > time_to_wait = 0; > - else if ((get_ttyp ()->ti.c_lflag & ICANON)) > + else if (!(get_ttyp ()->ti.c_lflag & ICANON)) No, this is wrong. You're switching the code for icanon with the code for -icanon. -icanon in stty means ICANON is switched off. I just gave it another try and the behaviour is perfectly valid. The real problem is that "something" is setting VMIN to 4. And that's somehow inside the X server, if I'm not completely wrong: - If you start an xterm from mintty like this: xterm -display :0 and then call `stty -a' in it, you'll see that min is 1, and then script will behave as desired. - However, if you start xterm from the X server tray icon and then call `stty -a' in it, min is set to 4 and script will misbehave. If you call `stty min 1' before calling script, script will work as expected again. So, why does the X server (or whatever controls starting applications from the X server tray icon) set VMIN to 4? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp8r2SZejK72.pgp Description: PGP signature
Re: update trouble 1.7.35
Corinna Vinschen cygwin.com> writes: > > This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)" > should only happen if you have /etc/nsswitch.conf is set to "files" > only, and there's no entry in /etc/passwd with a matching SID. > That's the only way I can reproduce this behaviour. > > Corinna > Hi Corinna, Where could I get the gpg key to send, as you had suggested earlier? I've tried posting replies with the requested information many times, but they all have seemed to fail... Sorry for the added complexity. Thanks, Steve Johnson -- 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
Under /bin/script, characters get printed in four-character chunks
On 2015-02-28 16:30, Corinna Vinschen wrote: > > On Feb 28 15:19, Denis Excoffier wrote: >> On 2015-02-28 13:13, Corinna Vinschen wrote: >>> >>> On Feb 28 00:23, Denis Excoffier wrote: On 2015-02-27 18:52, Corinna Vinschen wrote: > > I released another TEST version of the next upcoming Cygwin release. > I have noticed that the behavior of /usr/bin/script is not better than previously (probably the change resides near https://cygwin.com/ml/cygwin-cvs/2015-q1/msg00094.html). For at least several weeks, the behavior was ok, except for the Return key, which had to be hit several times to take effect. But the other characters were ok. Now (after 2015-02-26), only every fourth character that i type is flushed to the command line, Return key included. For example, suppose that my command is "abcdefgh": only after i hit the 'd' key is "abcd" displayed, and only after i hit the 'h' key the "efgh" is displayed (the command line reads "abcdefgh"); now i have to hit four times the return key to "enter" the command. Previously, the fourth-character-delay was probably already there, but only for the Return key. >>> >>> I can't reproduce this. I started script, script starts my shell, and >>> then I can type and I see every character I type immediately, including >>> the ENTER key. I tried with SHELL set to /bin/tcsh as well as with >>> /bin/bash. >>> >> Oops, forgot to mention: it is under xterm only. Under cmd.exe or under >> mintty, all is correct. > > Since when do you see this problem? > > I can not reproduce this in mintty, nor in a Cygwin xterm started on a > remote X server running under Linux. I can reproduce this with a local > xterm started via startxwin. But, and that's the problem, I can > reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and > last but not least also with a debug version of the Cygwin DLL in which I > backed out all PTY-related changes since last November. > > I'm not sure this is a giveaway, but from that it seems this problem > is not directly related to a Cygwin change in the last months. > > So, jturney and I are wondering when exactly you encountered this problem > for the first time. Did it coincide with a certain Cygwin release, > or a certain X server? Or new X libs, perhaps? > > Anything you can provide to narrow down the potential culprit would be > helpful. > Well. Here is some more inputs. This is connected with the "min" option of stty. When this occurs, 'stty -a' says '4' for min. If i change into 'stty min 5' the characters come by chunks of 5. I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin and i definitely don't understand where the 4 comes from. In any case, 4 should not be the problem, because 'stty min 4' is perfectly legitimate. The doc of stty says that 'min' (and 'time') are used in case of '-icanon'. However, i found in fhandler_tty.cc that it seems not to be always the case. After i applied the following patch: diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc 2015-03-17 11:42:16.0 +0100 +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc 2015-03-24 19:32:42.0 +0100 @@ -715,7 +715,7 @@ if (is_nonblocking () || !ptr) /* Indicating tcflush(). */ time_to_wait = 0; - else if ((get_ttyp ()->ti.c_lflag & ICANON)) + else if (!(get_ttyp ()->ti.c_lflag & ICANON)) time_to_wait = INFINITE; else { and the problem was gone. Let's try an explanation: the problem is present since "the beginning", at least since 2000-02-17, see https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_tty.cc;hb=1fd5e000ace55b323124c7e556a7a864b972a5c4, and recent (2014-11-13) changes in fhandler_tty.cc made it to appear. Perhaps i'm also completely wrong. Hoping this will help, Regards, Denis Excoffier. -- 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: update trouble 1.7.35
Greetings, Lemke, Michael ST/HZA-ZSW! > I just created new ones. I like passwd/group much better than AD, sorry. > Just like real unix before the invention of yellow pages and nis. This > way I can easily give different shells to different users You can give them in AD the same way. And they will persist through your system reinstalls and hardware changes. Having millions of separate file "databases" you have to maintain was never a good idea, and people were always looking for ways to simplify the management overhead. > (not that it is really important at the moment). > In nsswitch.conf I put > passwd: files db > group: files db > and ls listings seem to look fine. Login is also possible again > with correct tcsh shell. >>The problem is the domain switch which also changed the SID of your user >>account. The old SID, which you also have in your passwd, is not >>returned by the server anymore. But it's stored in your SID history in >>AD and when asking for it you get an answer. > So, to sort of sum this up: the new cygwin doesn't deal well with > contradicting entries in passwd and AD. It doesn't deal with them at all. It works with what it is given. > Or something like that. Maybe you can at least make the login process > generate an error message. What kind of error message? > I just > realize there is one (which started this whole thread) but if you start > cygwin from a minty shortcut (as I do and as it is the default I think) all > you get is a flashing window. I added "-h always" to the mintty options > to actually see the message. Weird local setups, like yours, is what was the primary reason to rewrite the user handling in Cygwin in first place. To have more transparent link to the underlying system calls. >>> >>> I noticed something else: With nsswitch.conf db: >>> >>> > ls -l >>> ... >>> -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users 10057 Oct 21 2013 >>> testresults.xml >>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Nov 9 2010 >>> tidy4aug00 >>> drwxrwxr-x+ 1 lemkemch Domain Users 0 May 14 2014 tinymce >>> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Jan 13 2012 >>> tomahawk-1.1.11 >>> ... >>> > ls -ln >>> ... >>> -rw-rwxr--+ 1 1051305 1073742337 10057 Oct 21 2013 testresults.xml >>> drwxr-xr-x+ 1 1051305 1073742337 0 Nov 9 2010 tidy4aug00 >>> drwxrwxr-x+ 1 11757881049089 0 May 14 2014 tinymce >>> drwxr-xr-x+ 1 1051305 1073742337 0 Jan 13 2012 tomahawk-1.1.11 >>> ... >>> >>> Note the different numerical id's that translate to the same username. >>> Don't know if it means anything. I just find it weird. >> >>That's due to your SID history. It's a bit hard to explain, but that >>occurs when "they" switch to a new domain with different SIDs. When >>asking for the new and the old SID, the same username is returned since >>both are your SIDs, one old, one new. >> >>I strongly recommend not to use the old SID anymore. The reason is that >>Cygwin will create all these files with the old SIDs. However, your >>actual user token has the new SID. Uh, as I wrote, hard to explain and >>a weird situation. > Ok, I think I get it. >> >>Downside: Cygwin can't handle the old SIDs from your SID history quite >>correctly. > Actually, with "files db" it seems to handle it quite well. I get the same > username for both kind of files. There are still lots of files in my > home I created before the domain switch. That's because Cygwin ask system "who is that man with this face(SID)?" and get the answer, that it is you, because that SID is in your history. Nothing is changed, really. And nothing should, in this regard. >>Trying to support them as well would slow down the user and >>group lookups a lot. If you can live with what we just found out and >>the solution I suggested, I'd be rather happy :} >> > Yes, I am happy now. You can get better results, if you define default shell in nsswitch.conf, rather than hose Cygwin back into 20'st century with your files db. I assume, you're the only one who's using this system, right? So, the change wouldn't affect anyone else. -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.03.2015, <21:37> Sorry for my terrible english... -- 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: static vs. shared linking
On 24/03/2015 00:02, David Stacey wrote: I've been having difficulty building poco-1.6.0 for Cygwin for some time. I've managed to produce a test case that shows the problem: https://dl.dropboxusercontent.com/u/119453582/Cygwin/crashtest.tar.xz This archive contains source files that produce a very simple library. When linked statically, the code works fine. However, when linked as a shared DLL, the test crashes with a core dump. The behaviour is identical on x86 and x86_64 architectures. Have I made a stupid error in the compilation of the shared case, or is something more interesting going on? I don't know if anyone has managed to look at this. I haven't had a deluge of e-mails telling me that I've done something silly (which is a shame, because then I could fix it quickly and move on). For the sake of a straw to clutch at, I tried compiling with clang++ rather than g++, and got the same result: $ ./go.sh Running test (static link)... Done. Running test (shared link)... ./go.sh: line 19: 3744 Aborted (core dumped) ./shared_test Done. Any help or hints would be greatly appreciated. Dave. -- 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: update trouble 1.7.35
On Tuesday, March 24, 2015 5:49 PM Corinna Vinschen wrote: >On Mar 24 16:25, Lemke, Michael ST/HZA-ZSW wrote: >> On March 24, 2015 4:50 PM Corinna Vinschen wrote: >> >On Mar 24 15:19, Lemke, Michael ST/HZA-ZSW wrote: >> >> C:\NCygwin\bin>cat ..\etc\nsswitch.conf >> >> passwd: files >> >> group: files >> >> >> >> C:\NCygwin\bin>getent passwd %USERNAME% >> >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1 >> >> 846952604-2729:/home/lemkemch:/bin/tcsh >> > >> >Is that what you have in /etc/passwd? >> >> Oops, thought I also showed passwd: >> >> C:\NCygwin\bin>cat ..\etc\passwd >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh >> >> > >> >> C:\NCygwin\bin>id >> >> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) >> >> groups=545(Users),555 >> >> (Remote Desktop Users) >> > >> >what does `mkpasswd -d | grep -i lemkemch' print? >> >> C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch >> lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash > >Ouch. Your user SID from AD is different to the one in /etc/passwd. > >> Note that "they" did a domain switch here at some point. My installation >> is really old and the passwd certainly is from before that domain change. > >That explains it. Please recreate your /etc/passwd and /etc/group >files with mkpasswd and mkgroup, or, even better, just discard them. > I just created new ones. I like passwd/group much better than AD, sorry. Just like real unix before the invention of yellow pages and nis. This way I can easily give different shells to different users (not that it is really important at the moment). In nsswitch.conf I put passwd: files db group: files db and ls listings seem to look fine. Login is also possible again with correct tcsh shell. >The problem is the domain switch which also changed the SID of your user >account. The old SID, which you also have in your passwd, is not >returned by the server anymore. But it's stored in your SID history in >AD and when asking for it you get an answer. So, to sort of sum this up: the new cygwin doesn't deal well with contradicting entries in passwd and AD. Or something like that. Maybe you can at least make the login process generate an error message. I just realize there is one (which started this whole thread) but if you start cygwin from a minty shortcut (as I do and as it is the default I think) all you get is a flashing window. I added "-h always" to the mintty options to actually see the message. >> >> I noticed something else: With nsswitch.conf db: >> >> > ls -l >> ... >> -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users 10057 Oct 21 2013 >> testresults.xml >> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Nov 9 2010 >> tidy4aug00 >> drwxrwxr-x+ 1 lemkemch Domain Users 0 May 14 2014 tinymce >> drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Jan 13 2012 >> tomahawk-1.1.11 >> ... >> > ls -ln >> ... >> -rw-rwxr--+ 1 1051305 1073742337 10057 Oct 21 2013 testresults.xml >> drwxr-xr-x+ 1 1051305 1073742337 0 Nov 9 2010 tidy4aug00 >> drwxrwxr-x+ 1 11757881049089 0 May 14 2014 tinymce >> drwxr-xr-x+ 1 1051305 1073742337 0 Jan 13 2012 tomahawk-1.1.11 >> ... >> >> Note the different numerical id's that translate to the same username. >> Don't know if it means anything. I just find it weird. > >That's due to your SID history. It's a bit hard to explain, but that >occurs when "they" switch to a new domain with different SIDs. When >asking for the new and the old SID, the same username is returned since >both are your SIDs, one old, one new. > >I strongly recommend not to use the old SID anymore. The reason is that >Cygwin will create all these files with the old SIDs. However, your >actual user token has the new SID. Uh, as I wrote, hard to explain and >a weird situation. Ok, I think I get it. > >Downside: Cygwin can't handle the old SIDs from your SID history quite >correctly. Actually, with "files db" it seems to handle it quite well. I get the same username for both kind of files. There are still lots of files in my home I created before the domain switch. >Trying to support them as well would slow down the user and >group lookups a lot. If you can live with what we just found out and >the solution I suggested, I'd be rather happy :} > Yes, I am happy now. Thanks, Michael
Re: xterm does not launch from a local shell after upgrade...
On 3/24/2015 6:03 PM, gary.bar...@datasoft.com wrote: I had not upgraded in sometime the last setup.exe I had downloaded was 12/18/2014 then most recently 3/18/2015. After completing the install/upgrades I attempt to restart xwin via startxwin command. Now I get an instance appearing on my task bar and in the typical iconized item in the task list, I also now have an active application showing in the upper left hand corner of my display. When I attempt to launch xterm, or any other xapplication, from the Cygwin command line it responds ‘xterm: Xt error: Can't open display:’ or associated applications name. If I attempt to launch xterm from a Windows desktop shortcut ‘C:\cygwin\bin\run.exe -p /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls +ah -aw -rightbar -sb -sl 1000 /bin/bash’ a window flashes on the screen and disappears. I have change in: run -p /usr/bin xterm -display :0.0 -ls +ah -aw -rightbar -sb -sl 1000 /bin/bash Currently the Xserver is not using anymore TCP connection so 127.0.0.1 is causing the "Can't open display" see "-nolisten tcp' deafult on: https://www.cygwin.com/ml/cygwin-xfree-announce/2015-02/msg00014.html /usr/X11R6/bin is not used by long time -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
xterm does not launch from a local shell after upgrade...
I had not upgraded in sometime the last setup.exe I had downloaded was 12/18/2014 then most recently 3/18/2015. The purpose of the most recent upgrade was to install Qt libraries and include files so that my code built on Linux would not show hundreds of errors and missing definitions when viewing on Windows. However in doing so several other files were upgraded and I do not know which is the issue. So here goes… After completing the install/upgrades I attempt to restart xwin via startxwin command. Now I get an instance appearing on my task bar and in the typical iconized item in the task list, I also now have an active application showing in the upper left hand corner of my display. When I attempt to launch xterm, or any other xapplication, from the Cygwin command line it responds ‘xterm: Xt error: Can't open display:’ or associated applications name. If I attempt to launch xterm from a Windows desktop shortcut ‘C:\cygwin\bin\run.exe -p /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls +ah -aw -rightbar -sb -sl 1000 /bin/bash’ a window flashes on the screen and disappears. I have changed nothing in my Cygwin startups, or methods for starting XServer, however the only way to open an xterm is through the application in the upper left corner. Changing the display variable to my ip address, localhost, or computername does not solve the issue. Downgrading to 1.17.1.0 from the current version does not help either. So whatever versions of all the applications that were upgraded from is unknown to me, and do not know how to downgrade all applications to what they were on 12/18/2014. So I am seeing two major changes: XServer that now appears on the desktop and unable to launch xterm from any place other than the XServer application. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.17.1.0 OS: CYGWIN_NT-6.1-WOW TANGO2 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.17.1-1 built 2015-02-13 XWin was started with the following command line: /usr/bin/XWin :0 -multiwindow -nolisten tcp -auth /home/barnes_g/.serverauth.17268 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1920 h 1080 winInitializeScreenDefaults - native DPI x 96 y 96 [ 7609.151] (II) xorg.conf is not supported [ 7609.151] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 7609.151] LoadPreferences: /home/barnes_g/.XWinrc not found [ 7609.151] LoadPreferences: Loading /etc/X11/system.XWinrc [ 7609.151] LoadPreferences: Done parsing the configuration file... [ 7609.182] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 7609.182] winDetectSupportedEngines - Returning, supported engines 0005 [ 7609.198] winSetEngine - Multi Window or Rootless => ShadowGDI [ 7609.198] winScreenInit - Using Windows display depth of 32 bits per pixel [ 7609.198] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 1080 depth: 32 [ 7609.198] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 7609.198] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [ 7609.260] MIT-SHM extension disabled due to lack of kernel support [ 7609.260] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 7609.260] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [ 7609.338] (II) AIGLX: Testing pixelFormatIndex 1 [ 7609.369] GL_VERSION: 4.2.11320 Compatibility Profile Context [ 7609.369] GL_VENDOR: ATI Technologies Inc. [ 7609.369] GL_RENDERER:AMD Radeon HD 7570 [ 7609.369] (II) AIGLX: enabled GLX_SGI_make_current_read [ 7609.369] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 7609.369] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [ 7609.369] (II) AIGLX: enabled GLX_SGIX_pbuffer [ 7609.369] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample [ 7609.369] (II) 107 pixel formats reported by wglGetPixelFormatAttribivARB [ 7609.369] (II) AIGLX: Set GLX version to 1.4 [ 7609.385] (II) 30 fbConfigs [ 7609.385] (II) ignored pixel formats: 0 not OpenGL, 12 RBGA float, 30 RGBA unsigned float, 0 unknown pixel type, 35 unaccelerated [ 7609.385] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [ 7609.650] winPointerWarpCursor - Discarding first warp: 1920 540 [ 7609.650] (--) 8 mouse buttons found [ 7609.650] (--) Setting autorepeat to delay=500, rate=31 [ 7609.650] (--) Windows keyboard layout: "0409" (0409) "US", type 4 [ 7609.650] (--) Found matching XKB configuration "English (USA)" [ 7609.650] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 7609.650] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 7609.650] winInitMultiWindowWM - DISPLAY=:0.0 [ 7609.650] winMultiWindowXMsgProc - DISPLAY=:0.0 [ 7609.869] winProcEstablishConn
Re: update trouble 1.7.35
On Mar 24 16:25, Lemke, Michael ST/HZA-ZSW wrote: > On March 24, 2015 4:50 PM Corinna Vinschen wrote: > >On Mar 24 15:19, Lemke, Michael ST/HZA-ZSW wrote: > >> C:\NCygwin\bin>cat ..\etc\nsswitch.conf > >> passwd: files > >> group: files > >> > >> C:\NCygwin\bin>getent passwd %USERNAME% > >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1 > >> 846952604-2729:/home/lemkemch:/bin/tcsh > > > >Is that what you have in /etc/passwd? > > Oops, thought I also showed passwd: > > C:\NCygwin\bin>cat ..\etc\passwd > lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh > > > > >> C:\NCygwin\bin>id > >> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) > >> groups=545(Users),555 > >> (Remote Desktop Users) > > > >what does `mkpasswd -d | grep -i lemkemch' print? > > C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch > lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash Ouch. Your user SID from AD is different to the one in /etc/passwd. > Note that "they" did a domain switch here at some point. My installation > is really old and the passwd certainly is from before that domain change. That explains it. Please recreate your /etc/passwd and /etc/group files with mkpasswd and mkgroup, or, even better, just discard them. The problem is the domain switch which also changed the SID of your user account. The old SID, which you also have in your passwd, is not returned by the server anymore. But it's stored in your SID history in AD and when asking for it you get an answer. > >> Anything else you'd like me try? > > > >Can you change /etc/nsswitch.conf to "db" only, stop all cygwin > >processes and restart a shell? What does `getent passwd %USERNAME%' > >and `id' print now? How does an strace of this getent call look like? > > C:\NCygwin\bin>vi ..\etc\nsswitch.conf > > C:\NCygwin\bin>cat ..\etc\nsswitch.conf > passwd: db > group: db > > C:\NCygwin\bin>getent passwd %USERNAME% > lemkemch:*:1175788:1049089:XXX\lemkemch,S-1-5-21-435809281-806517502-25 > 25237208-127212:/home/lemkemch:/bin/bash > > C:\NCygwin\bin>id > uid=1175788(lemkemch) gid=1049089(Domain Users) groups=1049089(Domain > Users),... > many many groups I don't like to post here. So it works. That's cool. I'd suggest to throw away your passwd and group files and live happily ever after. > > I'm grabbing for straws... > > I noticed something else: With nsswitch.conf db: > > > ls -l > ... > -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users 10057 Oct 21 2013 > testresults.xml > drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Nov 9 2010 > tidy4aug00 > drwxrwxr-x+ 1 lemkemch Domain Users 0 May 14 2014 tinymce > drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Jan 13 2012 > tomahawk-1.1.11 > ... > > ls -ln > ... > -rw-rwxr--+ 1 1051305 1073742337 10057 Oct 21 2013 testresults.xml > drwxr-xr-x+ 1 1051305 1073742337 0 Nov 9 2010 tidy4aug00 > drwxrwxr-x+ 1 11757881049089 0 May 14 2014 tinymce > drwxr-xr-x+ 1 1051305 1073742337 0 Jan 13 2012 tomahawk-1.1.11 > ... > > Note the different numerical id's that translate to the same username. > Don't know if it means anything. I just find it weird. That's due to your SID history. It's a bit hard to explain, but that occurs when "they" switch to a new domain with different SIDs. When asking for the new and the old SID, the same username is returned since both are your SIDs, one old, one new. I strongly recommend not to use the old SID anymore. The reason is that Cygwin will create all these files with the old SIDs. However, your actual user token has the new SID. Uh, as I wrote, hard to explain and a weird situation. Downside: Cygwin can't handle the old SIDs from your SID history quite correctly. Trying to support them as well would slow down the user and group lookups a lot. If you can live with what we just found out and the solution I suggested, I'd be rather happy :} Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYurFlpwpMx.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 12:22, Steve Johnson wrote: > Unfortunately, that is one piece of information that I forgot to mention > after I had removed stripped out the output of the commands. I get no output > whatsoever from getent. Here is the output of the commands, when I had run > them this morning: > > C:\cygwin64\bin>getent passwd %USERNAME% > > C:\cygwin64\bin>id > uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) > groups=545(Users),544(Admins),4(A1),66049(A2),11(Auth users),15(This > org),4095(CurrentSession),66048(LOCAL),1056170(A3),1057070(A4),1051115(A5),1 > 051005(A6),1056095(A7),1056192(A8),1051509(A9),1054768(A10),1057114(A11),104 > 9887(A12),1068445(A13),1051461(A14),1057115(A15),1056098(A16),1068744(A17),1 > 050912(A18),1068708(A19),1052088(A20),1053844(A21),1057175(A22),1053843(A23) > ,1051713(A24),1054212(A25),1057536(A26),1050984(A28),1054460(A29),1057071(A3 > 0),1055832(A31),1055117(A32),1051006(A33),1057060(A34),1068699(A35),1054464( > A36),1054462(A37),1054195(A38),1053997(A39),1054461(A40),1051464(A41),105172 > 5(A42),1057094(A43),1049914(A44),1050873(A44),1051719(A45),1055144(A46),1051 > 617(A47),1056091(A48),1055831(A49),1051093(A50),1068698(A51),1050648(A52),10 > 51842(A53),1051159(A54),1051187(A55),405504(A56) > > I ran id again, before writing this reply, and only got the following: > > C:\cygwin64\bin>id > uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) So it create a different output the second time?!? What does your /etc/nsswitch.conf look like? If you set /etc/nsswitch.conf to passwd: db group: db stop all Cygwin processes, start a shell and call `id' again, what does it look like? Can you provide an strace of `id' with this setting? Thanks, Corinna > 2068281 [main] getent 4532 transport_layer_pipes::connect: Try to > connect to named pipe: \\.\pipe\cygwin-e022582115c10879-lpc >538334 [main] getent 4532 transport_layer_pipes::connect: Error > opening the pipe (2) >468380 [main] getent 4532 client_request::make_request: cygserver un- > available > 10223 18603 [main] getent 4532 internal_getlogin: user not found in passwd > DB This looks strange. When connecting cygserver fails, Cygwin is supposed to fall back to reading /etc/passwd (if "files" is given) and if that fails as well, fall back to "db" (if "db" is given). And the latter should produce additional output, which just doesn't show up. I don't see why, unless your /etc/nsswitch.conf forbids "db". This "uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group)" should only happen if you have /etc/nsswitch.conf is set to "files" only, and there's no entry in /etc/passwd with a matching SID. That's the only way I can reproduce this behaviour. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTNwKz0uhtp.pgp Description: PGP signature
RE: update trouble 1.7.35
>You don't have a setup per chance that doesn't yet have network connectivity >when cygserver starts up? Firewall >opened only when a user logs in? VPN >needs time to establish connection? Is cygserver dependent on the tcpip >>service? No (at least not today and recently). I'm hardwired (Ethernet) in my office for the last several days. No firewall on outbound connections. No VPN (while physically in the office). Confirmed that the cygserver service has dependencies set on "Ancillary Function Driver for Winsock" and "TCP/IP Protocol Driver". Dave -- 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: update trouble 1.7.35
On March 24, 2015 4:50 PM Corinna Vinschen wrote: >On Mar 24 15:19, Lemke, Michael ST/HZA-ZSW wrote: >> On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote: >> >On Mar 24 13:28, Steve Johnson wrote: >> >> >> >> I am having the same issue, but from a fresh install of cygwin64. >> >> >> > >> >The problem is this: I can't reproduce this. I need a means to >> >reproduce this to be able to fix it. I'm totally stumped by this weird >> >problem because it seems LookupAccountSid fails and I never saw that >> >before and don't see this on my machines and in my environment. >> >> Ok, let's see what I can come up with. > >Thanks, but I'm even more puzzled than before. > >> For the test I cut >> down passwd to just a single line and removed /etc/group - the problem >> still occurs. From a cmd window: >> >> C:\NCygwin\bin>cat ..\etc\nsswitch.conf >> passwd: files >> group: files >> >> C:\NCygwin\bin>getent passwd %USERNAME% >> lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1 >> 846952604-2729:/home/lemkemch:/bin/tcsh > >Is that what you have in /etc/passwd? Oops, thought I also showed passwd: C:\NCygwin\bin>cat ..\etc\passwd lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1846952604-2729:/home/lemkemch:/bin/tcsh > >> C:\NCygwin\bin>id >> uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) >> groups=545(Users),555 >> (Remote Desktop Users) > >what does `mkpasswd -d | grep -i lemkemch' print? C:\NCygwin\bin>mkpasswd -d | grep -i lemkemch lemkemch:*:1175788:1049089:\lemkemch,S-1-5-21-435809281-806517502-2525237208-127212:/home/lemkemch:/bin/bash Note that "they" did a domain switch here at some point. My installation is really old and the passwd certainly is from before that domain change. >The unknown user is >totally weird. It should only occur if your SID doesn't show up in your >/etc/passwd file. Also, if /etc/nsswitch.conf is "files" only, and >you don't have a group file, there should be only one group in your `id' >output, the primary group 10513. >Here's how it looks like for me: > > $ getent passwd corinna > > corinna:unused:11001:11125:U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh > $ id > uid=11001(corinna) gid=11125 groups=11125 > >Did you stop all cygwin processes after doing all the settings, >including any service? yep. > >> strace output (hopefully) attached. >> >> Anything else you'd like me try? > >Can you change /etc/nsswitch.conf to "db" only, stop all cygwin >processes and restart a shell? What does `getent passwd %USERNAME%' >and `id' print now? How does an strace of this getent call look like? C:\NCygwin\bin>vi ..\etc\nsswitch.conf C:\NCygwin\bin>cat ..\etc\nsswitch.conf passwd: db group: db C:\NCygwin\bin>getent passwd %USERNAME% lemkemch:*:1175788:1049089:XXX\lemkemch,S-1-5-21-435809281-806517502-25 25237208-127212:/home/lemkemch:/bin/bash C:\NCygwin\bin>id uid=1175788(lemkemch) gid=1049089(Domain Users) groups=1049089(Domain Users),... many many groups I don't like to post here. > I'm grabbing for straws... I noticed something else: With nsswitch.conf db: > ls -l ... -rw-rwxr--+ 1 lemkemch OLDDOMAIN+Domain Users 10057 Oct 21 2013 testresults.xml drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Nov 9 2010 tidy4aug00 drwxrwxr-x+ 1 lemkemch Domain Users 0 May 14 2014 tinymce drwxr-xr-x+ 1 lemkemch OLDDOMAIN+Domain Users 0 Jan 13 2012 tomahawk-1.1.11 ... > ls -ln ... -rw-rwxr--+ 1 1051305 1073742337 10057 Oct 21 2013 testresults.xml drwxr-xr-x+ 1 1051305 1073742337 0 Nov 9 2010 tidy4aug00 drwxrwxr-x+ 1 11757881049089 0 May 14 2014 tinymce drwxr-xr-x+ 1 1051305 1073742337 0 Jan 13 2012 tomahawk-1.1.11 ... Note the different numerical id's that translate to the same username. Don't know if it means anything. I just find it weird. Michael
Re: update trouble 1.7.35
Unfortunately, that is one piece of information that I forgot to mention after I had removed stripped out the output of the commands. I get no output whatsoever from getent. Here is the output of the commands, when I had run them this morning: C:\cygwin64\bin>getent passwd %USERNAME% C:\cygwin64\bin>id uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) groups=545(Users),544(Admins),4(A1),66049(A2),11(Auth users),15(This org),4095(CurrentSession),66048(LOCAL),1056170(A3),1057070(A4),1051115(A5),1 051005(A6),1056095(A7),1056192(A8),1051509(A9),1054768(A10),1057114(A11),104 9887(A12),1068445(A13),1051461(A14),1057115(A15),1056098(A16),1068744(A17),1 050912(A18),1068708(A19),1052088(A20),1053844(A21),1057175(A22),1053843(A23) ,1051713(A24),1054212(A25),1057536(A26),1050984(A28),1054460(A29),1057071(A3 0),1055832(A31),1055117(A32),1051006(A33),1057060(A34),1068699(A35),1054464( A36),1054462(A37),1054195(A38),1053997(A39),1054461(A40),1051464(A41),105172 5(A42),1057094(A43),1049914(A44),1050873(A44),1051719(A45),1055144(A46),1051 617(A47),1056091(A48),1055831(A49),1051093(A50),1068698(A51),1050648(A52),10 51842(A53),1051159(A54),1051187(A55),405504(A56) I ran id again, before writing this reply, and only got the following: C:\cygwin64\bin>id uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) Below is the output from strace of getent command: 2 2 [main] getent (4532) ** 182 184 [main] getent (4532) Program name: C:\cygwin64\bin\getent.exe (windows pid 4532) 57 241 [main] getent (4532) OS version: Windows NT-6.1 28 269 [main] getent (4532) ** 163 432 [main] getent (4532) sigprocmask: 0 = sigprocmask (0, 0x0, 0x1802D1CA8) 395 827 [main] getent 4532 open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0x60, *m 6 55 882 [main] getent 4532 user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 112 994 [main] getent 4532 open_shared: name S-1-5-21-1155469006- 580272788-1541874228-59418.1, n 1, shared 0x18002 (wanted 0x18002), h 0x5C, *m 6 581052 [main] getent 4532 user_info::create: opening user shared for 'S-1-5-21-1155469006-580272788-1541874228-59418' at 0x18002 871139 [main] getent 4532 user_info::create: user shared version AB1FCCE8 1141253 [main] getent 4532 fhandler_pipe::create: name \\.\pipe\cygwin-e022582115c10879-4532-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 841337 [main] getent 4532 fhandler_pipe::create: pipe read handle 0x78 301367 [main] getent 4532 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-e022582115c10879-4532-sigwait 551422 [main] getent 4532 fhandler_pipe::create: pipe write handle 0x7C 821504 [main] getent 4532 dll_crt0_0: finished dll_crt0_0 initialization 12872791 [sig] getent 4532 wait_sig: entering ReadFile loop, my_readsig 0x78, my_sendsig 0x7C 2753066 [main] getent 4532 time: 1427207219 = time(0x0) 1043170 [main] getent 4532 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin64\bin, no-keep-rel, no-add-slash) 483218 [main] getent 4532 normalize_win32_path: C:\cygwin64\bin = normalize_win32_path (C:\cygwin64\bin) 333251 [main] getent 4532 mount_info::conv_to_posix_path: /usr/bin = conv_to_posix_path (C:\cygwin64\bin) 543305 [main] getent 4532 sigprocmask: 0 = sigprocmask (0, 0x0, 0x600018128) 2113516 [main] getent 4532 _cygwin_istext_for_stdio: fd 0: not open 393555 [main] getent 4532 _cygwin_istext_for_stdio: fd 1: not open 253580 [main] getent 4532 _cygwin_istext_for_stdio: fd 2: not open 943674 [main] getent (4532) open_shared: name cygpid.4532, n 4532, shared 0x18001 (wanted 0x18001), h 0xB8, *m 2 363710 [main] ? (4532) time: 1427207219 = time(0x0) 283738 [main] getent 4532 pinfo::thisproc: myself dwProcessId 4532 1103848 [main] getent 4532 environ_init: GetEnvironmentStrings returned 0x408020 773925 [main] getent 4532 environ_init: 0x6000284F0: !C:=C:\cygwin64\bin 523977 [main] getent 4532 environ_init: 0x600028510: !ExitCode=0002 724049 [main] getent 4532 environ_init: 0x600028530: ALLUSERSPROFILE=C:\ProgramData 594108 [main] getent 4532 environ_init: 0x600028560: APPDATA=C:\Users\johndoe\AppData\Roaming 654173 [main] getent 4532 environ_init: 0x600028590: CLASSPATH=.;C:\Program Files (x86)\Java\jre1.8.0_31\lib\ext\QTJava.zip 454218 [main] getent 4532 environ_init: 0x6000285E0: COMMONPROGRAMFILES=C:\Program Files\Common Files 424260 [main] getent 4532 environ_init: 0x600028620: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 424302 [main] getent 4532 environ_init: 0x600028670: CommonProgramW6432=C:\Program Files\Common Files 534355 [main] getent 4532 environ_init: 0x6000286B0: COMPUTERNAME=LAPTOPA 55
Re: update trouble 1.7.35
On Mar 24 15:19, Lemke, Michael ST/HZA-ZSW wrote: > On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote: > >On Mar 24 13:28, Steve Johnson wrote: > >> > >> I am having the same issue, but from a fresh install of cygwin64. > >> > > > >The problem is this: I can't reproduce this. I need a means to > >reproduce this to be able to fix it. I'm totally stumped by this weird > >problem because it seems LookupAccountSid fails and I never saw that > >before and don't see this on my machines and in my environment. > > Ok, let's see what I can come up with. Thanks, but I'm even more puzzled than before. > For the test I cut > down passwd to just a single line and removed /etc/group - the problem > still occurs. From a cmd window: > > C:\NCygwin\bin>cat ..\etc\nsswitch.conf > passwd: files > group: files > > C:\NCygwin\bin>getent passwd %USERNAME% > lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1 > 846952604-2729:/home/lemkemch:/bin/tcsh Is that what you have in /etc/passwd? > C:\NCygwin\bin>id > uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) > groups=545(Users),555 > (Remote Desktop Users) what does `mkpasswd -d | grep -i lemkemch' print? The unknown user is totally weird. It should only occur if your SID doesn't show up in your /etc/passwd file. Also, if /etc/nsswitch.conf is "files" only, and you don't have a group file, there should be only one group in your `id' output, the primary group 10513. Here's how it looks like for me: $ getent passwd corinna corinna:unused:11001:11125:U-VINSCHEN\corinna,S-1-5-21-2913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh $ id uid=11001(corinna) gid=11125 groups=11125 Did you stop all cygwin processes after doing all the settings, including any service? > strace output (hopefully) attached. > > Anything else you'd like me try? Can you change /etc/nsswitch.conf to "db" only, stop all cygwin processes and restart a shell? What does `getent passwd %USERNAME%' and `id' print now? How does an strace of this getent call look like? I'm grabbing for straws... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpyqs3pDMo52.pgp Description: PGP signature
RE: update trouble 1.7.35
On Tuesday, March 24, 2015 3:04 PM Corinna Vinschen wrote: >On Mar 24 13:28, Steve Johnson wrote: >> >> I am having the same issue, but from a fresh install of cygwin64. >> > >The problem is this: I can't reproduce this. I need a means to >reproduce this to be able to fix it. I'm totally stumped by this weird >problem because it seems LookupAccountSid fails and I never saw that >before and don't see this on my machines and in my environment. Ok, let's see what I can come up with. For the test I cut down passwd to just a single line and removed /etc/group - the problem still occurs. From a cmd window: C:\NCygwin\bin>cat ..\etc\nsswitch.conf passwd: files group: files C:\NCygwin\bin>getent passwd %USERNAME% lemkemch:unused:12729:10513:U-INA-DE01\lemkemch,S-1-5-21-1373454394-1654746546-1 846952604-2729:/home/lemkemch:/bin/tcsh C:\NCygwin\bin>id uid=4294967295(Unknown+User) gid=4294967295(Unknown+Group) groups=545(Users),555 (Remote Desktop Users) strace output (hopefully) attached. Anything else you'd like me try? Michael 1 1 [main] getent (9260) ** 143 144 [main] getent (9260) Program name: C:\NCygwin\bin\getent.exe (windows pid 9260) 46 190 [main] getent (9260) OS version: Windows NT-6.1 77 267 [main] getent (9260) ** 119 386 [main] getent (9260) sigprocmask: 0 = sigprocmask (0, 0x0, 0x61293748) 323 709 [main] getent 9260 open_shared: name shared.5, n 5, shared 0x60FF (wanted 0x60FF), h 0x74, *m 6 64 773 [main] getent 9260 user_heap_info::init: heap base 0x8000, heap top 0x8000, heap size 0x1800 (402653184) 103 876 [main] getent 9260 open_shared: name S-1-5-21-435809281-806517502-2525237208-127212.1, n 1, shared 0x60FE (wanted 0x60FE), h 0x70, *m 6 42 918 [main] getent 9260 user_info::create: opening user shared for 'S-1-5-21-435809281-806517502-2525237208-127212' at 0x60FE 22 940 [main] getent 9260 user_info::create: user shared version AB1FCCE8 38 978 [main] getent 9260 fhandler_pipe::create: name \\.\pipe\cygwin-c0a8879476f177eb-9260-sigwait, size 5412, mode PIPE_TYPE_MESSAGE 481026 [main] getent 9260 fhandler_pipe::create: pipe read handle 0x88 191045 [main] getent 9260 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c0a8879476f177eb-9260-sigwait 361081 [main] getent 9260 fhandler_pipe::create: pipe write handle 0x90 231104 [main] getent 9260 dll_crt0_0: finished dll_crt0_0 initialization 9112015 [sig] getent 9260 wait_sig: entering ReadFile loop, my_readsig 0x88, my_sendsig 0x90 742089 [main] getent 9260 time: 1427208969 = time(0x0) 612150 [main] getent 9260 mount_info::conv_to_posix_path: conv_to_posix_path (C:\NCygwin\bin, no-keep-rel, no-add-slash) 322182 [main] getent 9260 normalize_win32_path: C:\NCygwin\bin = normalize_win32_path (C:\NCygwin\bin) 232205 [main] getent 9260 mount_info::conv_to_posix_path: /usr/bin = conv_to_posix_path (C:\NCygwin\bin) 362241 [main] getent 9260 sigprocmask: 0 = sigprocmask (0, 0x0, 0x800180A8) 1772418 [main] getent 9260 _cygwin_istext_for_stdio: fd 0: not open 332451 [main] getent 9260 _cygwin_istext_for_stdio: fd 1: not open 322483 [main] getent 9260 _cygwin_istext_for_stdio: fd 2: not open 1042587 [main] getent (9260) open_shared: name cygpid.9260, n 9260, shared 0x60FD (wanted 0x60FD), h 0xD0, *m 2 252612 [main] ? (9260) time: 1427208969 = time(0x0) 212633 [main] getent 9260 pinfo::thisproc: myself dwProcessId 9260 632696 [main] getent 9260 environ_init: GetEnvironmentStrings returned 0x756E08 342730 [main] getent 9260 environ_init: 0x80028290: !::=::\ 322762 [main] getent 9260 environ_init: 0x800282A0: !C:=C:\NCygwin\bin 302792 [main] getent 9260 environ_init: 0x800282C0: !ExitCode= 312823 [main] getent 9260 environ_init: 0x800282D8: ALLUSERSPROFILE=C:\ProgramData 312854 [main] getent 9260 environ_init: 0x80028300: APPDATA=C:\Users\lemkemch\AppData\Roaming 342888 [main] getent 9260 environ_init: 0x80028330: COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files 332921 [main] getent 9260 environ_init: 0x80028370: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 322953 [main] getent 9260 environ_init: 0x800283B8: CommonProgramW6432=C:\Program Files\Common Files 312984 [main] getent 9260 environ_init: 0x800283F0: COMPUTERNAME=P01104393 323016 [main] getent 9260 environ_init: 0x80028410: COMSPEC=C:\Windows\system32\cmd.exe 333049 [main] getent 9260 parse_options: glob (called func) 313080 [main] getent 9260 parse_options: returning 163096 [main] getent 9260 environ_init: 0x80028440: CYGWIN=noglob 313127 [main] getent 9260 environ_init: 0x80028468: DEFLOGDIR=C:\ProgramData\McAfee\Desktop
Hit fork/rebase issue with new updated gcc 4.9.2-3
I got this error after a recent update which pulled in gcc 4.9.2-3: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address Similar issue was reported in Dec 2013 such as: https://cygwin.com/ml/cygwin/2013-12/msg00083.html After revert to 4.9.2-2 the problem goes away. So I think this is a regression. Thanks, Dumm FK -- 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: update trouble 1.7.35
Habermann, David (D dow.com> writes: > I am able to produce the failure again (by reverting to > cygserver starting immediately as a service upon > bootup). You don't have a setup per chance that doesn't yet have network connectivity when cygserver starts up? Firewall opened only when a user logs in? VPN needs time to establish connection? Is cygserver dependent on the tcpip service? Regards, Achim. -- 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: TIOCPKT mode of PTY is broken if ONLCR bit is cleared.
Hi Takashi, On Mar 23 11:08, Corinna Vinschen wrote: > On Mar 21 10:40, Takashi Yano wrote: > > Hi Corinna, > > > > On Fri, 20 Mar 2015 20:12:32 +0100 > > Corinna Vinschen wrote: > > > > > > For the time being, can you send your assignment as PDF via email > > > > to my company email address just so > > > > we make sure it arrived in *some* way? > > > > > > Even better. We got legal approval that we can use signed PDFs via > > > email alone, and that sending snail mail isn't required anymore. > > > Just sendthe PDF to . > > > > Thank you very much for your effort for approving > > PDF copyright assignment. > > > > I have just sent it via e-mail. > > And it's all set, finally. Thanks a lot for not giving up on us :) Btw., it's not important anymore, but your snail mail arrived finally at the office, after a mere 18 days on travel. Three cheers for the postal services! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSBxGoDuuiZ.pgp Description: PGP signature
RE: update trouble 1.7.35
> What account is cygserver as service running under? Your own, or something > like LocalSystem, or > NetworkService? In my case it is running under SYSTEM.
Re: update trouble 1.7.35
On Mar 24 15:20, Corinna Vinschen wrote: > On Mar 24 14:00, Habermann, David (D) wrote: > > > > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two > > > commands, and paste the output into your reply: > > > > >getent passwd %USERNAME% > > >id > > > > I am able to produce the failure again (by reverting to cygserver > > starting immediately as a service upon bootup). > > What account is cygserver as service running under? Your own, or > something like LocalSystem, or NetworkService? I tried both with no visible effect. It just works for me. Sigh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjt377UxW1t.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 14:00, Habermann, David (D) wrote: > > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two > > commands, and paste the output into your reply: > > >getent passwd %USERNAME% > >id > > I am able to produce the failure again (by reverting to cygserver > starting immediately as a service upon bootup). What account is cygserver as service running under? Your own, or something like LocalSystem, or NetworkService? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqKhJ_PEFLk.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 15:05, Corinna Vinschen wrote: > On Mar 24 14:00, Habermann, David (D) wrote: > > > > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two > > > commands, and paste the output into your reply: > > > > >getent passwd %USERNAME% > > >id > > > > I am able to produce the failure again (by reverting to cygserver > > starting immediately as a service upon bootup). I would be happy to > > provide the information above to a particular person or persons, but > > I'd rather not post it to the internet. If you want it, please let me > > know where to send it. If you don't want you email posted, please > > free to send directly to > > h a b e r m a n n atsymbal dow periadcharacter com > > Guys, please. Just redact the output. Names are irrelevant, just > call them X1, X2, D1, D2, etc. Oh well, ok. If all else fails, send the stuff via gpg-encrypted mail using my public gpg key to my company address vinschen AT redhat DOT com. But only if you promise to send an strace of the getent call as well! Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpF3g05X_YZP.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 14:00, Habermann, David (D) wrote: > > > - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two > > commands, and paste the output into your reply: > > >getent passwd %USERNAME% > >id > > I am able to produce the failure again (by reverting to cygserver > starting immediately as a service upon bootup). I would be happy to > provide the information above to a particular person or persons, but > I'd rather not post it to the internet. If you want it, please let me > know where to send it. If you don't want you email posted, please > free to send directly to > h a b e r m a n n atsymbal dow periadcharacter com Guys, please. Just redact the output. Names are irrelevant, just call them X1, X2, D1, D2, etc. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqxnBHVDf5_.pgp Description: PGP signature
Re: update trouble 1.7.35
On Mar 24 13:28, Steve Johnson wrote: > Hi Corinna, > > I am having the same issue, but from a fresh install of cygwin64. > > I also tried you recommendation, but it did not work. I tried with > just files instead of db as well, with the same results. There are no > passwd or group files in the etc folder, so I don't know if this is > any relevant information either. The problem is this: I can't reproduce this. I need a means to reproduce this to be able to fix it. I'm totally stumped by this weird problem because it seems LookupAccountSid fails and I never saw that before and don't see this on my machines and in my environment. I don't know anything about your environment, for instance. I don't know what you mean when you say "I tried with just files instead", because you didn't say if you also created /etc/passwd and /etc/group files and then stopped all Cygwin processes and opened the shell again. Or, FWIW, when you changed nsswitch.conf to "db" only, if you stopped the processes and started them again, which would be important, per the documentation. Details. I need details. Or ideally somebody with the problem willing to debug the stuff. For a start, the output of cygcheck -svr as outlined in https://cygwin.com/problems.html would be helpful. As well as the output of getent and id as outlined in my other mail. And ideally the strace output generated by strace -o getent.trace getent passwd $USERNAME > I would rather not post the results of the 'id' command publicly, so if > possible, I would gladly provide them if you contact me directly or give me > another mean to provide them. I don't care for the company name. I don't care for the actual group names. Just redact the output and call the (non-well-known) groups X1, X2, etc, and the domain names D1, D2, etc. The posix offset, the gid's and well-known group names (like Users, Domain Admins, etc) don't contain any confidential information so you can simply leave them as is. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpy1m_7Ml7cx.pgp Description: PGP signature
RE: update trouble 1.7.35
> - In a CMD shell, cd to C:\cygwin{64}\bin, call the following two > commands, and paste the output into your reply: >getent passwd %USERNAME% >id I am able to produce the failure again (by reverting to cygserver starting immediately as a service upon bootup). I would be happy to provide the information above to a particular person or persons, but I'd rather not post it to the internet. If you want it, please let me know where to send it. If you don't want you email posted, please free to send directly to h a b e r m a n n atsymbal dow periadcharacter com
Re: update trouble 1.7.35
Hi Corinna, I am having the same issue, but from a fresh install of cygwin64. I also tried you recommendation, but it did not work. I tried with just files instead of db as well, with the same results. There are no passwd or group files in the etc folder, so I don't know if this is any relevant information either. I would rather not post the results of the 'id' command publicly, so if possible, I would gladly provide them if you contact me directly or give me another mean to provide them. Thanks, Steve Johnson -- 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: X11Forward and xauth problems
On 23/03/2015 21:27, Andrew DeFaria wrote: On 3/23/2015 2:06 PM, Jon TURNEY wrote: On 23/03/2015 20:48, Andrew DeFaria wrote: Normally I just turn on -X (or put X11Forward yes in ~/.ssh/config) but that usually results in a noticeable delay in logging in and the following error: Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. Firstly, if you don't want these warnings, use ssh -Y. (By using ssh -X, you are asking for something which the X server can't give you, hence the warnings. See http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trusted-untrusted-x11-forwarding for more details) Yeah but -Y gives me the same thing: This is similar, but it is not the same. Adefaria-lt:ssh -Y cm-app-ldev01 Warning: No xauth data; using fake authentication data for X11 forwarding. /usr/bin/xauth: unable to link authority file /home/adefaria/.Xauthority, use /home/adefaria/.Xauthority-n Cm-app-ldev01: I think this last message here is unusual, and is coming from xauth running on the remote server. Can you you give a few more details on what OS that is running? If you connect using ssh -vv -Y, you should be able to see the xauth commands that sshd is running, and if those, or some other step in the connection, is the cause of the delay. You might also try running those xauth commands in the terminal to investigate further. Adefaria-lt:xhost + access control disabled, clients can connect from any host Adefaria-lt:ssh cm-app-ldev01 Cm-app-ldev01:export DISPLAY=adefaria-lt:0 Cm-app-ldev01:xclock Error: Can't open display: adefaria-lt:0 Cm-app-ldev01: If you want this to work, you will now (since X server 1.17) need to start the server with the option '-listen tcp'. Restarted Xwin with -multimonitor and -listen tcp. Now I get: Sorry for any ambiguity, but you have misunderstood what I wrote. If you want explicitly setting DISPLAY and allowing access using xhost to work, you must start the server with the option '-listen tcp'. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mkpasswd: option to force the 'primary' domain?
On 20/03/15 18:10, Corinna Vinschen wrote: On Mar 20 11:58, Tim Magee wrote: Now then, Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us. Our problem is with the way user names pulled from outside the primary domain get decorated. My question is: will there ever be a way to tell mkpasswd/mkgroup "make the one whose users get undecorated names"? We have Windows machines in one AD domain, and all our users in a different AD domain. According to the 'POSIX accounts, permissions and security' page, the machine's domain is considered the primary one. "mkpasswd -d" will generate undecorated names for that domain, and decorated names for any other named domain. We use SSH-based tools a great deal here, and we use Cygwin to make our Windows machines behave like members of our POSIX machine community, so having our usernames appear the same on all machines is very desirable. I think I can recreate the pre-1.74 behaviour with a little seddery, but I'd bet folding money that my seddery isn't future-proof. So, are mkpasswd/mkgroup ever likely to get an option to force the "undecorated users" domain? I'm not planning this. The idea is that mkpasswd/mkgroup create account names compatible with the "db"-based accounts and everyhing else is left to post-creation manipulation. Having said that, the new account handling is supposed to be stable on the user level for quite some time, ideally at least as many years as the old /etc/passwd&/etc/group-only based code. Therefore using some sed script to filter the output of mkpasswd/mkgroup if you dislike the new account handling is the way to go. Corinna Thanks, I feel more confident of my seddery already! In case anyone else with a similar setup reads this thread: using sed to trim off the domain decoration for the chosen domain is WFMing like a champ, but you'll want to make sure you're not creating name clashes. It's safe for us because we only have users we care about in one domain. Tim -- 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: Altered behaviour of grep
On Mar 24 08:07, Fergus Daly wrote: > grep -Pl "\xmn" > used to find files containing the ASCII character mn. For instance > grep -PL "\x0d" or "\x0a" or usefully "\x00". > This seems to have been lost with the current version. > Is this an error? If not, can anybody tell me what new syntax will recover > the old behaviour? I just tested this on Cygwin and Fedora 21, both with grep 2.21: $ cat x.sh #!/bin/sh echo ${0##*/} $ grep -Pl '\x30' x.sh x.sh $ grep -Pl '\x0a' x.sh $ Same result on both systems, so it finds characters in lines, but not the line separator itself. If that worked before, this looks like an upstream change to me. A bit of digging shows this thread on the bug-grep mailing list: http://lists.gnu.org/archive/html/bug-grep/2015-03/msg00015.html And indeed, if I add a NUL byte to the file and search for it: $ grep -Pl '\x0' x.sh $ grep -aPl '\x0' x.sh x.sh This does not work for the CR or LF, though. You may want to discuss this on the bug-grep ML. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpMy_vdTWdjZ.pgp Description: PGP signature
RE: Altered behaviour of grep
grep -Pl "\xmn" used to find files containing the ASCII character mn. For instance grep -PL "\x0d" or "\x0a" or usefully "\x00". ^ I did mean grep -Pl in both cases. Fergus -- 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
Altered behaviour of grep
grep -Pl "\xmn" used to find files containing the ASCII character mn. For instance grep -PL "\x0d" or "\x0a" or usefully "\x00". This seems to have been lost with the current version. Is this an error? If not, can anybody tell me what new syntax will recover the old behaviour? Thank you. Fergus -- 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