Re: OpenSSH port forwarding bug
On Feb 19 17:18, Karl M wrote: > >>> Subject: Re: OpenSSH port forwarding bug > >>> Date: Wed, 12 Feb 2014 22:44:54 -0500 > >>> > Hi All... > The following example shows the port forwarding problem. > > > ~ > > $ ssh raven -W coyote:22 > getsockname failed: Bad file descriptor > SSH-2.0-OpenSSH_6.5 > Protocol mismatch. > ~ > > $ ssh raven nc coyote 22 > SSH-2.0-OpenSSH_6.5 > Protocol mismatch. > >>> > >>> What are you trying to do? > >>> > >>> > >>> -- > > -- > Hi All... > > So I solved my real problem. It was a typo in my .ssh/config file that > prevented me from being able to use the proxy command in ssh. I've used it > for years. > > But there is still a minor bug in ssh, When I use a proxycommand with ssh > with the -W option, to avoid using an external program such as netcat (nc) > the error message "getsockname failed: Bad file descriptor" is displayed. The > proxycommand works, but displays this error message. Using netcat does not > display this error message. > > The example above is a STC showing the error in a more easily visible way. > The names raven and coyote are local names on my network at home. > > I am wishing the error message into the cornfield. Cygwin's getsockname is called with a file descriptor -1. I tried it on Linux and it occurs with the 6.5p1 version as well so it's a generic problem, still present upstream. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpP722tXJ2li.pgp Description: PGP signature
Re: cygwin make reporting "multiple target patterns" issue
Hi Eddie, On Wed, Feb 19, 2014 at 9:41 PM, Eddie Wang wrote: > Hi Team, > > I can build project OK with "make" command but failed on second build without > running "make clean". Checked with web and noticed that removing previously > create obj directory will resolve the issue. However, this is not the > solution for make command. If only one file is changed, second build should > carry on to recompile this changed file only. This will save a lot of time > for not rebuild everything from scratch. This is almost certainly a make issue and not a Cygwin problem. You are likely to get the same result on any platform if you use GNU make (which is what Cygwin's make is). You didn't tell us what the project is, didn't show the makefile, didn't report the exact error message. This makes it all but impossible to help you any further. I suspect the makefile is composing a list of files dynamically and gets it wrong, but that's just a guess. Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: OpenSSH port forwarding bug
On Feb 20 09:36, Corinna Vinschen wrote: > On Feb 19 17:18, Karl M wrote: > > >>> Subject: Re: OpenSSH port forwarding bug > > >>> Date: Wed, 12 Feb 2014 22:44:54 -0500 > > >>> > > Hi All... > > The following example shows the port forwarding problem. > > > > > > ~ > > > > $ ssh raven -W coyote:22 > > getsockname failed: Bad file descriptor > > SSH-2.0-OpenSSH_6.5 > > Protocol mismatch. > > ~ > > > > $ ssh raven nc coyote 22 > > SSH-2.0-OpenSSH_6.5 > > Protocol mismatch. > > >>> > > >>> What are you trying to do? > > >>> > > >>> > > >>> -- > > > -- > > Hi All... > > > > So I solved my real problem. It was a typo in my .ssh/config file that > > prevented me from being able to use the proxy command in ssh. I've used it > > for years. > > > > But there is still a minor bug in ssh, When I use a proxycommand with ssh > > with the -W option, to avoid using an external program such as netcat (nc) > > the error message "getsockname failed: Bad file descriptor" is displayed. > > The proxycommand works, but displays this error message. Using netcat does > > not display this error message. > > > > The example above is a STC showing the error in a more easily visible way. > > The names raven and coyote are local names on my network at home. > > > > I am wishing the error message into the cornfield. > > Cygwin's getsockname is called with a file descriptor -1. I tried > it on Linux and it occurs with the 6.5p1 version as well so it's a > generic problem, still present upstream. I reported the problem upstream: http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032244.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpogD1h9cF_0.pgp Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 19 21:58, J.H. vd Water wrote: > Hi Corinna, > > >Can you please just test the today's snapshot which should show up > >soon on the http://cygwin.com/snapshots/ page. > > Like Andrey I tested the 19/2 snapshot of today (x86). > > For good measure, I again started afresh ... > > getpwent (db_enum: local) no longer crashes. Splendid! Thanks for testing! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBUNoOoT9wW.pgp Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
Hi Corinna, >> What I meant was: >> >> The output of 'id' in my "regular setup" shows: >> >> @@# id >> uid=1003(Henri) gid=513(None) >> groups=513(None),0(root),544(Administrators),545(Users) >> >> The output of 'id' in the "test setup" shows: >> >> $ id >> uid=1003(Henri) gid=513(None) >> groups=513(None),0(root),545(Users),4(+INTERACTIVE),\ >> 11(+AuthenticatedUsers),4095(CurrentSession),66048(+LOCAL) >> >> To me the second output is different - but perhaps it is not. > >It shows groups which are present in your user token, but which are >not in your /etc/group file. Now that the XP bug is out of the way ... I would like come back to the change in the output of 'id'. Obviously, everything after '545(Users),' in the output of 'id' are "well-known" concepts (Windows) to you (but, not to me) ... ... and I know Cygwin is not Linux/Unix ... But as an Unix adept, I do not really care about the stuff after '545(Users),' in the output of 'id', especially in case of a passwd file and a group file. To me the stuff after '545(Users),' is ... well, superfluous (most certainly, most of the time). Perhaps other users think likewise ... Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 20 12:24, J.H. vd Water wrote: > Hi Corinna, > > >> What I meant was: > >> > >> The output of 'id' in my "regular setup" shows: > >> > >> @@# id > >> uid=1003(Henri) gid=513(None) > >> groups=513(None),0(root),544(Administrators),545(Users) > >> > >> The output of 'id' in the "test setup" shows: > >> > >> $ id > >> uid=1003(Henri) gid=513(None) > >> groups=513(None),0(root),545(Users),4(+INTERACTIVE),\ > >> 11(+AuthenticatedUsers),4095(CurrentSession),66048(+LOCAL) > >> > >> To me the second output is different - but perhaps it is not. > > > >It shows groups which are present in your user token, but which are > >not in your /etc/group file. > > Now that the XP bug is out of the way ... I would like come back to the > change in > the output of 'id'. > > Obviously, everything after '545(Users),' in the output of 'id' are > "well-known" > concepts (Windows) to you (but, not to me) ... I explained that in my mail and I already wrote http://cygwin.com/cygwin-ug-net/ntsec.html at one point. There are also links on the MSDN web site which explain how it works. The group concept in Windows isn't much different from the group concept in Unix, except that Windows applications don't really care for the owning group of objects, typically. > ... and I know Cygwin is not Linux/Unix ... We're striving for similarity... > But as an Unix adept, I do not really care about the stuff after > '545(Users),' in > the output of 'id', especially in case of a passwd file and a group file. > > To me the stuff after '545(Users),' is ... well, superfluous (most certainly, > most > of the time). > > Perhaps other users think likewise ... I don't know about you, but on my Linux box I get something like this: $ id uid=500(corinna) gid=11125(vinschen) groups=11125(vinschen),33(tape), 100(users),107(qemu),486(wireshark),1000(cvs),11126(libvirt) Most of the time I don't care about the supplementary groups after my primary group either, but that doesn't mean I don't want id to print them, nor are they unimportant. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNNS3IQvbw5.pgp Description: PGP signature
Re: Bug with dlopen() and fork()
Hello Corinna,
As you've checked, this behaviour doesn't appear with dll's created by
gcc, but it does with Visual Studio C++.
That minimal example compiled with VS will result in the freeze of the
child process.
testlib.h ==
#ifdef TESTLIB_EXPORTS
#define TEST_API extern "C" __declspec(dllexport)
#else
#define TEST_API extern "C" __declspec(dllimport)
#endif
TEST_API int mylib_open (const char *foo);
=
=== testlib.cpp ==
#include "stdafx.h"
#include "testLib.h"
int
mylib_open (const char *foo)
{
return 1;
}
==
I've tested several compiler and linker options with same result.
Any ideas?
> On Feb 19 14:38, Jaime Fabregas Fernandez wrote:
>> Library references loaded by a process using dlopen() and dlsym() are
>> no more valid in child processes after running a fork(). Calls from
>> child process will never return.
>>
>> I've searched for a similar problem in the mailing lists and found
>> this unanswered thread from 2001:
>>
>> http://cygwin.com/ml/cygwin/2001-02/msg01225.html
>>
>>
>> I'm running cygwin64. This behaviour can be checked with the following
>> test program:
>>
>>
>> #include
>> #include
>>
>> int (*myopen)(const char *);
>>
>> main(){
>> void *handle;
>> int ret;
>> handle = dlopen("my_lib.dll", RTLD_LAZY);
>> myopen = dlsym(handle, "mylib_open");
>>
>> if( ! fork() ){
>> ret = myopen("");
>> printf("This printf never shows, call to myopen will
>> block for ever\n");
>> }
>> else{
>> ret = myopen("");
>> printf("%i\n", ret);
>> sleep(1);
>> }
>> }
>>
>>
>> Same program runs correctly (showing the two printf's) in a Linux
>> environment.
>
> Works for me with 64 bit Cygwin. I used this as DLL:
>
> $ cat > my_lib.c < int
> mylib_open (const char *foo)
> {
> return 1;
> }
> $ gcc -shared -o my_lib.dll my_lib.c
> $ gcc -g -o my_tst my_tst.c <- That's your above testcase
> $ uname -a
> CYGWIN_NT-6.3 vmbert8164 1.7.28(0.271/5/3) 2014-02-04 16:01 x86_64 Cygwin
> $ ./my_tst
> 1
> This printf never shows, call to myopen will block for ever
> $
>
>
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Maintainer cygwin AT cygwin DOT com
> Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Setup Path
Hi all Really new to Cygwin. Is there a way to setup Cygwin so when I got to terminal to type a command I don't have to enter the complete path as shown here: $ cd /cygdrive/c/directory name Anyway to setup to where I might just enter $ c/directory name or something like it? Thanks -- Todd Poole -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
Hi Corinna, >> Now that the XP bug is out of the way ... I would like come back to the >> change in >> the output of 'id'. >> >> Obviously, everything after '545(Users),' in the output of 'id' are >> "well-known" >> concepts (Windows) to you (but, not to me) ... > >I explained that in my mail and I already wrote >http://cygwin.com/cygwin-ug-net/ntsec.html at one point. [snip] Yes, yes, yes :-) I have read all that a long time ago ... >The group concept in Windows isn't much different from the group concept in >Unix, > except that Windows applications don't really care for the owning group of > objects, > typically. Agreed. [snip] >> But as an Unix adept, I do not really care about the stuff after >> '545(Users),' in >> the output of 'id', especially in case of a passwd file and a group file. >> >> To me the stuff after '545(Users),' is ... well, superfluous (most >> certainly, most >> of the time). >I don't know about you, but on my Linux box I get something like this: > > $ id > uid=500(corinna) gid=11125(vinschen) groups=11125(vinschen),33(tape), > 100(users),107(qemu),486(wireshark),1000(cvs),11126(libvirt) > >Most of the time I don't care about the supplementary groups after my >primary group either, but that doesn't mean I don't want id to print >them, nor are they unimportant. Agreed, the supplementary groups I observe on Unix are relevant to me ... I know that out of experience. The difference is, that all supplementary groups show up in the /etc/group file on my Unix box ... However, as you know, the supplementary group to which I referred above do NOT show up in my /etc/group file on Cygwin (they show up in SAM ... somewhere). ... and I do not care, as these groups are NOT relevant to me as a Cygwin-only user of the Windows operating system (using passwd and group files). Sorry, for having a different opinion on the matter. Henri -- 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: Setup Path
From: Todd Poole > Hi all > Really new to Cygwin. Is there a way to setup Cygwin so when I got to > terminal to type a command I don't have to enter the complete path as > shown here: > > $ cd /cygdrive/c/directory name > > Anyway to setup to where I might just enter > > $ c/directory name > > or something like it? I suggest you look into the CDPATH environment variable. --Ken Nellis -- 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: $PATH contains dot but unclear where it comes from
Thanks to all who helped so far! On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote: > So far, I'm not convinced that issue is Cygwin-specific. The fact that it > doesn't manifest in Windows is actually because of it's (windows) native > ignorance for this matter. I sent a lengthy email with all the detailed shell outputs earlier but it was blocked by spam filter. :-( I'll try an executive summary, also because I don't have that much time right now. C:\Users\rklemme>C:\cygwin64\bin\bash.exe --norc --noprofile -li bash-4.1$ echo "$PATH" /cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES /COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/ Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/ c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86: /cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel /WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/ c/Users/rklemme/Applications/SysinternalsSuite:. bash-4.1$ You notice the "." at the end. C:\Users\rklemme>C:\cygwin64\bin\sh.exe --norc --noprofile -li sh-4.1$ echo "$PATH" /cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES /COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/ Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/ c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86: /cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel /WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/ c/Users/rklemme/Applications/SysinternalsSuite No dot at the end. Same for output of "env" without arguments invoked from Windows prompt. The dot is also not there in the windows path. My summary so far 1. There is nothing in the Windows PATH (neither system, nor user, nor what's combined at the prompt) that looks like a cause for dot (i.e. empty path). 1. not all cygwin programs show the dot at the end of $PATH 2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe C:\Users\rklemme>C:\cygwin64\bin\bash.exe --version GNU bash, version 4.1.11(2)-release (x86_64-unknown-cygwin) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 20 14:28, J.H. vd Water wrote: > >I don't know about you, but on my Linux box I get something like this: > > > > $ id > > uid=500(corinna) gid=11125(vinschen) groups=11125(vinschen),33(tape), > > 100(users),107(qemu),486(wireshark),1000(cvs),11126(libvirt) > > > >Most of the time I don't care about the supplementary groups after my > >primary group either, but that doesn't mean I don't want id to print > >them, nor are they unimportant. > > Agreed, the supplementary groups I observe on Unix are relevant to me ... I > know > that out of experience. > > The difference is, that all supplementary groups show up in the /etc/group > file on > my Unix box ... That's because you're using the files option exclusively on your Unix box. > However, as you know, the supplementary group to which I referred above do > NOT show > up in my /etc/group file on Cygwin (they show up in SAM ... somewhere). > > ... and I do not care, as these groups are NOT relevant to me as a > Cygwin-only user > of the Windows operating system (using passwd and group files). If you only want to use the content of your passwd and group files, rather than the db (which is pretty much upside down from what this patch is trying to accomplish, but, anyway), simply change your /etc/nsswitch.conf file accordingly. Just as on Linux. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDkDQbhnD6q.pgp Description: PGP signature
Re: Bug with dlopen() and fork()
On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
> Hello Corinna,
>
> As you've checked, this behaviour doesn't appear with dll's created by
> gcc, but it does with Visual Studio C++.
> That minimal example compiled with VS will result in the freeze of the
> child process.
>
> testlib.h ==
> #ifdef TESTLIB_EXPORTS
> #define TEST_API extern "C" __declspec(dllexport)
> #else
> #define TEST_API extern "C" __declspec(dllimport)
> #endif
>
> TEST_API int mylib_open (const char *foo);
> =
>
> === testlib.cpp ==
> #include "stdafx.h"
> #include "testLib.h"
>
> int
> mylib_open (const char *foo)
> {
> return 1;
> }
> ==
>
> I've tested several compiler and linker options with same result.
>
> Any ideas?
Using MS DLLs across fork in this way is unsupported. If you get it
working, you're just lucky.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpB7XJEWKhxD.pgp
Description: PGP signature
Re: Setup Path
On 2/20/2014 8:34 AM, Nellis, Kenneth wrote:
From: Todd Poole
Hi all
Really new to Cygwin. Is there a way to setup Cygwin so when I got to
terminal to type a command I don't have to enter the complete path as
shown here:
$ cd /cygdrive/c/directory name
Anyway to setup to where I might just enter
$ c/directory name
or something like it?
I suggest you look into the CDPATH environment variable.
That would simplify what you type as an argument to the cd command.
If you are wanting to be able to invoke a command foo without typing
its whole path, then you need its directory in the PATH variable.
PATH in cygwin is similar to PATH on Windows, but the format is
more like Unix: / instead of \, : instead of ;, and so on. The
command:
echo $PATH
will show you the default. You can add a directory to be searched
after the default ones by doing something like:
PATH="${PATH}:additional-directory"
The quotes are important if anything in PATH has spaces or other "strange"
characters.
By the way, this is standard Unix / bash stuff. cygwin kind of assumes that you
are familiar with Unix, since its purpose is to offer a Unix-like environment
on Windows. (bash, the Bourne-again shell, is the default shell brought up in
a cygwin terminal window.)
Best wishes -- Eliot Moss
--
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: $PATH contains dot but unclear where it comes from
On 2/20/2014 9:12 AM, Robert Klemme wrote: Thanks to all who helped so far! On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote: So far, I'm not convinced that issue is Cygwin-specific. The fact that it doesn't manifest in Windows is actually because of it's (windows) native ignorance for this matter. I sent a lengthy email with all the detailed shell outputs earlier but it was blocked by spam filter. :-( I'll try an executive summary, also because I don't have that much time right now. C:\Users\rklemme>C:\cygwin64\bin\bash.exe --norc --noprofile -li bash-4.1$ echo "$PATH" /cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES /COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/ Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/ c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86: /cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel /WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/ c/Users/rklemme/Applications/SysinternalsSuite:. bash-4.1$ You notice the "." at the end. C:\Users\rklemme>C:\cygwin64\bin\sh.exe --norc --noprofile -li sh-4.1$ echo "$PATH" /cygdrive/c/PROGRAM FILES (X86)/NVIDIA CORPORATION/PHYSX/COMMON:/cygdrive/c/PROG RAM FILES (X86)/INTEL/ICLS CLIENT:/cygdrive/c/PROGRAM FILES/INTEL/ICLS CLIENT:/c ygdrive/c/PROGRAM FILES (X86)/RSA SECURID TOKEN COMMON:/cygdrive/c/PROGRAM FILES /COMMON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/PROGRAM FILES (X86)/COMM ON FILES/MICROSOFT SHARED/WINDOWS LIVE:/cygdrive/c/Windows/SYSTEM32:/cygdrive/c/ Windows:/cygdrive/c/Windows/SYSTEM32/WBEM:/cygdrive/c/Windows/SYSTEM32/WINDOWSPO WERSHELL/V1.0:/cygdrive/c/PROGRAM FILES/DELL/DELL DATA PROTECTION/ACCESS/ADVANCE D/WAVE/GEMALTO/ACCESS CLIENT/V5:/cygdrive/c/PROGRAM FILES (X86)/NTRU CRYPTOSYSTE MS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES/NTRU CRYPTOSYSTEMS/NTRU TCG SOFTWARE STACK/BIN:/cygdrive/c/PROGRAM FILES (X86)/WINDOWS LIVE/SHARED:/cyg drive/c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/ c/PROGRAM FILES/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/DAL:/cygdrive/c/PROG RAM FILES (X86)/INTEL/INTEL(R) MANAGEMENT ENGINE COMPONENTS/IPT:/cygdrive/c/Prog ram Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x86: /cygdrive/c/Program Files (x86)/Intel/OpenCL SDK/2.0/bin/x64:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files (x86) /Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/Intel /WiFi/bin:/cygdrive/c/Program Files/Common Files/Intel/WirelessCommon:/cygdrive/ c/Users/rklemme/Applications/SysinternalsSuite No dot at the end. Same for output of "env" without arguments invoked from Windows prompt. The dot is also not there in the windows path. My summary so far 1. There is nothing in the Windows PATH (neither system, nor user, nor what's combined at the prompt) that looks like a cause for dot (i.e. empty path). Your cygcheck output contradicts this statement. The last path in the list of Windows paths is ".". -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top postin
Re: Setup Path
Thank you very much for information. I think I can get it now.
Todd Poole
On 2/20/2014 10:01 AM, Eliot Moss wrote:
On 2/20/2014 8:34 AM, Nellis, Kenneth wrote:
From: Todd Poole
Hi all
Really new to Cygwin. Is there a way to setup Cygwin so when I got to
terminal to type a command I don't have to enter the complete path as
shown here:
$ cd /cygdrive/c/directory name
Anyway to setup to where I might just enter
$ c/directory name
or something like it?
I suggest you look into the CDPATH environment variable.
That would simplify what you type as an argument to the cd command.
If you are wanting to be able to invoke a command foo without typing
its whole path, then you need its directory in the PATH variable.
PATH in cygwin is similar to PATH on Windows, but the format is
more like Unix: / instead of \, : instead of ;, and so on. The
command:
echo $PATH
will show you the default. You can add a directory to be searched
after the default ones by doing something like:
PATH="${PATH}:additional-directory"
The quotes are important if anything in PATH has spaces or other "strange"
characters.
By the way, this is standard Unix / bash stuff. cygwin kind of assumes
that you
are familiar with Unix, since its purpose is to offer a Unix-like
environment
on Windows. (bash, the Bourne-again shell, is the default shell brought
up in
a cygwin terminal window.)
Best wishes -- Eliot Moss
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: $PATH contains dot but unclear where it comes from
On Thu, Feb 20, 2014 at 03:12:47PM +0100, Robert Klemme wrote: >Thanks to all who helped so far! > >On Wed, Feb 19, 2014 at 11:23 PM, Andrey Repin wrote: > >> So far, I'm not convinced that issue is Cygwin-specific. The fact that it >> doesn't manifest in Windows is actually because of it's (windows) native >> ignorance for this matter. > >I sent a lengthy email with all the detailed shell outputs earlier but >it was blocked by spam filter. :-( i.e., DONT_USE_RAW_EMAIL_IN_BODY UNWANTED_LANGUAGE_BODY ZIP_ATTACHED The "ZIP_ATTACHED" was enough to cause it to be interpreted as spam but the "raw email" block made it even more blockable. But, of course, the cygwin mailing list is not the place to complain about being blocked. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug with dlopen() and fork()
On Thu, Feb 20, 2014 at 03:57:27PM +0100, Corinna Vinschen wrote:
>On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
>> Hello Corinna,
>>
>> As you've checked, this behaviour doesn't appear with dll's created by
>> gcc, but it does with Visual Studio C++.
>> That minimal example compiled with VS will result in the freeze of the
>> child process.
>>
>> testlib.h ==
>> #ifdef TESTLIB_EXPORTS
>> #define TEST_API extern "C" __declspec(dllexport)
>> #else
>> #define TEST_API extern "C" __declspec(dllimport)
>> #endif
>>
>> TEST_API int mylib_open (const char *foo);
>> =
>>
>> === testlib.cpp ==
>> #include "stdafx.h"
>> #include "testLib.h"
>>
>> int
>> mylib_open (const char *foo)
>> {
>> return 1;
>> }
>> ==
>>
>> I've tested several compiler and linker options with same result.
>>
>> Any ideas?
>
>Using MS DLLs across fork in this way is unsupported. If you get it
>working, you're just lucky.
Too bad. We >just< missed the Thursday window.
cgf
--
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
Creating a binary install package when target python version is unknown
I was looking to create a binary install package for newt, however it looks like the binary installs are extracted to root. If I have python2.7 installed, there are different binaries and install locations (and bootstrap .py) than python3, for example. Does this mean I have to install all combinations? Or is there some special way to do this that I am missing? When I make it from source, the makefile will detect which versions of python are installed and compile appropriately. Also, how do I know which versions of python I should be building for? As an example, here are the files that would be installed for python2.7: ./usr/lib/python2.7/site-packages/snack.py ./usr/lib/python2.7/site-packages/_snack.py ./usr/lib/python2.7/site-packages/_snackmodule.so and python3 would have its own set. How is this usually handled? Thanks! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: $PATH contains dot but unclear where it comes from
On 2/20/2014 9:12 AM, Robert Klemme wrote: 2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe This fact should enable you to track down the problem. The bash manual explains how it behaves differently when invoked as sh.exe. I don't remember the details, but I think one difference is that different startup files are read. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 19 23:57, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> [1] http://linux.die.net/man/1/getent > > > That sounds pretty much like the tool we need to be able to get rid of > > the `grep /etc/passwd' stuff we have in some of the service configuration > > helper scripts. Unfortunately it's a glibc tool so we probably have to > > create our own. > > > For a start it would suffice to support only passwd and group databases. > > Yup, was exactly what I thought. Just FYI, I succeeded in porting the Glibc getent. I will provide this as a standalone package ASAP, so we can start converting the service configuration helper scripts even before we release the new passwd/group code. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNgoXfN1Erx.pgp Description: PGP signature
Re: $PATH contains dot but unclear where it comes from
On 2/20/2014 10:41 AM, Ken Brown wrote: On 2/20/2014 9:12 AM, Robert Klemme wrote: 2. only bash invoked as bash shows it - it's not shown when invoked as sh.exe This fact should enable you to track down the problem. The bash manual explains how it behaves differently when invoked as sh.exe. I don't remember the details, but I think one difference is that different startup files are read. The OP's use of --noprofile and --norc suppress most of those differences. One little thing I noticed has to do with "posix mode". sh enters posix mode only after trying to source input files, while bash is in posix mode all the time. One difference when not in posix mode is that sourcing of files will search the currently directory. It seems a little far-fetched that this would affect the setting of PATH, but at the same time, it is all related to whether the current directory is searched or not ... Regards -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug with dlopen() and fork()
On Feb 20 10:38, Christopher Faylor wrote:
> On Thu, Feb 20, 2014 at 03:57:27PM +0100, Corinna Vinschen wrote:
> >On Feb 20 14:16, Jaime Fabregas Fernandez wrote:
> >> Hello Corinna,
> >>
> >> As you've checked, this behaviour doesn't appear with dll's created by
> >> gcc, but it does with Visual Studio C++.
> >> That minimal example compiled with VS will result in the freeze of the
> >> child process.
> >>
> >> testlib.h ==
> >> #ifdef TESTLIB_EXPORTS
> >> #define TEST_API extern "C" __declspec(dllexport)
> >> #else
> >> #define TEST_API extern "C" __declspec(dllimport)
> >> #endif
> >>
> >> TEST_API int mylib_open (const char *foo);
> >> =
> >>
> >> === testlib.cpp ==
> >> #include "stdafx.h"
> >> #include "testLib.h"
> >>
> >> int
> >> mylib_open (const char *foo)
> >> {
> >> return 1;
> >> }
> >> ==
> >>
> >> I've tested several compiler and linker options with same result.
> >>
> >> Any ideas?
> >
> >Using MS DLLs across fork in this way is unsupported. If you get it
> >working, you're just lucky.
>
> Too bad. We >just< missed the Thursday window.
Indeed. But http://cygwin.com/acronyms/#PTC still applies, if this is
possible at all with Visual Studio DLLs, I think.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpfFQNN8tXsO.pgp
Description: PGP signature
Re: Testers needed: New passwd/group handling in Cygwin
Greetings, Corinna Vinschen! >> >> [1] http://linux.die.net/man/1/getent >> >> > That sounds pretty much like the tool we need to be able to get rid of >> > the `grep /etc/passwd' stuff we have in some of the service configuration >> > helper scripts. Unfortunately it's a glibc tool so we probably have to >> > create our own. >> >> > For a start it would suffice to support only passwd and group databases. >> >> Yup, was exactly what I thought. > Just FYI, I succeeded in porting the Glibc getent. I will provide this > as a standalone package ASAP, so we can start converting the service > configuration helper scripts even before we release the new passwd/group > code. O.o thursday of miracles. -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <21:13> 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: Setup Path
Greetings, Todd Poole! > Really new to Cygwin. Is there a way to setup Cygwin so when I got to > terminal to type a command I don't have to enter the complete path as > shown here: > $ cd /cygdrive/c/directory name > Anyway to setup to where I might just enter > $ c/directory name > or something like it? There's a small improvement you can apply in regard to paths length. Check the /etc/fstab file, duplicate the last line, uncomment it and amend to none/ cygdrivebinary,posix=0,noacl0 0 Then you will be able to use just "/c" instead of "/cygdrive/c" -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <21:25> 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: Setup Path
Excellent, that's what I was looking for. Thanks for the help. Todd Poole On 2/20/2014 12:30 PM, Andrey Repin wrote: Greetings, Todd Poole! Really new to Cygwin. Is there a way to setup Cygwin so when I got to terminal to type a command I don't have to enter the complete path as shown here: $ cd /cygdrive/c/directory name Anyway to setup to where I might just enter $ c/directory name or something like it? There's a small improvement you can apply in regard to paths length. Check the /etc/fstab file, duplicate the last line, uncomment it and amend to none/ cygdrivebinary,posix=0,noacl0 0 Then you will be able to use just "/c" instead of "/cygdrive/c" -- WBR, Andrey Repin (anrdae...@yandex.ru) 20.02.2014, <21:25> 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 -- 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: Need general snapshot testers
On Wed, Feb 19, 2014 at 03:52:37PM +0100, Bengt Larsson wrote: >Christopher Faylor wrote: >>On Wed, Feb 19, 2014 at 12:52:58PM +0100, Bengt Larsson wrote: >>>I start a console window, set the buffer to 1100 lines, display a lot in >>>it. Start bash, type ^L: the console window resizes to be only one line. >>>Same result if bash was started first, then display data, then ^L. >> >>Huh. That's a bad bug. Thanks for reporting. That's not something we'd >>want to see in a release. >> >>What Windows version are you running? > >Windows 7. I forgot to mention that I managed to duplicate this problem and am working on a fix for this and the other screen garbling seen in recent snapshots. Thanks again for testing/reporting. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
Hi Corinna, >> However, as you know, the supplementary group to which I referred above do >> NOT show >> up in my /etc/group file on Cygwin (they show up in SAM ... somewhere). >> >> ... and I do not care, as these groups are NOT relevant to me as a >> Cygwin-only user >> of the Windows operating system (using passwd and group files). > >If you only want to use the content of your passwd and group files, >rather than the db (which is pretty much upside down from what this >patch is trying to accomplish, but, anyway), simply change your >/etc/nsswitch.conf file accordingly. Just as on Linux. :-) My /etc/nsswitch.conf file ALREADY specifies 'db_enum: files'. However, as you probably aware of, the output of 'id' _still_ shows all the (non-file ;-) supplementary groups I do not care about ... That is what I tried to make clear with my message. No more. Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Testers needed: New passwd/group handling in Cygwin
On Feb 20 19:58, J.H. vd Water wrote: > Hi Corinna, > > >> However, as you know, the supplementary group to which I referred above do > >> NOT show > >> up in my /etc/group file on Cygwin (they show up in SAM ... somewhere). > >> > >> ... and I do not care, as these groups are NOT relevant to me as a > >> Cygwin-only user > >> of the Windows operating system (using passwd and group files). > > > >If you only want to use the content of your passwd and group files, > >rather than the db (which is pretty much upside down from what this > >patch is trying to accomplish, but, anyway), simply change your > >/etc/nsswitch.conf file accordingly. Just as on Linux. > > :-) My /etc/nsswitch.conf file ALREADY specifies 'db_enum: files'. > > However, as you probably aware of, the output of 'id' _still_ shows all > the (non-file ;-) supplementary groups I do not care about ... > > That is what I tried to make clear with my message. No more. Try passwd: files group: files The output of `id' has nothing to do with the getpwent/getgrent functionality db_enum is about. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgphYJbQDPzRr.pgp Description: PGP signature
[ANNOUNCEMENT] New package: getent-2.18.90-1
Hi folks, I just uploaded the new getent package to the 32 and 64 bit distros. getent is a Glibc tool which allows to fetch host, passwd, group, protocol, and service information via a simple tool. = IMPORTANT (not only) FOR CYGWIN PACKAGE MAINTAINERS = The most important aspect for Cygwin for the near future is this: With the new passwd/group code just in testing (see http://cygwin.com/ml/cygwin/2014-02/msg00306.html for lots and lots of information), tools and scripts must not rely anymore on being able to grep user and group information from /etc/passwd and /etc/group! The new way to read passwd and group information from, for instance, service installation helper scripts, is to use the getent tool for this purpose. I'd like to urge all maintainers which provide such scripts to look into their packages and fix them to use the getent tool, rather than grep'ing /etc/passwd and /etc/group directly. = Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Need general snapshot testers
> I forgot to mention that I managed to duplicate this problem and am working > on a fix for this and the other screen garbling seen in recent snapshots. Hm, with luck maybe that will also fix the recent garbled screen problem in screen(1): http://cygwin.com/ml/cygwin/2014-01/msg00223.html http://cygwin.com/ml/cygwin/2014-01/msg00300.html -- 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: Need general snapshot testers
On Thu, Feb 20, 2014 at 02:30:50PM -0500, Andrew Schulman wrote: >> I forgot to mention that I managed to duplicate this problem and am working >> on a fix for this and the other screen garbling seen in recent snapshots. > >Hm, with luck maybe that will also fix the recent garbled screen problem in >screen(1): Nope. cgf -- 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: setup: how to select all src packages too?
On 02/18/2014 08:26 PM, Andrey Repin wrote: Greetings, Luke Kendall! It's great that Cygwin has so many packages. And setup.exe makes it easy to select the packages you want. But it seems quite difficult to also select all the corresponding source packages as well, simply because there are so many packages! In the worst case, where you want every package, and all the source packages too, surely you don't have to scroll and click 3,000-odd times in the UI to select them all? But I haven't found a way to do it through setup. Sorry if this is a dumb question. I have searched, but couldn't find an answer. This is a known deficiency of a Cygwin setup. However, how many source packages you ACTUALLY, REALLY need to download? -- WBR, Andrey Repin (anrdae...@yandex.ru) 18.02.2014, <13:24> Sorry for my terrible english... I imagine others have suggested that the UI for the missing functionality could be as simple as a checkbox to include source package for all packages selected. We actually, really needed to download all the source packages, because we need to be able to check the licenses, and the licenses can often only be found by looking in the source packages. We worked around the problem by rsync-ing the whole thing, in the end. Thanks for confirming that it wasn't a dumb question, Andrey! Regards, luke -- 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: Maintainer for git?
On Sat, Feb 15, 2014 at 10:14:25AM +, Adam Dinwoodie wrote: > On Sat, Feb 15, 2014 at 09:11:44AM +0100, Alexander Kriegisch wrote: > > I am wondering if this version will ever make it into the official > > distribution and be auto-updated when I run setup*.exe. Is there any > > progress? Just wondering, not demanding anything... > > As the (hopefully) incoming maintaner: yes, I'm very much hoping this > will become the version provided by the setup*.exes. There are still a > few checks I want to run in the name of being sure I'm not making > anything worse, and some other details to iron out, but I am making > progress. > > If you (or anyone else) wants to help speed things along, there're a few > tests you can do; I'm planning on doing these but if someone else can > it'll save me the time: > > - Install git-cvs and the assorted dependencies mentioned in its > setup.hint, and verify you can clone the Cygwin CVS repository. I've > not managed to do this without hitting errors, but I suspect that's > because I'm using the tool incorrectly. I've tried this. I have `git cvsimport` seemingly working on the current Git 1.7.9 build, while my build reports the following SHA1 error: $ CVSROOT=:pserver:anon...@cygwin.com:/cvs/src git cvsimport -C cygwin -r cvs -k cygwin Initialized empty Git repository in /home/Adam/vcs/cygwin/.git/ fatal: refs/remotes/cvs/master: not a valid SHA1 fatal: master: not a valid SHA1 fatal: You are on a branch yet to be born checkout failed: 32768 That's a showstopper, currently, and it'll probably take a little while to work out where it's going wrong, since I have very little familiarity with Git's internals. I am working on it, but I don't have an ETA at present. (Of course, if anyone fancies helping out, or having a wonderful revelation akin to Corinna's earlier OpenSSL one, that would be exceedingly useful right now.) > - Install minimal packages (Base + the dependencies listed in the > setup.hint files) and check that the basic functionality works. I've done this, and everything seems to be fine there, at least for the exceedingly basic tests I've done. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: chere-1.4-1 (x86 and x86_64)
Version 1.4-1 of "chere" has been uploaded and should be available from mirrors shortly. chere is a script allowing you to add Explorer context menus to start cygwin in the selected directory. This script supports x86 and x86_64 simultaneously. If you have 32 and 64 bit cygwin installed on the same machine, you can add separate context menu entries to start 32 or 64 bit terminals. The default menu text does not differentiate between 32 and 64 bit, so if you do this you should use the -e option. Changes: * Use getent to identify the user login shell when the shell is unspecified or set as passwd * Support fish shell Fixes: * Allow cd'ing to directories containing single quotes when using registry one-liners (-1) *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup: how to select all src packages too?
On 2/20/2014 5:50 PM, Luke Kendall wrote: On 02/18/2014 08:26 PM, Andrey Repin wrote: Greetings, Luke Kendall! It's great that Cygwin has so many packages. And setup.exe makes it easy to select the packages you want. But it seems quite difficult to also select all the corresponding source packages as well, simply because there are so many packages! In the worst case, where you want every package, and all the source packages too, surely you don't have to scroll and click 3,000-odd times in the UI to select them all? But I haven't found a way to do it through setup. Sorry if this is a dumb question. I have searched, but couldn't find an answer. This is a known deficiency of a Cygwin setup. However, how many source packages you ACTUALLY, REALLY need to download? -- WBR, Andrey Repin (anrdae...@yandex.ru) 18.02.2014, <13:24> Sorry for my terrible english... I imagine others have suggested that the UI for the missing functionality could be as simple as a checkbox to include source package for all packages selected. We actually, really needed to download all the source packages, because we need to be able to check the licenses, and the licenses can often only be found by looking in the source packages. We worked around the problem by rsync-ing the whole thing, in the end. Thanks for confirming that it wasn't a dumb question, Andrey! Well, he didn't exactly say it wasn't a dumb question. ;-) Just kidding! Mirroring is actually a good way to grab all the source with relative ease, given setup's mechanism is much more laborious. And while neither way is optimal, I think you get points for finding the path of lesser pain. :-) -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
[octave 3.8.0] font missig in fltk graph
Hello I have installed Cygwin-67 on windows 7 64 bit to use octave. So far everything is fine on gnuplot graphics_tool kit. However, on fltk graphics_toolkit, fonts on the graph were not represent. For example, http://www.geocities.co.jp/tmoctwin/files/fltk20140221.html Any suggestions? Regards Tatsuro -- 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: setup: how to select all src packages too?
Greetings, Luke Kendall! >>> It's great that Cygwin has so many packages. And setup.exe makes it >>> easy to select the packages you want. >>> But it seems quite difficult to also select all the corresponding source >>> packages as well, simply because there are so many packages! In the >>> worst case, where you want every package, and all the source packages >>> too, surely you don't have to scroll and click 3,000-odd times in the UI >>> to select them all? But I haven't found a way to do it through setup. >>> Sorry if this is a dumb question. I have searched, but couldn't find an >>> answer. >> This is a known deficiency of a Cygwin setup. >> However, how many source packages you ACTUALLY, REALLY need to download? > I imagine others have suggested that the UI for the missing > functionality could be as simple as a checkbox to include source package > for all packages selected. > We actually, really needed to download all the source packages, because > we need to be able to check the licenses, and the licenses can often > only be found by looking in the source packages. > We worked around the problem by rsync-ing the whole thing, in the end. > Thanks for confirming that it wasn't a dumb question, Andrey! Well, since you need _every_ thing, mirroring was, perhaps, the easiest way of doing it. -- WBR, Andrey Repin (anrdae...@yandex.ru) 21.02.2014, <10:48> 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: Testers needed: New passwd/group handling in Cygwin
Hi Corinna, >> >If you only want to use the content of your passwd and group files, >> >rather than the db (which is pretty much upside down from what this >> >patch is trying to accomplish, but, anyway), simply change your >> >/etc/nsswitch.conf file accordingly. Just as on Linux. >> >> :-) My /etc/nsswitch.conf file ALREADY specifies 'db_enum: files'. >> >> However, as you probably aware of, the output of 'id' _still_ shows all >> the (non-file ;-) supplementary groups I do not care about ... >> >> That is what I tried to make clear with my message. Nothing more. > >Try > > passwd: files > group: files > >The output of `id' has nothing to do with the getpwent/getgrent >functionality db_enum is about. Sorry, sorry, sorry (yes, I tried). How stupid of me. Thank you, thank you! Apparently, I must learn how to read ... (shame on me!). Thanks again, Henri -- 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: Need general snapshot testers
Am 20.02.2014 02:26, schrieb Andrey Repin: Greetings, Thomas Wolff! Not specific to this snapshot but it happens when trying to test it: If a cygwin console is started from a cygwin terminal (e.g. in mintty: cygstart /Cygwin.bat), the TERM variable is set incorrectly. Suggested fix: ... unset TERM to Cygwin.bat. unset would be better (more neutral) choice in a long-term, IMO. Actually, unset doesn't exist in cmd (blush). It should be "set TERM=" then. However you spell it :) Using same assignment in shell would have nearly equal results. Having something like case `tty` in /dev/cons*) TERM=cygwin;; esac in /etc/profile would be a clumsy workaround and possibly have tricky glitches. My proposal catches the issue at its root in the simplest way. I would provide a patch (if needed) if I had an idea in which package Cygwin.bat is hiding;-) -- Thomas --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Need general snapshot testers
Greetings, Thomas Wolff! > Not specific to this snapshot but it happens when trying to test it: > If a cygwin console is started from a cygwin terminal (e.g. in mintty: > cygstart /Cygwin.bat), the TERM variable is set incorrectly. > Suggested fix: ... unset TERM to Cygwin.bat. unset would be better (more neutral) choice in a long-term, IMO. >>> Actually, unset doesn't exist in cmd (blush). >>> It should be "set TERM=" then. >> However you spell it :) >> Using same assignment in shell would have nearly equal results. > Having something like case `tty` in /dev/cons*) TERM=cygwin;; esac in > /etc/profile would be a clumsy workaround and possibly have tricky glitches. Except not every shell read /etc/profile > My proposal catches the issue at its root in the simplest way. > I would provide a patch (if needed) if I had an idea in which package > Cygwin.bat is hiding;-) It's autogenerated. -- WBR, Andrey Repin (anrdae...@yandex.ru) 21.02.2014, <11:48> 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
