printf and echo no longer changing the window title
As seen here http://cygwin.com/ml/cygwin/2005-05/msg01263.html He mention this command echo -e '\E]0;blah\a' However I think he meant to lowercase "E" echo -e '\e]0;blah\a' Either way, these commands are no longer changing the window title. Note that PS1='\e]0;blah\a' Still works $ uname -a CYGWIN_NT-6.1 Steven-PC 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 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: printf and echo no longer changing the window title
Steven Penny wrote: As seen here http://cygwin.com/ml/cygwin/2005-05/msg01263.html He mention this command echo -e '\E]0;blah\a' However I think he meant to lowercase "E" echo -e '\e]0;blah\a' Either way, these commands are no longer changing the window title. Note that PS1='\e]0;blah\a' Still works Works for me. Are you sure you don't have PROMPT_COMMAND set, and it's overriding it? -- Chris J. Breisch -- 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: printf and echo no longer changing the window title
On Tue, May 6, 2014 at 6:27 AM, Chris J. Breisch wrote: > Works for me. Are you sure you don't have PROMPT_COMMAND set, and it's > overriding it? This is on a clean Cygwin install. I deleted the Cygwin folder and reinstall from that. I even tried a clean install in a virtual machine with VirtualBox, same result. Note I am using Windows 7 Service Pack 1. -- 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: Problem with "None" Group on Non-Domain Members
Larry Hall (Cygwin) wrote: On 05/05/2014 06:39 PM, Chris J. Breisch wrote: 513/None is in /etc/group. It's the next to last line. The line above is the last line and apparently comes from some prior invocation of 'mkgroup -c'. I never knew until this moment that there was a 'mkgroup -c', so I didn't do it. :) I am guessing that's part of Cygwin's postinstall? Yes. See /etc/postinstall/000-cygwin-post-install.sh* I'm not quite sure why your user and its ID ended up in your group file though. I don't see it in mine and invoking 'mkgroup -l -c' doesn't enumerate it. For the moment, you can try removing this line and see if it helps with your problem. No, no changes at all. I bet that you're not surprised though. -- Chris J. Breisch -- 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
Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
ount\ as part of the supplementary group list. - If you still use your current /etc/passwd, you will still have the "None" weirdness perhaps, because the group with gid 513 is simply not in your user token, and there's nothing Cygwin can do about that. - If you want to utilize Cygwin's capability to override your primary group, you have two choices: - Download the complete cygwin-inst-20140506.tar.xz for your platform (x86/x86_64) and use the new mkpasswd and mkgroup tools in there to generate new /etc/passwd and /etc/group files. Then override your primary group with the value 545, just like before. - Alternatively, change the primary group in the Windows SAM, as described in the document attached to this mail. It's the latest version of the preliminary documentation of the new account handling in Cygwin. See the chapter "Cygwin user names, home dirs, login shells". Other than that, I'm open to discuss the necessity(?) to override the primary group by default. But, in fact, I'm not sure this really makes sense. Linux systems default to creating a user-specific group account and using that as the user's primary group for years. The Windows Account technique isn't quite as nice, but admittedly, it does its job just as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfCqK9ifX6I.pgp Description: PGP signature
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
On May 6 14:52, Corinna Vinschen wrote: > - Alternatively, change the primary group in the Windows SAM, as > described in the document attached to this mail. It's the latest > version of the preliminary documentation of the new account handling > in Cygwin. See the chapter "Cygwin user names, home dirs, login > shells". Ok, next time I should probably attach the document to the original mail. Sorry, attached now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat === History === For as long as Cygwin has existed, it has stored user and group information in /etc/passwd and /etc/group files. Under the assumption that these files would never be too large, the first process in a process tree, as well as every execing process within the tree would parse them into structures in memory. Thus every Cygwin process would contain an expanded copy of the full information from /etc/passwd and /etc/group. This approach has a few downsides. One of them is that the idea to have always small files is flawed. Another one is that reading the entire file is most of the time entirely useless, since most processes only need information on their own user and the primary group. Last but not least, the passwd and group files have to be maintained separately from the already existing Windows user databases, the local SAM and Active Directory. On the other hand, we have to have a mapping between Windows SIDs and POSIX uid/gid values (see [1]), so we rely on some mechanism to convert SIDs to uid/gid values and vice versa. Microsoft "Services for UNIX" (SFU) (which are unfortunately deprecated since Windows 8/Server 2012) never used passwd/group files. Rather, SFU used a fixed, computational mapping between SIDs and POSIX uid/gid. It allows to generate uid/gid values from SIDs and vice versa. The mechanism is documented, albeit in a confusing way and spread over multiple MSDN articles. The Cygwin approach clones the mapping, with just tiny differences for backward compatibility. = How does it work? = The following description assumes you're comfortable with the concept of Windows SIDs and RIDs. For a brief introduction, please read [1]. Cygwin's new mapping between SIDs and uid/gid values works in two ways. - Read /etc/passwd and /etc/group files, like before, mainly for backward compatibility. - If no files are present, or if an entry is missing in the files, ask Windows. At least, that's the default behaviour now. It will be configurable using a file /etc/nsswitch.conf, which is discussed in a later section. Let's explore the default for now. If files are present, they will be scanned on demand as soon as a mapping from SIDs to uid/gid or account names is required. The new mechanism will never read the entire file into memory, but only scan for the requested entry and cache this one in memory[2]. If no entry is found, or no passwd or group file was present, Cygwin will ask the OS. Note: If the first process in a Cygwin process tree determines that no /etc/passwd or /etc/group file is present, no other process in the entire process tree will try to read the files later on. This is done for self-preservation. It's rather bad if the uid or gid of a user changes during the lifetime of a process tree. For the same reason, if you delete the /etc/passwd or /etc/group file, this will be ignored. The passwd and group records read from the files will persist in memory until either a new /etc/passwd or /etc/group files is created, or you exit all processes in the current process tree. See the note in the section on /etc/nsswitch.conf for some comprehensive examples. So if we've drawn a blank reading the files, we're going to ask the OS. First thing, we ask the local machine for the SID or the username. The OS functions LookupAccountSid and LookupAccountName[3] are pretty intelligent. They have all the stuff built in to ask for any account of the local machine, the Active Directory domain of the machine, the Global Catalog of the forest of the domain, as well as any trusted domain of our forest for the information. One OS call and we're practically done... Except, the calls only return the mapping between SID, account name and the account's domain. We don't have a mapping to POSIX uid/gid and we're missing information on the user's home dir and login shell. Let's discuss the SID<=>uid/gid mapping first. Here's how it works. - Well-known SIDs in the NT_AUTHORITY domain of the S-1-5-RID type, or aliases of the S-1-5-32-RID type are mapped to the uid/gid value RID[4]. For an overview of well-known SIDs, see [5]. Examples: "SYSTEM" S-1-5-18 <=> uid/gid: 18 "Users" S-1-5-32-545 <=> uid/gid: 545 - Other well-known SIDs in the NT_AUTHORITY domain
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
On May 6 14:52, Corinna Vinschen wrote: > - One account in the user token's group list is a special SID for a > user(!) account which apparently connects your local account with the > Microsoft Account. Here's the output from Windows' own `whoami' tool: > > MicrosoftAccount\testu...@foobar.de User > S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 > Mandatory group, Enabled by default, Enabled group > [...] > - The maximum length of a netbios domain name is defined as DNLEN > in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" > has a length of 16. Cygwin uses buffers based on DNLEN :-P Btw. Does anybody here use a Microsoft Account on a non-English Windows system? If so, I'd like to see the output of /cygdrive/c/Windows/System32/whoami /groups | grep S-1-11- What I'm especially interested in is, if the domain name, "MicrosoftAccount" is localized or not. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7FGuoRussv.pgp Description: PGP signature
Re: Problem with "None" Group on Non-Domain Members
On May 5 14:52, Robert Pendell wrote: > On Mon, May 5, 2014 at 12:57 PM, Corinna Vinschen wrote: > > alloc_sd (the underlying function creating a security descriptor) gets > > a uid 1001 and gid 513 as input, as usual. But the owner *and* group > > SIDs of the file's existing security descriptor is > > S-1-5-21-3514886939-1786686319-3519756147-1001, the SID of your user > > account. > > > > Why is your user account the primary group of the file, even though > > your user token definitely has "None" (513) as its primary group? > > How did it get there? > > > > Is that something enforced by the "Microsoft accounts", perhaps? > > > > I just had a look into the Local Security Policy settings, and I can't > > see any related setting. > > > > > > Corinna > > > > I just saw this thread. I'm running Windows 8.1 Update 1 and I'm > using a Microsoft Account as login. I'm seeing the same behavior on > my machine as well with Cygwin64. I'm open to any tests that you > would like me to do as well. Thanks for the offer. Please see my mails I just sent in reply to Chris' mails: http://cygwin.com/ml/cygwin/2014-05/msg00083.html http://cygwin.com/ml/cygwin/2014-05/msg00084.html if you'd like to test the latest snapshot and follow my suggestions in terms of the primary group... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzvBQ_Cpsd7.pgp Description: PGP signature
Re: email-3.1.4
On 5 May 2014 11:36, Corinna Vinschen wrote: > On Apr 21 11:10, axd wrote: > > The latest "email" on Cygwin is email-3.1.2-2, I get an error similar to > > this: > > https://github.com/deanproxy/eMail/issues/7 > > > > Meanwhile there is email-3.1.4 available: > > http://cleancode.org/downloads/email > > > > Is it possible to provide current version? Thank you very much. > > Just uploaded. Thanks, but are you sure you uploaded the correct version? Now I get 3.1.3, which is newer but I expected 3.1.4 (my problem is not fixed with this version) $ email --version email - By: Dean Jones. Email: [...] Version 3.1.3 - Date 10/31/2010-01:13:35PM_EDT -- 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: email-3.1.4
On May 6 15:40, a...@gmx-topmail.de wrote: > On 5 May 2014 11:36, Corinna Vinschen wrote: > > On Apr 21 11:10, axd wrote: > > > The latest "email" on Cygwin is email-3.1.2-2, I get an error similar to > > > this: > > > https://github.com/deanproxy/eMail/issues/7 > > > > > > Meanwhile there is email-3.1.4 available: > > > http://cleancode.org/downloads/email > > > > > > Is it possible to provide current version? Thank you very much. > > > > Just uploaded. > > Thanks, but are you sure you uploaded the correct version? > Now I get 3.1.3, which is newer but I expected 3.1.4 > (my problem is not fixed with this version) The upstream source archive name is email-3.1.4.tar.gz, the directory name in there is email-3.1.3. I assumed this is just a naming glitch by the upstream maintainer. If you can point me to the fix for this version I will create a new package, but I'm not going to debug this myself. I'm just filling in for the original Cygwin maintainer, who seems to have disappeared. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBTLHOKqbvi.pgp Description: PGP signature
Re: printf and echo no longer changing the window title
On 06/05/2014 14:12, Steven Penny wrote: On Tue, May 6, 2014 at 6:27 AM, Chris J. Breisch wrote: Works for me. Are you sure you don't have PROMPT_COMMAND set, and it's overriding it? This is on a clean Cygwin install. I deleted the Cygwin folder and reinstall from that. I even tried a clean install in a virtual machine with VirtualBox, same result. Note I am using Windows 7 Service Pack 1. -- what is PS1 setting ? Likely PS1 is overwriting any "echo -e '\e]0;blah\a'" command what happens if you remove the "\[\e]0;\w\a\]\n\[" (or similar) from PS1 ? regards Marco -- 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: email-3.1.4
On 6 May 2014 15:58, Corinna Vinschen wrote: > On May 6 15:40, axd wrote: > > On 5 May 2014 11:36, Corinna Vinschen wrote: > > > On Apr 21 11:10, axd wrote: > > > > The latest "email" on Cygwin is email-3.1.2-2, I get an error similar > > > > to this: > > > > https://github.com/deanproxy/eMail/issues/7 > > > > > > > > Meanwhile there is email-3.1.4 available: > > > > http://cleancode.org/downloads/email > > > > > > > > Is it possible to provide current version? Thank you very much. > > > > > > Just uploaded. > > > > Thanks, but are you sure you uploaded the correct version? > > Now I get 3.1.3, which is newer but I expected 3.1.4 > > (my problem is not fixed with this version) > > The upstream source archive name is email-3.1.4.tar.gz, the directory > name in there is email-3.1.3. I assumed this is just a naming glitch > by the upstream maintainer. I just figured out that this archive is buggy > If you can point me to the fix for this version I will create a new > package, but I'm not going to debug this myself. Would it be OK for you to get latest version directly from the repository? http://cleancode.org/projects/email/repository -- 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: email-3.1.4
On May 6 16:49, a...@gmx-topmail.de wrote: > On 6 May 2014 15:58, Corinna Vinschen wrote: > > On May 6 15:40, axd wrote: > > > On 5 May 2014 11:36, Corinna Vinschen wrote: > > > > On Apr 21 11:10, axd wrote: > > > > > The latest "email" on Cygwin is email-3.1.2-2, I get an error similar > > > > > to this: > > > > > https://github.com/deanproxy/eMail/issues/7 > > > > > > > > > > Meanwhile there is email-3.1.4 available: > > > > > http://cleancode.org/downloads/email > > > > > > > > > > Is it possible to provide current version? Thank you very much. > > > > > > > > Just uploaded. > > > > > > Thanks, but are you sure you uploaded the correct version? > > > Now I get 3.1.3, which is newer but I expected 3.1.4 > > > (my problem is not fixed with this version) > > > > The upstream source archive name is email-3.1.4.tar.gz, the directory > > name in there is email-3.1.3. I assumed this is just a naming glitch > > by the upstream maintainer. > > I just figured out that this archive is buggy > > > > If you can point me to the fix for this version I will create a new > > package, but I'm not going to debug this myself. > > Would it be OK for you to get latest version directly from the repository? > http://cleancode.org/projects/email/repository I don't know in which state of stability the repo is so I'd prefer an official upstream source archive. I contacted the author. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpw3iKYqxAxz.pgp Description: PGP signature
Re: snapshot 05/05: ssh segmentation fault within screen
On May 6 11:09, Shaddy Baddah wrote: > Hi, > > I've just dropped snapshot 2014-05-05 into my 64bit Cygwin install. > > I am getting a segmentation fault running ssh from within a screen > session. Regardless of the arguments passed: > > $ ssh -V > OpenSSH_6.6.1p1, OpenSSL 1.0.1g 7 Apr 2014 > > $ screen > > Screen version 4.01.00devel (GNU) 2-May-06 > ... > [Press Space or Return to end.] > > $ ssh -V > Segmentation fault (core dumped) This is by far the worst message I got in the last couple of weeks :( The problem here is that I thought it would be a good idea to cache passwd and group data in the cygheap, which is a Cygwin DLL specific heap containing datastructures propagated to child processes via fork and execve. The problem, which I totally not realized since I started implementing this stuff is, that by propagating this cache to child processes, said child processes suffer from what the parent process does to the passwd structures in the cache. Screen seems to call getpwuid and then sets some of the pointers in the passwd structure it got from the call to NULL, apparently for some sort of security, this way overwriting the cached passwd struct for the current user. Ssh on the other hand tries to copy the passwd structure, but it never checks for NULL pointers because, well, the passwd structure never contains NULL pointers. This annihilates every advantage the cygheap caching has. *sob* Oh well, back to the drawing board. This will take some time, though. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTN51U7qWHh.pgp Description: PGP signature
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
Corinna Vinschen wrote: But, here's the deal. I eventually gave up and created a Microsoft Account on my W8.1 machine. And this was definitely the right thing to do, for a couple of reasons: - For a start, it uncovered a case-sensitivity bug in my new SAM/AD account code. - In my case `id' showed clearly that in my user token the primary group is set to my user account itself. I'm using my new SAM/AD code, so I can see what happens if there are no /etc/passwd and /etc/group files in the way. - This explains why your user account shows up in /etc/group. `mkpasswd -c' creates the group info from your user token, and the primary group in your user token is your own user account. - The reason that you *seem* to have "None" as primary group is a result of historical laziness: mkpasswd simply sets the primary gid to 513 for all local accounts, since that's what it always was so far. - The reason that setting your primary group to "None" doesn't really work (and thus, neither do file group permissions) is the fact that the "None" group is no longer in the user token's group list. For kicks, if you call `net user' it still prints Global Group memberships *None - The reason that setting your primary group to "Users" works fine is the fact that it *is* in the user token's group list. - One account in the user token's group list is a special SID for a user(!) account which apparently connects your local account with the Microsoft Account. Here's the output from Windows' own `whoami' tool: MicrosoftAccount\testu...@foobar.de User S-1-11-96-3623454863-58364-18864-2661722203-1597581903-2673650909-3269597714-2381787221-1144632321-4110357092 Mandatory group, Enabled by default, Enabled group The problem here is the length of the SID. So far the Cygwin code assumes that a SID has a maximum number of 8 subauthorities. This is based on the fact that the Win32 routine to generate a SID allows a maximum of 8 subauthorities, so it was a relatively safe assumption. Not so, anymore. The subauthorities are the numbers starting at the 96. If I count correctly we now have a SID with 11 subauthorities. This is, of course, my fault. In reality there's a macro in the Windows headers called SID_MAX_SUB_AUTHORITIES, which is set to 15. But so far there were never more than 6 subauthorities, so I never had a reason to look :| As a sidenote, the SIDs of the Microsoft Accounts are undocumented and no matching values exist even in the latest Microsoft VC++ header files... - The maximum length of a netbios domain name is defined as DNLEN in lmcons.h. DNLEN is 15. The new domain name "MicrosoftAccount" has a length of 16. Cygwin uses buffers based on DNLEN :-P That's the state for now. I patched Cygwin to be able to handle all of the above, but I didn't touch the primary group in the user token yet. So, if you download the today's developer snapshot from http://cygwin.com/snapshots/, you get at least a somewhat sane behaviour: - If you have no passwd/group files (or set /etc/nsswitch.conf to passwd: db group: db so that you just rely on the new SAM/AD code in Cygwin, you get a primary group == your user account. The output of `id' reflects what I wrote above. You will see a group called MicrosoftAccount\ as part of the supplementary group list. Hmmm. Yes, I see that. It seems that the "None" weirdness has just transferred itself to this other group though. Now my test file is owned by Chris.Chris instead of Chris.None and the group permissions still mirror the owner permissions. I dropped my /etc/passwd and am using the new stuff. - If you still use your current /etc/passwd, you will still have the "None" weirdness perhaps, because the group with gid 513 is simply not in your user token, and there's nothing Cygwin can do about that. - If you want to utilize Cygwin's capability to override your primary group, you have two choices: - Download the complete cygwin-inst-20140506.tar.xz for your platform (x86/x86_64) and use the new mkpasswd and mkgroup tools in there to generate new /etc/passwd and /etc/group files. Then override your primary group with the value 545, just like before. - Alternatively, change the primary group in the Windows SAM, as described in the document attached to this mail. It's the latest version of the preliminary documentation of the new account handling in Cygwin. See the chapter "Cygwin user names, home dirs, login shells". Other than that, I'm open to discuss the necessity(?) to override the primary group by default. But, in fact, I'm not sure this really makes sense. Linux systems default to c
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
On May 6 13:01, Chris J. Breisch wrote: > Corinna Vinschen wrote: > >Other than that, I'm open to discuss the necessity(?) to override > >the primary group by default. But, in fact, I'm not sure this really > >makes sense. Linux systems default to creating a user-specific group > >account and using that as the user's primary group for years. The > >Windows Account technique isn't quite as nice, but admittedly, it > >does its job just as well. > > Yes, I've experienced that on Linux, but I don't recall having these > file permission issues there. Perhaps I just never noticed though. No, it *is* different, On Linux you get a user account called "Chris" and a group account called "Chris", and they are different because users and groups are totally different beasts on POSIX systems. You can have a user with uid 42 and a group with gid 42 and they are still different. On Windows, users and groups are identified not by uid/gid, but by their SID. The SID is a unique value, but other than that, a SID can be a user or a group and in lots of cases Windows doesn't care. A group can be owner of a file and a user can be the group of the file, it just doesn't matter to Windows. The permission "problem" you're seeing is a result of that. Your user *and* your primary group are both your user's SID. Therefore the same account is user and primary group at the same time. Therefore, if the file is created, it gets created with an ACL with user and group being the same account. Therefore the POSIX translation of the user and group permissions on the file are always the same. Does this clear it up? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFUUh6XJgEq.pgp Description: PGP signature
Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
I've been working mainly on Linux boxes and haven't had to dig in to
Cygwin deeply for a while. But I have a question or two again. I could
just switch to a Linux server but I figured I'd try my Windows laptop
first.
Goal: Set up Apache2 on my Windows laptop with mod_perl working as well
as Apache2::AuthCookieLDAP and write an example login page that
authenticates to Active Directory using AuthCookieLDAP.
First problem (minor): I can't figure out how to install Apache2 as a
Windows service. For now I can just do apachectl2 start but would like
to configure it as a real service. I've tried:
Adefaria-lt:cygrunsrv -I httpd2 -d 'CYGWIN Apache2' -p
/usr/sbin/httpd2.exe -a '-DNO_DETACH'
Adefaria-lt:net start httpd2
The CYGWIN Apache2 service is starting.
The CYGWIN Apache2 service could not be started.
The service did not report an error.
More help is available by typing NET HELPMSG 3534.
Adefaria-lt:
Second problem: Perl CGI scripts do not execute but just display even
though AddHandler is configured in Apache:
Adefaria-lt:grep -i 'addhandler cgi-script' /etc/apache2/httpd.conf
AddHandler cgi-script .cgi .pl
Adefaria-lt:cat ~/web/test.pl
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print <
A Simple Perl CGI
A Simple Perl CGI
Hello World
HTML
exit;
Adefaria-lt:
When I go to test.pl it just gets printed as the web page. Note that PHP
is working and if I go to phpinfo.php it works just fine...
Third problem: mod_perl2 doesn't seem to want to install:
Running install for module 'mod_perl2'
Running make for P/PH/PHRED/mod_perl-2.0.8.tar.gz
Checksum for
/home/adefaria/.cpan/sources/authors/id/P/PH/PHRED/mod_perl-2.0.8.tar.gz ok
Catching error: "Couldn't move
/cygdrive/a/.cpan/build/tmp-156520/mod_perl-2.0.8/src to
/home/adefaria/.cpan/build/mod_perl-2.0.8-zKWTRp/src: Is a directory at
/usr/lib/perl5/5.14/CPAN/Distribution.pm line
528.\cJ\cICPAN::Distribution::run_preps_on_packagedir(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
355\cJ\cICPAN::Distribution::get(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
1760\cJ\cICPAN::Distribution::make(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3088\cJ\cICPAN::Distribution::test(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3480\cJ\cICPAN::Distribution::install(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Module.pm line 479\cJ\cIeval {...}
called at /usr/lib/perl5/5.14/CPAN/Module.pm line
478\cJ\cICPAN::Module::rematein(CPAN::Module=HASH(0x607f96780),
\"install\") called at /usr/lib/perl5/5.14/CPAN/Module.pm line
578\cJ\cICPAN::Module::install(CPAN::Module=HASH(0x607f96780)) called at
/usr/lib/perl5/5.14/CPAN/Shell.pm line
1797\cJ\cICPAN::Shell::rematein(\"CPAN::Shell\", \"install\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN/Shell.pm
line 1977\cJ\cICPAN::Shell::__ANON__(\"CPAN::Shell\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN.pm line
376\cJ\cIeval {...} called at /usr/lib/perl5/5.14/CPAN.pm line
373\cJ\cICPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line
338\cJ\cIApp::Cpan::_process_options(\"App::Cpan\") called at
/usr/lib/perl5/5.14/App/Cpan.pm line
421\cJ\cIApp::Cpan::run(\"App::Cpan\") called at /bin/cpan line 12\cJ"
at /usr/lib/perl5/5.14/CPAN.pm line 392.
CPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line 338
App::Cpan::_process_options("App::Cpan") called at
/usr/lib/perl5/5.14/App/Cpan.pm line 421
App::Cpan::run("App::Cpan") called at /bin/cpan line 12
--
Andrew DeFaria
--
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: snapshot 05/05: ssh segmentation fault within screen
On 05/06/2014 10:39 AM, Corinna Vinschen wrote: > The problem, which I totally not realized since I started implementing > this stuff is, that by propagating this cache to child processes, said > child processes suffer from what the parent process does to the passwd > structures in the cache. > > Screen seems to call getpwuid and then sets some of the pointers in the > passwd structure it got from the call to NULL, apparently for some sort > of security, this way overwriting the cached passwd struct for the Bug in screen. POSIX states: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.html The application shall not modify the structure to which the return value points, nor any storage areas pointed to by pointers within the structure. The returned pointer, and pointers within the structure, might be invalidated or the structure or the storage areas might be overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid(). > current user. Ssh on the other hand tries to copy the passwd structure, > but it never checks for NULL pointers because, well, the passwd > structure never contains NULL pointers. > > This annihilates every advantage the cygheap caching has. Caching still sounds correct, let's fix the bug in screen instead of bloating cygwin to work around it. Or maybe find a way to cause a SEGV in any process that tries to write into the pointer returned by getpwuid and friends, to help them realize their bug, rather than the current state of propagating the broken memory to other processes. Maybe you just memcpy the result out of the cache into local memory, instead of returning a pointer into the actual cygheap cache. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Microsoft Accounts (was Re: Problem with "None" Group on Non-Domain Members)
Corinna Vinschen wrote: On May 6 13:01, Chris J. Breisch wrote: Corinna Vinschen wrote: Other than that, I'm open to discuss the necessity(?) to override the primary group by default. But, in fact, I'm not sure this really makes sense. Linux systems default to creating a user-specific group account and using that as the user's primary group for years. The Windows Account technique isn't quite as nice, but admittedly, it does its job just as well. Yes, I've experienced that on Linux, but I don't recall having these file permission issues there. Perhaps I just never noticed though. No, it *is* different, On Linux you get a user account called "Chris" and a group account called "Chris", and they are different because users and groups are totally different beasts on POSIX systems. You can have a user with uid 42 and a group with gid 42 and they are still different. On Windows, users and groups are identified not by uid/gid, but by their SID. The SID is a unique value, but other than that, a SID can be a user or a group and in lots of cases Windows doesn't care. A group can be owner of a file and a user can be the group of the file, it just doesn't matter to Windows. The permission "problem" you're seeing is a result of that. Your user *and* your primary group are both your user's SID. Therefore the same account is user and primary group at the same time. Therefore, if the file is created, it gets created with an ACL with user and group being the same account. Therefore the POSIX translation of the user and group permissions on the file are always the same. Does this clear it up? Yes, that makes complete sense. Thank you again. -- Chris J. Breisch -- 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: snapshot 05/05: ssh segmentation fault within screen
On May 6 11:49, Eric Blake wrote: > On 05/06/2014 10:39 AM, Corinna Vinschen wrote: > > > The problem, which I totally not realized since I started implementing > > this stuff is, that by propagating this cache to child processes, said > > child processes suffer from what the parent process does to the passwd > > structures in the cache. > > > > Screen seems to call getpwuid and then sets some of the pointers in the > > passwd structure it got from the call to NULL, apparently for some sort > > of security, this way overwriting the cached passwd struct for the > > Bug in screen. POSIX states: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.html > > The application shall not modify the structure to which the return value > points, nor any storage areas pointed to by pointers within the > structure. The returned pointer, and pointers within the structure, > might be invalidated or the structure or the storage areas might be > overwritten by a subsequent call to getpwent(), getpwnam(), or getpwuid(). Oh, wow. However, what if screen (thinks it) never calls getpwuid or getpwnam again. In that case it may do whatever it wants with the pointers inside the returned passwd structure, doesn't it? It certainly doesn't have to expect sharing with another process. > > current user. Ssh on the other hand tries to copy the passwd structure, > > but it never checks for NULL pointers because, well, the passwd > > structure never contains NULL pointers. > > > > This annihilates every advantage the cygheap caching has. > > Caching still sounds correct, let's fix the bug in screen instead of > bloating cygwin to work around it. Or maybe find a way to cause a SEGV > in any process that tries to write into the pointer returned by getpwuid > and friends, to help them realize their bug, rather than the current > state of propagating the broken memory to other processes. Hmm, I'd have to allocate a full 4K page for this. Also, ssh called from screen works fine on Linux, even if the above behaviour is buggy... > Maybe you > just memcpy the result out of the cache into local memory, instead of > returning a pointer into the actual cygheap cache. Yes, that's what I was coming to realize, too. I'm going to copy the entire entry to local storage and return a pointer to that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpmJWFq7lbS6.pgp Description: PGP signature
Re: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
On 5/6/2014 11:42, Andrew DeFaria wrote: I could just switch to a Linux server but I figured I'd try my Windows laptop first. Don't neglect the option of running a minimal Linux VM on the laptop. You can shove a headless Linux VMs into a pretty small slice of RAM. Goal: Set up Apache2 on my Windows laptop with mod_perl mod_perl has been slowly dying for years. It's not dead yet (*thwack*) but it pretty much only works with Apache 2.2 and older. RHEL7 won't include it at all, because it will ship with Apache 2.4.6. There are third-party patches floating around the net that restore compatibility, but this isn't the sort of thing you want to be building programs against that have to live for many years to come. Cygwin still ships Apache 2.2, but you'd be betting that either Cygwin Apache will never be updated to 2.4, or that mod_perl will get dragged into the modern world before that happens. mod_perl is being allowed to die because all the modern web frameworks have moved to PSGI/Plack instead: http://plackperl.org/ PSGI abstracts away the operating environment. You can run PSGI apps standalone as their own web server, or behind a fast reverse proxy, or in a FastCGI environment (e.g. Apache's mod_fcgid). From the software development perspective, it's all the same. (Devops is a different story, of course.) A common pattern is to run the PSGI app with an internal web server on localhost:3000 or whatever, then put nginx or similar in front of it to carry the static content load and proxy dynamic page requests to the web app. Since the native Windows nginx port doesn't yet run as a Windows service, it isn't suited for systems that need long uptimes, or which can't be left logged in to an interactive desktop. The native Windows version of Apache is only a smidge slower than nginx for many workloads, it ships with mod_proxy to make it act as a reverse proxy, and it naturally runs as a Windows service: http://goo.gl/woQjYZ It is common to use HTTP::Server::PSGI (http://goo.gl/o7wmIm) for development, and only switch to something more complicated when it comes time to deploy to production. If your web app won't have a high load, you may not have to switch at all. Or, if most of the load is static content, you can push that load off onto the reverse proxy. Single-threaded dynamic page generation is fine for many web apps. If you really need concurrent dymamic page generation, a lot of people use Starman (http://goo.gl/J97Ac1) rather than a traditional web server. It is a pure Perl pre-forking web server, compatible with PSGI, and fast enough that a lot of its users don't use a reverse proxy in front of it at all. If you go Perl-native, your web app can run as a single-instance program, which can have tremendous benefits. A lot of old web frameworks persist session data to disk purely because it assumes it will run under pre-forking Apache, where there are many short-lived children that may contend for access to the session store. When all I/O comes into a single long-lived process, you might not have to persist some things to disk at all, greatly reducing that area of I/O overhead. Single-instance web apps also don't have to pay other penalties associated with periodically killing off an restarting child forks. You don't have to use PSGI/Plack directly. All of the modern Perl web frameworks -- Catalyst, Mojolicious, Mason/Poet -- will run under it, providing a much nicer usage environment. I've been using Dancer (http://perldancer.org/) for months now, and love it. I just tested, and it does build and run under Cygwin. Install App::cpanminus with cpan, then just say "cpanm Dancer". Done, easy. (I chose Dancer because it doesn't impose MVC or ORM policies like a lot of other web frameworks do. (Catalyst, Rails, Zope, etc.) You're free to design your web app however it makes sense to you.) If you do go with Dancer or something like it, you don't need to use Cygwin Apache. The native Windows version of Apache will perform much better, and when used as a reverse proxy, you probably won't need any of the benefits you get from using Cygwin Apache which native Apache wouldn't have, such as the ability to compile and load some of the more esoteric modules that only build on POSIXy systems. First problem (minor): I can't figure out how to install Apache2 as a Windows service. Another reason to native Windows Apache instead. -- 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
perl -V:cc still says "gcc-4"
Many moons ago Cygwin "gcc" became GCC 4. Later, Cygwin dropped the "gcc-4" wrapper package. Unfortunately, this means Perl modules that only come in native (XS) form don't compile because perl -V:cc says "gcc-4". I tried creating a symlink from gcc-4 -> gcc in /bin, but it didn't help. STC: cpanm Text::Xslate -- 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
Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
I've been working mainly on Linux boxes and haven't had to dig in to
Cygwin deeply for a while. But I have a question or two again. I could
just switch to a Linux server but I figured I'd try my Windows laptop first.
Goal: Set up Apache2 on my Windows laptop with mod_perl working as well
as Apache2::AuthCookieLDAP and write an example login page that
authenticates to Active Directory using AuthCookieLDAP.
First problem (minor): I can't figure out how to install Apache2 as a
Windows service. For now I can just do apachectl2 start but would like
to configure it as a real service. I've tried:
Adefaria-lt:cygrunsrv -I httpd2 -d 'CYGWIN Apache2' -p
/usr/sbin/httpd2.exe -a '-DNO_DETACH'
Adefaria-lt:net start httpd2
The CYGWIN Apache2 service is starting.
The CYGWIN Apache2 service could not be started.
The service did not report an error.
More help is available by typing NET HELPMSG 3534.
Adefaria-lt:
Second problem: Perl CGI scripts do not execute but just display even
though AddHandler is configured in Apache:
Adefaria-lt:grep -i 'addhandler cgi-script' /etc/apache2/httpd.conf
AddHandler cgi-script .cgi .pl
Adefaria-lt:cat ~/web/test.pl
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print <
A Simple Perl CGI
A Simple Perl CGI
Hello World
HTML
exit;
Adefaria-lt:
When I go to test.pl it just gets printed as the web page. Note that PHP
is working and if I go to phpinfo.php it works just fine...
Third problem: mod_perl2 doesn't seem to want to install:
Running install for module 'mod_perl2'
Running make for P/PH/PHRED/mod_perl-2.0.8.tar.gz
Checksum for
/home/adefaria/.cpan/sources/authors/id/P/PH/PHRED/mod_perl-2.0.8.tar.gz ok
Catching error: "Couldn't move
/cygdrive/a/.cpan/build/tmp-156520/mod_perl-2.0.8/src to
/home/adefaria/.cpan/build/mod_perl-2.0.8-zKWTRp/src: Is a directory at
/usr/lib/perl5/5.14/CPAN/Distribution.pm line
528.\cJ\cICPAN::Distribution::run_preps_on_packagedir(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
355\cJ\cICPAN::Distribution::get(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
1760\cJ\cICPAN::Distribution::make(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3088\cJ\cICPAN::Distribution::test(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3480\cJ\cICPAN::Distribution::install(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Module.pm line 479\cJ\cIeval {...}
called at /usr/lib/perl5/5.14/CPAN/Module.pm line
478\cJ\cICPAN::Module::rematein(CPAN::Module=HASH(0x607f96780),
\"install\") called at /usr/lib/perl5/5.14/CPAN/Module.pm line
578\cJ\cICPAN::Module::install(CPAN::Module=HASH(0x607f96780)) called at
/usr/lib/perl5/5.14/CPAN/Shell.pm line
1797\cJ\cICPAN::Shell::rematein(\"CPAN::Shell\", \"install\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN/Shell.pm
line 1977\cJ\cICPAN::Shell::__ANON__(\"CPAN::Shell\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN.pm line
376\cJ\cIeval {...} called at /usr/lib/perl5/5.14/CPAN.pm line
373\cJ\cICPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line
338\cJ\cIApp::Cpan::_process_options(\"App::Cpan\") called at
/usr/lib/perl5/5.14/App/Cpan.pm line
421\cJ\cIApp::Cpan::run(\"App::Cpan\") called at /bin/cpan line 12\cJ"
at /usr/lib/perl5/5.14/CPAN.pm line 392.
CPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line 338
App::Cpan::_process_options("App::Cpan") called at
/usr/lib/perl5/5.14/App/Cpan.pm line 421
App::Cpan::run("App::Cpan") called at /bin/cpan line 12
--
Andrew DeFaria
--
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
thank you for vsnprintf et al
Hello, The recent snapshots (since 20140505) contain (in /usr/include/stdio.h) the declarations of the vsnprintf(), snprintf() etc. functions, including (this is new) for under strict C++11 (i.e. 'gcc -std=c++11’). I think this is worth noting. And thank you. 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: Testers needed: New passwd/group handling in Cygwin
Achim Gratz NexGo.DE> writes: > I guess it does: the mapping that gets created from AD is sometimes 1049120 > instead of 544. That depends on the settings in nsswitch.conf and whether > an /etc/group file exists at all or contains an entry for Administrators. I > guess that once this behaviour is stable (and maps to 544 in every case) the > problem that Perl is having also goes away. I've installed todays snapshot and removed passwd, group and nsswitch.conf. So far everything looks OK (while I'm wired to the local network, wireless and VPN testing will have to wait). The Administrators group maps to 544 as it should and Perl correctly determines accessibility of files and directories via the ACL. 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
Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
Forgive me if this is double posted. I posted yesterday after a long
hiatus of posting anything to the Cygwin Mailing list and it didn't seem
to show up so I'm trying again. If anybody sees this then a quick email
to adefa...@audience.com saying you saw it would clear that up.
I've been working mainly on Linux boxes and haven't had to dig in to
Cygwin deeply for a while. But I have a question or two again. I could
just switch to a Linux server but I figured I'd try my Windows laptop first.
Goal: Set up Apache2 on my Windows laptop with mod_perl working as well
as Apache2::AuthCookieLDAP and write an example login page that
authenticates to Active Directory using AuthCookieLDAP.
First problem (minor): I can't figure out how to install Apache2 as a
Windows service. For now I can just do apachectl2 start but would like
to configure it as a real service. I've tried:
Adefaria-lt:cygrunsrv -I httpd2 -d 'CYGWIN Apache2' -p
/usr/sbin/httpd2.exe -a '-DNO_DETACH'
Adefaria-lt:net start httpd2
The CYGWIN Apache2 service is starting.
The CYGWIN Apache2 service could not be started.
The service did not report an error.
More help is available by typing NET HELPMSG 3534.
Adefaria-lt:
Second problem: Perl CGI scripts do not execute but just display even
though AddHandler is configured in Apache:
Adefaria-lt:grep -i 'addhandler cgi-script' /etc/apache2/httpd.conf
AddHandler cgi-script .cgi .pl
Adefaria-lt:cat ~/web/test.pl
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print <
A Simple Perl CGI
A Simple Perl CGI
Hello World
HTML
exit;
Adefaria-lt:
When I go to test.pl it just gets printed as the web page. Note that PHP
is working and if I go to phpinfo.php it works just fine...
Third problem: mod_perl2 doesn't seem to want to install:
Running install for module 'mod_perl2'
Running make for P/PH/PHRED/mod_perl-2.0.8.tar.gz
Checksum for
/home/adefaria/.cpan/sources/authors/id/P/PH/PHRED/mod_perl-2.0.8.tar.gz ok
Catching error: "Couldn't move
/cygdrive/a/.cpan/build/tmp-156520/mod_perl-2.0.8/src to
/home/adefaria/.cpan/build/mod_perl-2.0.8-zKWTRp/src: Is a directory at
/usr/lib/perl5/5.14/CPAN/Distribution.pm line
528.\cJ\cICPAN::Distribution::run_preps_on_packagedir(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
355\cJ\cICPAN::Distribution::get(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
1760\cJ\cICPAN::Distribution::make(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3088\cJ\cICPAN::Distribution::test(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Distribution.pm line
3480\cJ\cICPAN::Distribution::install(CPAN::Distribution=HASH(0x60aa40ad8))
called at /usr/lib/perl5/5.14/CPAN/Module.pm line 479\cJ\cIeval {...}
called at /usr/lib/perl5/5.14/CPAN/Module.pm line
478\cJ\cICPAN::Module::rematein(CPAN::Module=HASH(0x607f96780),
\"install\") called at /usr/lib/perl5/5.14/CPAN/Module.pm line
578\cJ\cICPAN::Module::install(CPAN::Module=HASH(0x607f96780)) called at
/usr/lib/perl5/5.14/CPAN/Shell.pm line
1797\cJ\cICPAN::Shell::rematein(\"CPAN::Shell\", \"install\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN/Shell.pm
line 1977\cJ\cICPAN::Shell::__ANON__(\"CPAN::Shell\",
\"Apache2::AuthCookie\") called at /usr/lib/perl5/5.14/CPAN.pm line
376\cJ\cIeval {...} called at /usr/lib/perl5/5.14/CPAN.pm line
373\cJ\cICPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line
338\cJ\cIApp::Cpan::_process_options(\"App::Cpan\") called at
/usr/lib/perl5/5.14/App/Cpan.pm line
421\cJ\cIApp::Cpan::run(\"App::Cpan\") called at /bin/cpan line 12\cJ"
at /usr/lib/perl5/5.14/CPAN.pm line 392.
CPAN::shell() called at /usr/lib/perl5/5.14/App/Cpan.pm line 338
App::Cpan::_process_options("App::Cpan") called at
/usr/lib/perl5/5.14/App/Cpan.pm line 421
App::Cpan::run("App::Cpan") called at /bin/cpan line 12
--
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: perl -V:cc still says "gcc-4"
Warren Young writes: > Many moons ago Cygwin "gcc" became GCC 4. Later, Cygwin dropped the > "gcc-4" wrapper package. > > Unfortunately, this means Perl modules that only come in native (XS) > form don't compile because perl -V:cc says "gcc-4". I tried creating > a symlink from gcc-4 -> gcc in /bin, but it didn't help. Yes, I've posted about this some time ago. You absolutely need to name the symlink "gcc-4.exe". You could also patch out the EXEEXT appendage that makes that particular check fail when it encounters a symlink of just "gcc-4", but renaming the symlink is easier. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: 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: perl -V:cc still says "gcc-4"
On 5/6/2014 13:35, Warren Young wrote: Unfortunately, this means Perl modules that only come in native (XS) form don't compile because perl -V:cc says "gcc-4". I tried creating a symlink from gcc-4 -> gcc in /bin, but it didn't help. This only affects 32-bit Cygwin, by the way. I tried the STC on 64-bit Cygwin where perl -V:cc says "gcc", and it built and installed the module, and the module works. -- 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: perl -V:cc still says "gcc-4"
On 06/05/2014 20:35, Warren Young wrote: Many moons ago Cygwin "gcc" became GCC 4. Later, Cygwin dropped the "gcc-4" wrapper package. Unfortunately, this means Perl modules that only come in native (XS) form don't compile because perl -V:cc says "gcc-4". I tried creating a symlink from gcc-4 -> gcc in /bin, but it didn't help. STC: cpanm Text::Xslate This is how I build perl-Text-CSV_XS - I create a symbolic link as you described. Using cygport I was able to produce a Xslate DLL, but I couldn't run the test suite as I'm missing many dependencies. Does the attached help? Dave. CPAN_AUTHOR=GFUJI inherit perl NAME="perl-Text-Xslate" VERSION=3.2.4 RELEASE=1 CATEGORY="Perl" SUMMARY="Scalable template engine." DESCRIPTION="Xslate is a template engine, tuned for persistent applications, safe as an HTML generator, and with rich features." -- 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: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
On 5/6/2014 12:33 PM, Warren Young wrote: On 5/6/2014 11:42, Andrew DeFaria wrote: I could just switch to a Linux server but I figured I'd try my Windows laptop first. Don't neglect the option of running a minimal Linux VM on the laptop. You can shove a headless Linux VMs into a pretty small slice of RAM. Well I do happen to have a Linux VM but usually I'm just given a Windows laptop by my clients and must press on. Sure I could download and install vmware and get a Linux VM setup but that's a lot of work to do to set up a machine I'm basically only using for one thing. Sure setting up Cygwin takes work/care/feeding but I can then use that Cygwin installation all the time to connect to and develop stuff. Goal: Set up Apache2 on my Windows laptop with mod_perl mod_perl has been slowly dying for years. It's not dead yet (*thwack*) but it pretty much only works with Apache 2.2 and older. RHEL7 won't include it at all, because it will ship with Apache 2.4.6. There are third-party patches floating around the net that restore compatibility, but this isn't the sort of thing you want to be building programs against that have to live for many years to come. ... Yeah thanks for all of that but really my real goal was just to get Apache2::AuthCookieLDAP working. That seems to require mod_perl. Of course if mod_perl is dying then that brings in the question of "Is it worth it to develop a login page to authenticate with Active Directory and store cookies to ease logins if this all might be going away?". ... If you do go with Dancer or something like it, you don't need to use Cygwin Apache. The native Windows version of Apache will perform much better, and when used as a reverse proxy, you probably won't need any of the benefits you get from using Cygwin Apache which native Apache wouldn't have, such as the ability to compile and load some of the more esoteric modules that only build on POSIXy systems. First problem (minor): I can't figure out how to install Apache2 as a Windows service. Another reason to native Windows Apache instead. Personally I prefer Cygwin Apache because all of the pathing then can be POSIX-like and can easily port to Linux systems later on. Plus Cygwin's Perl is, IMHO, far superior to ActiveState. However I had set up Apache2 as a Windows service before so I know it's doable. I just forget how to do it! ;-) I thought it was just to specify -k or perhaps -DNO_DETACH or something like that... -- 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: perl -V:cc still says "gcc-4"
On 06/05/14 21:45, Achim Gratz wrote: Warren Young writes: Many moons ago Cygwin "gcc" became GCC 4. Later, Cygwin dropped the "gcc-4" wrapper package. Unfortunately, this means Perl modules that only come in native (XS) form don't compile because perl -V:cc says "gcc-4". I tried creating a symlink from gcc-4 -> gcc in /bin, but it didn't help. Yes, I've posted about this some time ago. You absolutely need to name the symlink "gcc-4.exe". This is not my experience. My link is called 'gcc-4' pointing to 'gcc'; there is no '.exe' extension in either source or destination. This gets XS modules compiling for me. 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: perl -V:cc still says "gcc-4"
On 5/6/2014 14:45, Achim Gratz wrote: You absolutely need to name the symlink "gcc-4.exe". That may have done it. I'd have to do some manual CPAN package uninstalls and reinstalls, testing under various conditions to be sure, and can't be bothered. I can say that I *also* required a g++-4 -> g++ symlink. I made it with .exe, just to be safe. -- 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: printf and echo no longer changing the window title
On Tue, May 6, 2014 at 9:10 AM, Marco Atzeri wrote: > what is PS1 setting ? > Likely PS1 is overwriting any "echo -e '\e]0;blah\a'" command Yes sir! That was it! Culpable file /etc/bash.bashrc Thanks for the help. -- 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: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
On 5/6/2014 15:10, Andrew DeFaria wrote: Yeah thanks for all of that but really my real goal was just to get Apache2::AuthCookieLDAP working. Plack::Middleware::Auth::Basic supports LDAP auth: http://goo.gl/O7RHgp Personally I prefer Cygwin Apache because all of the pathing then can be POSIX-like and can easily port to Linux systems later on. Plus Cygwin's Perl is, IMHO, far superior to ActiveState. The two issues are actually separate. There's nothing making you use ActiveState Perl to run a PSGI app front-ended by native Windows Apache. PSGI apps behind a reverse proxy simply present an HTTP interface to the proxy. As far as the proxy server knows, the app providing that interface could be built in F#. (Why F#? Another new favorite tool, and about as different from Perl as you can get. :) ) However I had set up Apache2 as a Windows service before so I know it's doable. I just forget how to do it! ;-) I thought it was just to specify -k or perhaps -DNO_DETACH or something like that... Did you try -F? http://comments.gmane.org/gmane.os.cygwin/60331 -- 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: perl -V:cc still says "gcc-4"
On 5/6/2014 15:05, David Stacey wrote: Does the attached help? Thank you, but I wasn't actually trying to make a Cygwin package. I just noticed this while composing my answer to Andrew DeFaria in his mod_perl thread. I tried to build Dancer::Template::Xslate (which depends on Text::Xslate) and it failed, so I thought I'd report it, hoping it would give the Perl maintainer incentive to update the package. ...which turns out to not be necessary, since Reini Urban's 5.18.2 32-bit test build doesn't say "gcc-4" any more. Assuming no regression, this will be fixed when Cygwin moves formally to Perl 5.18. So never mind. :) -- 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: perl -V:cc still says "gcc-4"
On 06/05/14 23:02, Warren Young wrote: Assuming no regression, this will be fixed when Cygwin moves formally to Perl 5.18. Indeed - I have already built perl-Text-CSV_XS for perl-5.18.2, and no 'gcc-4' symlink was necessary. Glad you managed to get Text::Xslate built in the end, 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: Bug at getsockopt when TCP_NODELAY is used as parameter
Hi Corinna, I have recompiled and tested Varnish Cache 3.0.5 against cygwin snapshot 2014-05-05 (64 bits), removing my workaround, and now TCP_NODELAY functionality works fine. In order to planning the release of fixed varnish 3.0.5, Do you have any estimated release date for future Cygwin 1.7.30? Thank you --- This email is free from viruses and malware because avast! Antivirus protection is active. 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: Setting up Apache2 with mod_perl and Apache2::AuthCookieLDAP
On 5/6/2014 2:51 PM, Warren Young wrote:
On 5/6/2014 15:10, Andrew DeFaria wrote:
Yeah thanks for all of that but really my real goal was just to get
Apache2::AuthCookieLDAP working.
Plack::Middleware::Auth::Basic supports LDAP auth: http://goo.gl/O7RHgp
Personally I prefer Cygwin Apache because all of the pathing then can be
POSIX-like and can easily port to Linux systems later on. Plus Cygwin's
Perl is, IMHO, far superior to ActiveState.
The two issues are actually separate. There's nothing making you use
ActiveState Perl to run a PSGI app front-ended by native Windows Apache.
PSGI apps behind a reverse proxy simply present an HTTP interface to
the proxy. As far as the proxy server knows, the app providing that
interface could be built in F#.
If you are using a Cygwin based Apache then it will follow symlinks
whereas my experience with the Windows based Apache it doesn't.
(Why F#? Another new favorite tool, and about as different from Perl as
you can get. :) )
However I had set up Apache2 as a Windows service before so I know it's
doable. I just forget how to do it! ;-) I thought it was just to specify
-k or perhaps -DNO_DETACH or something like that...
Did you try -F?
http://comments.gmane.org/gmane.os.cygwin/60331
That message was about Apache 1.3. I'm on Apache 2.2. There is no -F option:
Adefaria-lt:/usr/sbin/httpd2 -F
httpd2: illegal option -- F
Usage: /usr/sbin/httpd2 [-D name] [-d directory] [-f file]
[-C "directive"] [-c "directive"]
[-k start|restart|graceful|graceful-stop|stop]
[-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S]
Options:
-D name: define a name for use in directives
-d directory : specify an alternate initial ServerRoot
-f file: specify an alternate ServerConfigFile
-C "directive" : process directive before reading config files
-c "directive" : process directive after reading config files
-e level : show startup errors of level (see LogLevel)
-E file: log startup errors to file
-v : show version number
-V : show compile settings
-h : list available command line options (this page)
-l : list compiled in modules
-L : list available configuration directives
-t -D DUMP_VHOSTS : show parsed settings (currently only vhost settings)
-S : a synonym for -t -D DUMP_VHOSTS
-t -D DUMP_MODULES : show all loaded modules
-M : a synonym for -t -D DUMP_MODULES
-t : run syntax check for config files
-T : start without DocumentRoot(s) check
Adefaria-lt:
--
body {
font: Helvetica, Arial, sans-serif;
}
p {
font: Helvetica, Arial, sans-serif;
}
.standout {
font-family: verdana,
arial,
sans-serif;
font-size:12px;
color:#99;
line-height: 13px;
font-weight: bold;
margin-bottom:10px;
}
.code {
border-top: 1px solid #ddd;
border-left: 1px solid #ddd;
border-right: 2px solid #000;
border-bottom:2px solid #000;
padding: 10px;
margin-top: 5px;
margin-left: 5%;
margin-right: 5%;
background: #ea;
color:black;
font-family: courier;
white-space: pre;
-moz-border-radius: 10px;
}
.terminal {
border-top: 10px solid #03f;
border-left: 1px solid #ddd;
border-right: 2px solid grey;
border-bottom:2px solid grey;
padding: 10px;
margin-top: 5px;
margin-left: 5%;
margin-right: 5%;
background: black;
color:white;
font-family: courier;
white-space: pre;
-moz-border-radius: 10px;
}
a:link {
color:blue;
}
a:visited {
color:darkblue;
}
a:hover {
color:black;
background-color: #cc;
text-decoration: underline;
}
a:active {
color:red;
}
http://defaria.com/Images/clearscm.com-qrcode.jpg";
align="left" height="100" width="100"/>
http://defaria.com";>Andrew DeFaria
http://clearscm.com";>ClearSCM, Inc.
--
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
