Re: perl -r says readable dir is unreadable
On Sat, April 25, 2009 9:37 pm, Mikel Ward wrote: The key is that the -r (file is readable) operator returns false for directories that I CAN read. test and ls prove that I can read them. -r does not test to see if you can read a file, it tests whether the mode gives you read access to the file. $ ~/bin/pstat /c/WINDOWS mode = 16888 (= 040770) And it does not. This may help: use filetest access; (see http://search.cpan.org/perldoc/filetest) but the only guaranteed cross-platform way to see if you can read a file is to try to read it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GREP: Memory Exhausted
On Wed, April 15, 2009 12:46 pm, Dave Korn wrote: Letters in an error message don't just randomly change between upper and lower case for no reason. Either you two are using different versions of grep, or Shailesh did not accurately report the *actual* error message that he was *actually* seeing. Note that Shailesh parsed grep man page as (grep man) page [on cygwin.com], not as grep (man page). I know how that inclines me to choose between your either and or. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[attention base-files maintainer] copying /bin files to home dir on first run of cygwin.bat
I did a base install of cygwin 1.7 (using setup-1.7.exe),
and the first time I ran cygwin.bat, it gave the following:
Copying skeleton files.
These files are for the user to personalise their cygwin experience.
They will never be overwritten nor automatically updated.
bash: cd: /etc/skel: No such file or directory
`./addftinfo.exe' - `/home/ysth//addftinfo.exe'
`./afmtodit' - `/home/ysth//afmtodit'
...
repeated for many files.
Looking into it further, it seems at least this version of
base-files (3.8-2) has a postinstall script that is
expecting something else to have created /etc/skel before
it starts copying files from /etc/defaults/etc/skel there.
This is one possible fix:
$ cat bf.patch
--- etc/postinstall/base-files-profile.sh.orig 2009-02-15
13:50:22.77960 -0800
+++ etc/postinstall/base-files-profile.sh 2009-02-15
13:54:16.34280 -0800
@@ -10,6 +10,7 @@
fDest=/${f}
if [ ! -e ${fDest} -a ! -L ${fDest} ]; then
/bin/echo Using the default version of ${fDest} (${fSrc})
+/bin/mkdir -p `dirname ${fDest}`
/bin/touch ${fDest}
/bin/cp ${fSrc} ${fDest}
else
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: CygWine 1.0 Beta -- an new cygwin package manager
I'd rather see the common code put into a library (and available in both cygwin and mingw flavors). Then it would be pretty easy to have a Cygwin::Setup perl extension and command line tools using it. (Substitute your other glue language of choice as desired.) On Thu, February 12, 2009 10:17 am, Dave Korn wrote: I'm taking a quick browse through the code. I see that you've based it on chunks of the core setup.exe code, somewhat refactored and restructured. I wonder if we couldn't merge the two codebases, in such a way that there's one common 'setup engine' with a couple of alternative GUI front-ends; that might be a neat way to fix up all the missing features and make sure there is thoroughly consistent behaviour between the two different installers. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: is it an FAQ: cygwin startup sequence
On Sun, December 21, 2008 4:56 pm, Kermit Tensmeyer wrote: On Sun, Dec 21, 2008 at 6:21 PM, Eric Blake e...@byu.net wrote: My guess is that you might have PATH problems. But if you had followed these directions: and that's why I'm asking for the documentation. I don't need/want you to solve a problem that apparently only I have. Ah, but technical mailing lists are usually hangouts for problem-solving addicts. In a sense, solving a problem is the reward the denizens expect for going to the hassle of responding. Problem reports: http://cygwin.com/problems.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin Design
On Fri, September 12, 2008 3:08 pm, Jason Pyeron wrote: I am deeply interested in implementing a simple command interpreter in Windows XP platform as a part of my summer project, so will you please give me some hint on implementing it. Isn't summer over? Do I detect the taint of hemisphericentrism? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Design
On Fri, September 12, 2008 9:38 am, RD wrote: I am deeply interested in implementing a simple command interpreter in Windows XP platform as a part of my summer project, so will you please give me some hint on implementing it. I suspect cygwin will be of little use to you in pursuing such a goal. You might start here, though: http://www.opengroup.org/onlinepubs/95399/idx/shell.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: why the strange stack stuf in cygwin?
(reformatted) On Tue, September 2, 2008 12:42 am, [EMAIL PROTECTED] wrote: Jay [EMAIL PROTECTED] wrote: snipped the drivel ... The code seems very wierd in places. I don't like it. I know, boo hoo, whine whine whine. It seems to work but it makes me nervous. - Jay Jay, rather than making silly pedantic and empty arguments I'd rather that you contributed to making things better. That is if you were truely up to it capable. Wow, *that* was an awesome contribution to the thread. Thanks for sharing. regards I somehow missed those. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How do I fetch files from the web?
On Mon, August 11, 2008 2:50 am, circ ular wrote: 1. how do I install packages once I already have installed cygwin? Use http://cygwin.com/setup.exe to select additional packages. 2. what do I write do download from a specific internetadress. This list is for cygwin-specific questions, not general linux use question. But: there isn't one specific way. Offhand, there are curl, wget, and lynx (each in the pacakge of the same name). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: programming API to determine whether in 'Cygwin environment'
On Thu, July 10, 2008 10:06 pm, Christopher Faylor wrote: On Thu, Jul 10, 2008 at 08:49:06PM -0700, Tony Last wrote: My console program is built for native Windows (thus does not reply on cygwin1.dll). So I'm looking for a boolean method which will allow a program to tell whether it was run from within a Cygwin shell. A PATH containing colons which weren't preceded by just a single alphabetic character would be a clue but it wouldn't be foolproof. A HOME environment variable with no colons and forward slashes would be another clue. I don't think there is a foolproof test, though. Both HOME and PATH are translated by the time the non-cygwin program sees them, though?? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Ugrent !! Reg. Executing the EXE generated by Cygwin
On Fri, June 13, 2008 2:23 am, Mani kandan wrote: This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. We have made sure that we use the same version of cygwin1.dll while building the exe and while running it on the server. What are the possible reasons for this? Are there any other solutions to this? The most likely reason and the solution for it were already provided to you by Cygwin itself. See above. Have you read and performed those instructions? === Yes, we have read and performed those instruction. We have placed the cygwin1.dll in current working folder which is inside the c:\cygwin\bin folder while generating the exe. We have checked the size of the dll also. Both are same size . Then wt are the possible reasons for this problem?? You have misunderstood the problem. It has nothing to do with incompatibilities between the dll used to build an exe and to run it. The problem is having multiple versions of the dll running on the same machine at the same time. Please re-read cygwin's advice with this in mind. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: building perl-5.8.8-4 from source 'perl-5.8.8-ext-Win32CORE.tar.bz2 not found'
On Sat, May 24, 2008 8:45 am, David Christensen wrote: I am attempting to build Perl from source (I'm curious about Perl's regression test), but it appears that the current Cygwin source distribution is incomplete: If you don't want to duplicate the exact cygwin binary distribution, but don't want a perl 5.10, just download and build from http://search.cpan.org/dist/perl-5.8.8 or, for what will become 5.8.9, http://public.activestate.com/pub/apc/perl-5.8.x-snap/perl-5.8.x-latest.tar.bz2 (which does include the Win32CORE changes, I believe). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: please add a find-the-fastest-mirror-automatically feature to setup.exe
On Fri, May 23, 2008 10:03 pm, Soren Andersen wrote: On Fri, 23 May 2008 12:23:13 -0400 Chris Sutcliffe [EMAIL PROTECTED] wrote: Setup.exe is a great tool, but could you please add a find-the-fastest-mirror-automatically feature? That would require making a connection attempt to every entry in setup's list, which would be rather counter-productive I would think. Yes, it would (and annoying, etc...). However, I can envision a compromise solution in which Setup.exe looks for a file, a la unix user rc files, and if found reads the address of the preferred host to use from that file. Caching the result of a one-time burst of pings, in other words. Something like /etc/setup/last-mirror, perhaps? :)
Re: Putting my packages up for adoption
On Wed, April 30, 2008 3:27 am, Corinna Vinschen wrote: According to Max Bowsher on 4/29/2008 4:47 PM: | Farewell, of sorts, and thanks everyone for helping make Windows a nice | place to be the past many years! Sad ACK. I've marked all your packages as orphaned now. Would not a farewell gold star be appropriate?
Re: Add OpenSC packages to cygwin?
On Fri, April 25, 2008 2:16 pm, Alon Bar-Lev wrote: Is anyone interested in maintaining a cygwin packages for OpenSC projects? To whit: http://www.opensc-project.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32Core module question
On Mon, September 10, 2007 12:34 pm, Reini Urban wrote: John Neil schrieb: Thanks. For now I installed the previous version of the Cygwin perl-libwin32 package, but I agree there should be some way to access the non-core Win32 routines that were previously available without having to install the Win32 module yourself. Oops, I seem to have forgot my promise to add Win32.pm to CORE, when Jan removed it from libwin32. perl-libwin32-0.26 has it. perl-libwin32-0.27 not anymore. perl-5.8.8 needs another update, sorry. Our quality process is really bad. I noticed the situations when John asked about this last week at http://perlmonks.org/?node_id=637296 and I started to email you, but then got distracted. I'm glad someone ended up getting in touch with you. You should be able to just remove the win32/ext/Win32/ files and include the win32/ext/Win32 files from maint and change MANIFEST accordingly. Pedantically, it would also be nice to use the Configure patch in http://public.activestate.com/cgi-bin/perlbrowse/p/30733 Win32API::File is still in libwin32, since even for MSWin32 builds it won't move to the core till 5.8.9, correct? Thanks for all your work on cygwin perl. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Perl and -Duselongdouble
On Thu, July 26, 2007 5:19 am, Corinna Vinschen wrote: On Jul 26 22:09, Sisyphus wrote: I'd like to have a perl on Cygwin built with -Duselongdouble, so I tried *** You requested the use of long doubles but you do not seem to have *** the following mathematical functions needed for long double support: *** sqrtl modfl frexpl Long double functions are not supported by newlib so far. There are a couple of C99 functions not available in newlib. Volunteers implementing these functions in a license compatible way (BSD, not GPL) in newlib are always welcome. Note that changing perl to use long doubles is a binary incompatible change. So if anyone is going to jump on this, it would be nice to have it happen before the already incompatible 5.10 is out Septemberish. modfl isn't strictly necessary; perl will substitute aintl (a solaris flavor of truncl) + copysignl. And ilogbl + scalbnl can be used to emulate frexpl. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl-5.9.5
On Wed, June 20, 2007 6:39 pm, Reini Urban wrote: I almost have that ready, I just wait for some of my cygwin patches upstream. With current blead (5.9.5) I get now the same number of failing tests as with 5.8 ../lib/Net/Ping/t/500_ping_icmp.t21 50.00% 2 being the only leftover. How should we name it so that users can experiment with that? Side-by-side to perl-5.8.8 Since 5.9.5 is basically a beta 5.10.0, I would actually make it a test version of a new perl5.10 package (so perl5.10-5.9.5-1). When 5.10.0 is released, the package would be updated to perl5.10-5.10.0-1 and move to current. I also enabled -DDEBUGGING, esp. for the new regex engine. Different routines with DEBUGGGING enabled are swapped in when you do use re debug, so that shouldn't be necessary. Note that DEBUGGING on vs. off are not binary-compatible, so once you pick a state, you're stuck with it unless you want to make people recompile XS modules they've built.
Re: [ITP] perl-5.8.8
On Tue, June 19, 2007 7:24 pm, Reini Urban wrote: I want to it take over from Gerrit. Thank you so much. If it were up to me, you'd get three gold stars. Please try to test it. It's a really weird build system. But I'm quite happy with this 5.8.8 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1-src.tar.b z2 http://rurban.xarch.at/software/cygwin/release/perl/perl_manpages/perl_ma npages-5.8.8-1.tar.bz2 setup.hint's attached (unchanged) Failed Test Stat Wstat Total Fail Failed List of Failed -- - ../ext/IPC/SysV/t/ipcsysv.t 1 25616 32 200.00% 1-16 ../ext/IPC/SysV/t/msg.t 012?? ?? % ?? ../ext/IPC/SysV/t/sem.t 012?? ?? % ?? ../lib/Net/Ping/t/500_ping_icmp.t21 50.00% 2 op/magic.t 581 1.72% 27 op/taint.t 012 238 178 74.79% 150-238 25 tests and 262 subtests skipped. Failed 6/996 test scripts, 99.40% okay. 107/117806 subtests failed, 99.91% okay. I think all of those but the Net::Ping are due to cygserver not running (or server not in CYGWIN). And Net::Ping tends to have obscure problems that vary from system to system. I also have a test version for perl-5.9.4 ready, but I'll wait a bit to get some patches in, until Rafaël announces the 5.9.5 release. -- There shouldn't be major changes between now and 5.9.5, so it wouldn't hurt at all to grab http://public.activestate.com/pub/apc/perl-current-snap/perl-current-latest.tar.bz2 for a test version.
Re: [ANNOUNCEMENT] EOL for Windows 95/86/Me
Corinna Vinschen wrote: On Feb 13 21:02, Yaakov (Cygwin Ports) wrote: And approximately what is the timeframe to 1.7.0; weeks, months, next year? Is HEAD stable enough for those not working on cygwin1.dll to be testing? Months. It's stable enough now but it's constantly changing. Stability in snapshots is not guaranteed. Exciting new stuff so far (IMHO): [snip] - More POSIXy unlink/rmdir behaviour Can you expand on that? What changes? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl bug?
On Jan 28 11:57, Yitzchak Scott-Thoennes wrote: Corinna Vinschen wrote: Thanks for the info. It's interesting to know. What I still don't get, however, is the fact that the same statement does not waste memory on the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8.7 and the x86_64 Linux 5.8.8. So it has been introduced only in later versions? And why is it defended? It doesn't seem to make sense, rather on the contrary. This behaviour hasn't changed that I know of. I verified that a 5.8.5 cygwin perl behaves the same way. Could you confirm your x86 Linux Perl 5.8.5 results again, and send me (privately if you wish) the output of: perl -MConfig=config_sh -we'print config_sh' from that perl? I just ran the testcase under strace on the Linux box again and to my surprise it behaved identical to the Cygwin and the 64 bit Linux version, as you say. What have I done wrong in my first tests? Was I hallucinating, caffein-induced maybe? Perhaps your command history could tell you? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl bug?
Corinna Vinschen wrote: On Jan 27 23:17, Reini Urban wrote: Václav Haisman schrieb: If I were you I would report it as a bug to their bug tracker. It's no bug, it's a perl feature, Uh, right, a *feature* ;) and often defended. Even dll's are not unloaded. If you want to free it, free it explicitly with undef or with lexicals (my) go out of scope. Doesn't help in this case, Reini. Same with PHP and python btw. Only GC languages like lisp, ml and its derivates have a proper GC. The perl GC they are talking about only garbage collects cyclic referenced objects on final destruction, to enable proper free() of externals. Thanks for the info. It's interesting to know. What I still don't get, however, is the fact that the same statement does not waste memory on the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8.7 and the x86_64 Linux 5.8.8. So it has been introduced only in later versions? And why is it defended? It doesn't seem to make sense, rather on the contrary. This behaviour hasn't changed that I know of. I verified that a 5.8.5 cygwin perl behaves the same way. Could you confirm your x86 Linux Perl 5.8.5 results again, and send me (privately if you wish) the output of: perl -MConfig=config_sh -we'print config_sh' from that perl? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl inefficiency...
Linda Walsh cygwin at tlinx.org writes: I understand perl may not be as efficient in data storage as C, but seems like expanding a 100MB string to take 200MB is wasting 100MB. Is this what you were referring to, Corinna? No, the inefficiency is that it stores the 100MB string in two separate places. It is definitely not using 2 bytes per ascii character in a single string. Try Corinna's script under strace -m malloc -o trace.out perl ... with a tail -F trace.out running in a separate window. -- I'm looking for a job: http://perlmonks.org/?node=ysth#looking -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl bug?
Corinna Vinschen wrote:
On Jan 22 11:26, Yitzchak Scott-Thoennes wrote:
Corinna wrote:
$a = a x (100 * 1024 * 1024);
sleep 5;
a -- malloc (2 bytes)
x 100 Megs -- realloc (100 Megs) + malloc (100 Megs)
So the result is that each string of 100 Megs requires 200 Megs of
memory. Doing this once is no problem, but doing it over and over
again will hit the maximum memory available twice as early.
This is as I would expect. Most operators have a target, a temporary
lexical, allocated to store their results. Like all lexicals, these
hold on to any memory they have allocated in the hope of saving having
to allocate it a second time.
The problem is that it's *not* reused. If you use strace when running
this script you see the allocations as I described them. When the
2 Gigs virtual memory size for the process are used up, mmap (which
is called by malloc for big memory chunks) is called and returns -1,
MAP_FAILED. Then malloc tries to get the memory from the heap, when
that fails, it just prints Out of memory!, munmaps half of the above
allocations and then exits.
Right, *each* x operation has it's own target. If you undef $a, $b, etc.
at the end and wrap the whole thing in a for (1..2) loop, you'll see the
second time round that space is only allocated once per statement.
Or just have one x operation, and only see the leaked memory allocated
once:
#!/usr/bin/perl
for ($a, $b, $c, $d, $e, $f, $g, $h, $h, $i, $j, $k, $l) {
$_ = a x (100 * 1024 * 1024);
sleep 5;
}
sleep 95;
x= doesn't behave the same way. It doesn't use the target, since it knows
where the result should go, so the following doesn't have the problem you
observed:
#!/usr/bin/perl
$a = a; $a x= (100 * 1024 * 1024);
sleep 5;
$b = b; $b x= (100 * 1024 * 1024);
sleep 5;
$c = c; $c x= (100 * 1024 * 1024);
sleep 5;
$d = d; $d x= (100 * 1024 * 1024);
sleep 5;
$e = e; $e x= (100 * 1024 * 1024);
sleep 5;
$f = f; $f x= (100 * 1024 * 1024);
sleep 5;
$g = g; $g x= (100 * 1024 * 1024);
sleep 5;
$h = h; $h x= (100 * 1024 * 1024);
sleep 5;
$h = h; $h x= (100 * 1024 * 1024);
sleep 5;
$i = i; $i x= (100 * 1024 * 1024);
sleep 5;
$j = j; $j x= (100 * 1024 * 1024);
sleep 5;
$k = k; $k x= (100 * 1024 * 1024);
sleep 5;
$l = l; $l x= (100 * 1024 * 1024);
sleep 100;
It is possible to free the memory used by targets, but only by putting the
code in an anonymous closure:
#!/usr/bin/perl
my $dummy;
{sub {
$dummy if 0;
$a = a x (1 * 1024 * 1024);
sleep 5;
$b = b x (1 * 1024 * 1024);
sleep 5;
$c = c x (1 * 1024 * 1024);
sleep 5;
$d = d x (1 * 1024 * 1024);
sleep 5;
$e = e x (1 * 1024 * 1024);
sleep 5;
$f = f x (1 * 1024 * 1024);
sleep 5;
$g = g x (1 * 1024 * 1024);
sleep 5;
$h = h x (1 * 1024 * 1024);
sleep 5;
$h = h x (1 * 1024 * 1024);
sleep 5;
$i = i x (1 * 1024 * 1024);
sleep 5;
$j = j x (1 * 1024 * 1024);
sleep 5;
$k = k x (1 * 1024 * 1024);
sleep 5;
$l = l x (1 * 1024 * 1024);
sleep 5;
}};
sleep 95;
$dummy forces the anonymous sub to be a closure, which gets it's own pad
(storage space for lexicals and targets) each time the sub{} is encountered
at runtime. Without it, the sub{} holds on to it's pad even after the
code reference it returns is freed.
There has been some work towards implementing a use less 'memory'; pragma
that may make perl less greedy, but there's no timetable for that or clear
plan for what it would do.
--
I'm looking for a job: http://perlmonks.org/?node=ysth#looking
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygwin source question
Dave Korn writes: On 21 January 2007 14:38, Christopher Layne wrote: I notice in some places, there are double-negates, like: me-read_ready |= ret || !!(events (FD_READ | FD_ACCEPT | FD_CLOSE)); What's the rationale for these? To enforce either a 0 or 1, to be directly in line with boolean, rather than a zero or non-zero result? It's a standard C idiom for that, yeh, it normalizes zero/non-zero into 0/1. Also protects against accidentally truncating true values to false (e.g. if events is an int and events |(FD_READ...) is 0x8000 and me-read_ready is a short, the implicit cast to short in the assignment turns 0x8000 into 0). This is also a Perl idiom (though Perl doesn't suffer the above problem). Some people prefer (expr) ? 1 : 0, which looks a lot worse to me than !!(expr). -- I'm looking for a job: http://perlmonks.org/?node=ysth#looking -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl bug?
Hi, consider the following statement: $a = a x (100 * 1024 * 1024) When you create a script which does this over and over again, you'll observe a strange memory problem. Can you show your script? By stracing I found that for each of these statements the following happens: a -- malloc (2 bytes) x 100 Megs -- realloc (100 Megs) + malloc (100 Megs) So the result is that each string of 100 Megs requires 200 Megs of memory. Doing this once is no problem, but doing it over and over again will hit the maximum memory available twice as early. This is as I would expect. Most operators have a target, a temporary lexical, allocated to store their results. Like all lexicals, these hold on to any memory they have allocated in the hope of saving having to allocate it a second time. I can only assume that either the garbage collector doesn't kick in when it should, or the garbage collector doesn't even know about this wasted memory, which would be a generic memory leak either way. However, it's not clear if this depends on the Perl version, or if it depends on the 64 bit int setting when building Perl. I'd more likely suspect differences in the usemymalloc setting (perl -V:usemymalloc). I'm not clear on exactly what you are seeing; again, I'd like to see your test script. -- I'm looking for a job: http://perlmonks.org/?node=ysth#looking -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: activestate perl on cygwin
Kevin T Cella kcella at nycap.rr.com writes: Using the version of perl installed with cygwin is not really an option since I already have scripts written that utilize windows specific modules. Out of curiousity, which modules are those? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl script dies with The instruction at
moka writes:
Larry Hall wrote:
Don't mix and match perl modules. If you're using Cygwin's perl, use modules
built and be sure _not_ to use any ActiveState Perl modules and vice-versa.
Well, I did not mean to mix. In fact I think I did not ask cygwin to install
perl, but I am not sure. I do not find any perl in c:\cygwin\bin
There is a perl file directory in c:\cygwin\lib though
I just didn't deinstall Activestate
Now when I do from a DOS prompt, even in a c:\cygwin subdirectory
which perl
I get back
\cygdisk\c\perl\bin\perl
which is C:\perl\bin\perl.exe, i.e. the activestate one
Originally I thought this was a path problem, i.e. if I put c:\perl\bin
first in the path, only the activestate perl would be used.
How are you starting your script? Can you put: print $^O: $]\n
or something at the beginning and verify for sure which perl you are using?
If you are accidentally running cygwin's perl and it's loading activestate
modules, uninstalling the perl packages should help.
If you are running activestate's perl and it is finding some cygwin perl
modules, that would cause a problem also. Adding something like:
BEGIN { unshift @INC, sub {
print join :, loading, @_, caller, \n;
return;
}; }
at the beginning of your script, that may help isolate the problem.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: perl script dies with The instruction at
Harold Fuchs harold at wolfeden.demon.co.uk writes: Yitzchak Scott-Thoennes wrote: How are you starting your script? Can you put: print $^O: $]\n or something at the beginning and verify for sure which perl you are using? At a command prompt (DOS/CMD or cygwin) do perl -version (no quotes). Not -v; spell it out in full. That will tell you, for each shell, which version of perl *perl* thinks is running. Then, if you have two different ones, remove the one you don't want. perl -v is identical in meaning to perl -version, and has been for a long long time. And that will tell you about the perl that gets invoked when you type perl foo.pl at a shell prompt, but won't tell you anything about what version of perl a particular script ends up using. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin 1.5.22 - cpan core dumping on initial
jake writes: $ cpan There seems to be running another CPAN process (pid 2064). Contacting... Other job not responding. Shall I overwrite the lockfile? (Y/N) [y] ... Fetching with Net::FTP: ftp://ftp.perl.org/pub/CPAN/authors/01mailrc.txt.gz Segmentation fault (core dumped) I have occasionally seen a corrupt local cpan database cause this kind of error, and it looks like you had a cpan process not shut down cleanly earlier. Try blowing away .cpan/Metadata, or even everything under .cpan. Also, avoid sharing your .cpan directory among multiple versions of perl (e.g. ActiveState and cygwin, or local builds of perl and the stock cygwin perl.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with perl debugger and stdin
On Sat, Dec 02, 2006 at 02:25:24PM -0800, Andrew Certain wrote: In a normal UNIX environment, you can run the perl debugger and still redirect an input file to stdin. In other words, perl -d myscript mydata does the right thing, namely, that you enter the debugger, the debugger reads input from the keyboard, but if the script reads from STDIN, it gets lines from mydata. Under cygwin, however, the same invocation causes the debugger to read commands from mydata. There's probably something the debugger is doing for linux but not for cygwin because it thinks cygwin can't do it, but a quick scan of perl5db.pl didn't reveal it to me. Doing PERLDB_OPTS=TTY=/dev/tty perl -d ... should work, though. Please include this line when replying. Is this some kind of behaviorist experiment? What's my prize? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl output dropped when invoking itself
On Tue, Nov 14, 2006 at 12:09:49PM -0500, Michael Adler wrote:
I'm having Perl I/O problems on one machine that keep me from getting
CPAN installations to work. On this machine if I execte:
perl -e 'print `perl -e require 5; print qq{VER_OK\n}`;'
from bash there is no output. On all my other machines it prints
VER_OK. ExtUtils::MM_Unix does this test and fails.
I've looked at all environment variables I can think of, especially
CYGWIN, and it is identical on a machine that works and one that fails.
Cygwin is up to date on both and Perl version is 5.8.7. I've tried
multiple values of the PERLIO variable with no success. Replacing the
inner invocation of perl with some other command, like cat of a file,
works on both machines! I tried blowing away the entire perl
environment and reinstalling.
I assume I'm missing something simple. Hints would be appreciated.
What do these do:
perl -e 'print `perl -v`'
perl -e 'print `perl -f -e require 5; print qq{VER_OK\n}`;'
perl -e 'print `perl -f -e print qq{VER_OK\n}`;'
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: fortune-1.99.1-2
On Wed, Oct 04, 2006 at 12:24:18PM +0200, Corinna Vinschen wrote: On Sep 11 19:10, Buchbinder, Barry (NIH/NIAID) [E] wrote: http://sourceware.org/ml/cygwin-apps/2006-01/msg00113.html Is it time to remove the test designation? I removed the test, curr and prev lines from setup.hint. Thanks.
Re: Perl's use locale don't work on Cygwin ?
Sergei Kolodka wrote:
YST Letting perl know what the encoding of your data is should enable /i
to work
YST correctly. How you would do this depends on what exactly you are
doing; it
YST may just require a use encoding 'cp1251';. (I assume 2151 was a
typo.)
Well, all I got was perfectly formed UTF8 output, and this is
not what I've been looking for because now I need somehow to
convert UTF8 input to CP1251 to be able to use for database
query and ... yes, again do case-insensitive regex on it.
I'm not sure what you mean by that last part, but if you need to
explicitly use it as cp1251, you'd do $cp1251_octets =
Encode::encode('cp1251', $data).
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
pathconf/fpathconf failing in some cases
The perl tests for pathconf/fpathconf are showing some failures (perl translates -1 to undef, and the fpathconf calls are made on an fd opened to the path mentioned in the following pathconf calls): 1..84 ok 1 - calling fpathconf(3, _PC_CHOWN_RESTRICTED) not ok 2 - checking that the returned value is defined: not ok 3 - checking that the returned value looks like a number ok 4 - calling fpathconf(3, _PC_LINK_MAX) ok 5 - checking that the returned value is defined: 8 ok 6 - checking that the returned value looks like a number ok 7 - calling fpathconf(3, _PC_NAME_MAX) ok 8 - checking that the returned value is defined: 260 ok 9 - checking that the returned value looks like a number ok 10 - calling fpathconf(3, _PC_NO_TRUNC) not ok 11 - checking that the returned value is defined: not ok 12 - checking that the returned value looks like a number ok 13 - calling fpathconf(3, _PC_PATH_MAX) ok 14 - checking that the returned value is defined: 260 ok 15 - checking that the returned value looks like a number ok 16 - calling pathconf(., _PC_CHOWN_RESTRICTED) not ok 17 - checking that the returned value is defined: not ok 18 - checking that the returned value looks like a number ok 19 - calling pathconf(., _PC_LINK_MAX) ok 20 - checking that the returned value is defined: 8 ok 21 - checking that the returned value looks like a number ok 22 - calling pathconf(., _PC_NAME_MAX) ok 23 - checking that the returned value is defined: 260 ok 24 - checking that the returned value looks like a number ok 25 - calling pathconf(., _PC_NO_TRUNC) not ok 26 - checking that the returned value is defined: not ok 27 - checking that the returned value looks like a number ok 28 - calling pathconf(., _PC_PATH_MAX) ok 29 - checking that the returned value is defined: 259 ok 30 - checking that the returned value looks like a number ok 31 - calling fpathconf(3, _PC_MAX_CANON) (/dev/tty) ok 32 - checking that the returned value is defined: 255 ok 33 - checking that the returned value looks like a number ok 34 - calling fpathconf(3, _PC_MAX_INPUT) (/dev/tty) ok 35 - checking that the returned value is defined: 255 ok 36 - checking that the returned value looks like a number ok 37 - calling fpathconf(3, _PC_VDISABLE) (/dev/tty) not ok 38 - checking that the returned value is defined: not ok 39 - checking that the returned value looks like a number ok 40 - calling pathconf(/dev/tty, _PC_MAX_CANON) ok 41 - checking that the returned value is defined: 255 ok 42 - checking that the returned value looks like a number ok 43 - calling pathconf(/dev/tty, _PC_MAX_INPUT) ok 44 - checking that the returned value is defined: 255 ok 45 - checking that the returned value looks like a number ok 46 - calling pathconf(/dev/tty, _PC_VDISABLE) not ok 47 - checking that the returned value is defined: not ok 48 - checking that the returned value looks like a number ok 49 - calling fpathconf(4, _PC_PIPE_BUF) (fifo3748) ok 50 - checking that the returned value is defined: 4096 ok 51 - checking that the returned value looks like a number ok 52 - calling pathconf(fifo3748, _PC_PIPE_BUF) ok 53 - checking that the returned value is defined: 4096 ok 54 - checking that the returned value looks like a number ok 55 - calling sysconf(_SC_ARG_MAX) ok 56 - checking that the returned value is defined or that errno is clear: 1048576 ok 57 - checking that the returned value looks like a number ok 58 - calling sysconf(_SC_CHILD_MAX) ok 59 - checking that the returned value is defined or that errno is clear: 63 ok 60 - checking that the returned value looks like a number ok 61 - calling sysconf(_SC_CLK_TCK) ok 62 - checking that the returned value is defined or that errno is clear: 1000 ok 63 - checking that the returned value looks like a number ok 64 - calling sysconf(_SC_JOB_CONTROL) ok 65 - checking that the returned value is defined or that errno is clear: 1 ok 66 - checking that the returned value looks like a number ok 67 - calling sysconf(_SC_NGROUPS_MAX) ok 68 - checking that the returned value is defined or that errno is clear: 16 ok 69 - checking that the returned value looks like a number ok 70 - calling sysconf(_SC_OPEN_MAX) ok 71 - checking that the returned value is defined or that errno is clear: 256 ok 72 - checking that the returned value looks like a number ok 73 - calling sysconf(_SC_PAGESIZE) ok 74 - checking that the returned value is defined or that errno is clear: 65536 ok 75 - checking that the returned value looks like a number ok 76 - calling sysconf(_SC_SAVED_IDS) ok 77 - checking that the returned value is defined or that errno is clear: 0 but true ok 78 - checking that the returned value looks like a number ok 79 -
Re: Permission denied Permission denied Permission denied Permission denied Permission denied Permission denied
On Thu, Aug 10, 2006 at 03:53:55PM +1200, Steve Keate wrote: Are there any useful resources on finding out exactly what security mode to choose when using Cygwin, also, are there any resources on how to use mkpasswd and what arguments to use. I have scoured the net for two days looking for anything. Is cygwin now abandonware, or is support just abyssmally poor? http://isbn.nu/0671723650 Only a very brief period of scouring the net should have led you to the conclusion that this list is the primary vehicle for support. Since the list archives should indicate to you that there is a great deal of traffic on this list, I'm at a loss to know where the abandonware comes from. And since this is apparently your first effort at asking for help, the same goes for abyssmally (sic) poor. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Where is complex.h
On Mon, Jul 24, 2006 at 01:36:47PM -0700, TV JOE wrote: Hi, I've a C program referencing complex.h. But make can't find it and the only copy I see is in /usr/include/mingw which I don't think is the right version. Advice welcomed. Comment out the complex.h, see what errors you get, and implement the needed functions yourself? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Perl failure
Thanks for the suggestion, I tried it with 1.5.20 and 1.5.21s 20060718. But Alas no better luck. Any Idea if this is Cygwin or Perl? I'm betting on cygwin. I hope to look more into this soon. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl failure
On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote: Hi, I have a server that has been doing back end maintenance using perl on cygwin for 6 years now. I recently upgraded from win2k and cyg1.5.9 to XP sp3 and cyg1.5.19 (to be fare, I also cleaned up the perl code a bit). The script checks versioning and build info on about 600+ windows systems. Since the upgrade, it gets thru about 500 of them ( almost exactly 2 hours) and then: panic: MUTEX_LOCK (45) [util.c:2266] at /c/dist_and_install_files/source/dist2/spUpdate2d.pl line 24, HOSTFILE line 277. panic: MUTEX_LOCK (45) [op.c:354], HOSTFILE line 277. This indicates EDEADLK being returned from posix_mutex_lock. It hits a slightly different time and position in the list each time, but always after approximately 2 hours. I found a few old mails suggesting rebaseall, which I ran to no effect. The system pretty much runs nothing but this. I've been running a version of this script since cyg1.3.9 and never had a problem like this one. Any suggestions? Can you revert one or more of the many things you changed, and see if it makes a difference? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl failure
On Thu, Jul 13, 2006 at 08:53:09AM -0700, Yitzchak Scott-Thoennes wrote: On Wed, Jul 12, 2006 at 05:08:43PM -0700, Bruce Dobrin wrote: Hi, I have a server that has been doing back end maintenance using perl on cygwin for 6 years now. I recently upgraded from win2k and cyg1.5.9 to XP sp3 and cyg1.5.19 (to be fare, I also cleaned up the perl code a bit). The script checks versioning and build info on about 600+ windows systems. Since the upgrade, it gets thru about 500 of them ( almost exactly 2 hours) and then: panic: MUTEX_LOCK (45) [util.c:2266] at /c/dist_and_install_files/source/dist2/spUpdate2d.pl line 24, HOSTFILE line 277. panic: MUTEX_LOCK (45) [op.c:354], HOSTFILE line 277. This indicates EDEADLK being returned from posix_mutex_lock. Err, I mean pthread_mutex_lock. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Crashes/defunct processes after upgrade to cygwin-1.5.20
On Tue, Jul 11, 2006 at 02:46:58PM +0100, Dave Korn wrote: On 11 July 2006 14:12, Harald Anlauf wrote: Corinna, Nope, I'm not Corinna! I have now attached the output of cygcheck of my system that should be current except for cygwin1 which 1.5.19-4. I have verified that there was and is no other cygwin1.dll, neither in PATH nor elsewhere. #!/usr/bin/csh There is no such thing as /usr/bin/csh in the cygwin distribution. cat EOF Hello world! EOF % ./cygwin-csh-bug cat: -: Bad file descriptor cat: closing standard input: Bad file descriptor % echo $? 1 The cygwin version of the C-shell is called 'tcsh'. You perhaps have some kind of bogus shell script in /usr/bin that's pretending to be csh and is attempting to translate and forward the command line args to the real tcsh and is getting confused? I know I'm going out on a limb here, but could the csh in /usr/bin be the one created by the tcsh postinstall script? :) Try deleting /usr/bin/csh.exe.lnk and re-running /etc/postinstall/tcsh.sh.done. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is anything getting through to the list?
On Tue, Jul 11, 2006 at 10:21:51AM -0400, Chuck wrote: I have been trying to post a question to this list for over a week and it never appears, not does it bounce back indicating a problem. I've tried to email the list owner and haven't gotten any help there either. I guess I have to run my own test to see if this gets through. I apologize if this test goes out to the whole list but I don't seem to have any other choice. Twisted your arm, did they? Out of curiousity, where did you look for instructions to email the list owner? My original question that has disappeared some 6 or 7 times now was simply where is the cal utility. I've done a search on the packages but can't find it. Does it even exist? I thought I remembered using it in cygwin a while back. http://cygwin.com/packages/, search for bin/cal. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FW: Cygwin Perl bug -- pod2usage(-verbose = 0) pod2usage(-verbose = 1)
On Sun, Jul 09, 2006 at 04:35:29PM -0700, David Christensen wrote: Cygwin Perl: This issue is still present. Reini's PERLIO suggestion functions as a work-around on Cygwin. Who decides if/when to use Reini's suggested patch? If that decision has already been made in the negative, why and what is the next step? If that decision has already be made in the positive, when will we see the correction in Cygwin? I'm building an updated perl package, and will include this patch and try to get it included upstream. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: In scripts suddenly must use perl.exe rather than perl
On Sun, Jul 09, 2006 at 10:38:19PM +, zzapper wrote:
Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
On Sun, Jul 09, 2006 at 12:23:24PM +, zzapper wrote:
Hi,
I have a few (ancient) shell scripts which call perl scripts (which
perform MySql queries), since a few days these have stopped working
(may have been since recent coreutils update)
What does stopped working mean?
YST
I just get no output from the perl (doesn't produce any error)
c:/usr/local/bin/perl sdbk.pl $* (hard path to activestate perl)
to get them working again I have to change perl to perl.exe
c:/usr/local/bin/perl.exe sdbk.pl $*
What happens when you try running them directly from a shell prompt
(using the same shell as your shell script)?
It's just the same
What does sdbk.pl do? If you put a
BEGIN { print started!\n; }
line at the beginning, does it print it?
cygcheck output?
Do you want all?
cygcheck -s
Sorry, should have been more explicit. Bug reports should be accompanied
by cygcheck -srv output, attached as a text attachment, not inline.
Where did you actually install activeperl? And what output do you get from:
ls -l c:/usr/local/bin
(It's kind of odd that you have a /usr/local/bin set up outside of
c:/Cygwin.)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: In scripts suddenly must use perl.exe rather than perl
On Sun, Jul 09, 2006 at 12:23:24PM +, zzapper wrote: Hi, I have a few (ancient) shell scripts which call perl scripts (which perform MySql queries), since a few days these have stopped working (may have been since recent coreutils update) What does stopped working mean? c:/usr/local/bin/perl sdbk.pl $* (hard path to activestate perl) to get them working again I have to change perl to perl.exe c:/usr/local/bin/perl.exe sdbk.pl $* Havn't been lurking here recently but is this a known problem or brain- failure on my part? What happens when you try running them directly from a shell prompt (using the same shell as your shell script)? cygcheck output? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug list posted on alpha centauri for 50 years!
Dave Korn wrote: That's a false positive and you're about the fifteenth person this month to report it to the list without having bothered to search the archives first. --- Yeah -- the buglist has been clearly posted on Alpha Centauri for the past 50 years. There's no reason why anyone should know the contents of said list! Darn Vogon! Given an average shoulder height of 4.6 feet, you only need a stack of 30 quadrillion hippos to get there. -l Every time I see that, I think at first it's the number one less than zero. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Which list should cygwin development be discussed on ?
On Sat, Jul 01, 2006 at 01:28:08PM -0700, [EMAIL PROTECTED] wrote: And of course the discussion and methodology behind the internal development of the cygwin libraries, issues, and future ideas is - in true opensource form (NOT) - on a completely closed list, invite-only, with no public access to any form of archives. Where do you get invite-only from? Seems directly contradicted by what you go on to quote. What exactly is the positive purpose behind that? cygwin-developers: a by-approval developers list for discussing the internals of the Cygwin DLL and all components of the winsup directory. Discussions of upcoming net releases are also appropriate. Subscription requests are handled on a case-by-case basis. Only subscribers may submit email to this list. Please do not attempt to join the cygwin-developers mailing list unless 1) you are thoroughly familiar with the cygwin DLL, 2) you have successfully built the DLL from source, 3) you contributed at least one patch to the Cygwin DLL or its utilities, and 4) you intend on being a long-term contributor. Please do not ask for read-only access to this mailing list. You either qualify or you don't. There is no middle ground. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Copyright Assignment received from Yitzchak Scott-Thoennes
On Thu, Feb 17, 2005 at 09:50:42AM +0100, Corinna Vinschen wrote: Patch as patch can, Yitzchak! I started with a new employer at the end of April, and have been expecting to get an assignment from them any day now. But since it's been so long I thought I'd let you all know.
Re: CygPerl hangs opening FIFO after fork (in both parentchild)
On Thu, Jun 22, 2006 at 06:53:38PM -0700, Brian Dessent wrote: Linda Walsh wrote: The attached test case is simple and fairly short. It does not depend on File::BOM (and has none of the code from it). It's only dependency (other than perl) is the POSIX module, where, from, the fifo command is taken. This appears to be a deadlock in the Cygwin DLL when both the reader and writer end of a fifo tries to open the file at the same time (or nearly the same time.) They end up signaling each other to ask about the other end of the pipe, and hang there. It has nothing to do with perl or fork, as far as I can tell -- the attached C testcase will work fine if the reader end sleeps briefly to ensure the opening order. It's just a classic race condition somewhere. Good job isolating this problem, Linda and Brian. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Maintainer searched
On Tue, Jun 13, 2006 at 12:36:46PM +0200, Corinna Vinschen wrote: On May 4 18:06, Yitzchak Scott-Thoennes wrote: On Wed, May 03, 2006 at 10:24:19PM +0200, wrote: Hello, there is not enough time to maintain all my packages. Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). If it's ok with you, I'll take perl. Since there hasn't been much movement lately, I tracked which of Gerrit's packages have been actually taken over. As I see it now, the following packages remain to be taken over, please correct me if I missed something: antiword check Yaakov S? db* Max Bowsher? enscript exif expat Max Bowsher? freeglut gcc*Dave Korn? gconf2 gnutls* indent jasper libdb* libexif* libfpx libgnutls11 libmng libopencdk8 libtasn1 libwmf libxml2*Yaakov S? libxslt Yaakov S? opencdk openjade opensp perl,perl_manpages Yitzchak Scott-Thoennes? I'd like to ask Yaakov, Max, Dave and Yitzchak, are you taking over, or are you still considering to take over? It would be nice to have that sorted out. Unless Gerrit objects (and he seems to have stopped responding to mail, so that seems unlikely) I'm taking over. I should have a release of perl 5.8.8 ready soon.
Re: cygwin non-posix problems
Linda Walsh wrote: Yitzchak Scott-Thoennes wrote: Can he or you reduce the problem to a non-File::BOM dependent test script What part of the perl module File::BOM should I throw out before it's no longer File::BOM? It's just perl code. It's freely downloadable through CPAN, so I can't make it too much more publicly available than that. The point would be to reduce the amount of code that might need to be inspected to find the underlying problem. Nothing to do with publicly available. But FWIW, the File::BOM code isn't the actual problem. It's the authors test routine that he decided to be fancy with, and use a child process to send strings via a FIFO to the test harness process. It isn't desirable to modify cygwin-only-failing Perl modules to work around problems than only happen under cygwin. Certainly you can see how that is burying one's head under the sand. Suppose various parts of CPAN are rewritten to steer around bugs in Cygwin. Does that make the underlying problems problems in Cygwin go away? Does that make cygwin more stable or more compatible with other Posix platforms? In my mind it eliminates test cases that are perfectly uncovering Cygwin incompatibilities and deficiencies. I agree with all of the above and wasn't trying to suggest modifying the tests. Another example is the Win32::API module? It also fails under cygwin -- starting about 9 months ago. Still does. The problems in cygwin aren't going away. And when module developers get bugs reported under cygwin, they may not bother with them if cygwin is known to have many Posix compatibility problems. I didn't know posix compatibility problems were at issue there? And I don't think posix compatibility ranks high in importance for Win32::API. The module maintainers would like nothing more than for their module to work w/o problems on all platforms. Perl goes to great lengths to ensure it just works, out-of-the-box on scores of platforms. Also, FWIW, I did report a simpler test case that came up during their continued attempts to isolate the problem: ([perlbug #39325]: Cygperl allows reading of file descriptors open Write-Only) I don't know if the above bug is somehow the root cause of the problem in File::BOM but I doubt it is solely responsible for the behaviors I'm seeing, including cygperl hanging and being unkillable from within cygwin. Certainly, we can agree, that a process under cygwin should not normally hang and be unresponsive to cygwin kill -9 signals? /bin/kill -f worked for me. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin fork problem maybe?
On Tue, Jun 06, 2006 at 01:30:43PM -0700, Linda W wrote: A problem I reported in trying to install File::BOM (module to handle files with Unicode Byte-Order-Marks) under CPAN originally here: http://sourceware.org/ml/cygwin/2006-02/msg00238.html last February is still a problem. I bounced it off of the module maintainer, and he believes the problem has to do with forking, not FIFO use. His test works under AS Perl, but he doesn't think he'll be able to get his module to work under cygwin with these problems. Can he or you reduce the problem to a non-File::BOM dependent test script? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Reading Term::ReadKey support for ActiveState Perl and Cygwin
On Sun, May 21, 2006 at 09:39:16PM -0400, Igor Peshansky wrote: On Mon, 22 May 2006, Paul Dorman wrote: Hi all, I've been racking my brains trying to read keystrokes in a Cygwin shell with ActiveState Perl. Has anyone worked out how to read individual keystrokes with a Perl script running in a Cygwin shell or SSH session? We have standardized on ActiveState perl here (as not all servers are actually running Cygwin). Windows applications (like ActivePerl) are mostly off-topic on this list, especially since there's a perfectly good Cygwin alternative available (which, BTW, comes with Term::ReadKey). However, you do realize that a Perl script running in a Cygwin shell or SSH session may not even be running in a terminal as ActivePerl understands it, right? Hence his question, I believe. I'd think ways of making a windows app happy with pty stdin/stdout would be on-topic (though in most cases, changes to the windows app seem to be not an option, so there's not much to talk about.) Paul, can you show what you've tried, and what exactly is the trouble spot? If people really think it's not appropriate to discuss here, perhaps you could ask at: http://perlmonks.org/?node=Seekers+of+Perl+Wisdom. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl reading ^M on text mounts
On Sun, Apr 23, 2006 at 12:28:52PM +, Michael Lemke wrote: Dave kilroyd at googlemail.com writes: Have you tried setting the environment variable PERLIO? I'm not a heavy PERL user, but I tend to have PERLIO=crlf if I'm likely to see CRLFs. Thanks, I tried that. It indeed seems to remove the \r but independent of the mount mode of the disk. I googled a bit and found an old thread about this where Max Bowsher sums it up in http://www.mail-archive.com/cygwin@cygwin.com/ msg22668.html What a mess. And no solution it seems. The perl docs say a simple open X, file; opens the file in text mode. So I expect the subsequent read (and chomp) to treat a \r according to mount mode of the file system. PERLIO=crlf changes it for all files. Is it just me or do other people also feel this is broken? Yes, it's broken, but with no good solution that I know of. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Call for testing Cygwin snapshot
On Wed, May 10, 2006 at 01:38:58AM -0400, Christopher Faylor wrote: On Tue, May 09, 2006 at 10:30:50PM -0700, Yitzchak Scott-Thoennes wrote: On Tue, May 02, 2006 at 08:50:59PM -0700, Yitzchak Scott-Thoennes wrote: On Tue, May 02, 2006 at 11:47:09AM -0400, Christopher Faylor wrote: On Mon, May 01, 2006 at 11:11:57PM -0700, Yitzchak Scott-Thoennes wrote: On Mon, Apr 24, 2006 at 08:12:42PM +0200, Corinna Vinschen wrote: Please test the latest snapshot (at least 2006-Apr-24) from http://cygwin.com/snapshots/ Please report back in this thread when you encounter a problem, which you can't reproduce with 1.5.18 or 1.5.19. We're interested in regressions in the first place. I'm having problems with rsync'ing perl seeming to hang that didn't happen with 1.5.18/9 or snapshots up to 20060329. I'll try to post cygcheck output soon. Corinna changed ssh recently. Are you using the new version? No, not using ssh at all. Just: rsync --delete -avz public.activestate.com::perl-current perl cygcheck attached (after backing down to 20060329). I was mistaken. It is working in 20060403 and hangs in 20060412 and every snapshot afterward. Would you be willing to try building a cygwin DLL with Corinna's 2006-04-04 Corinna Vinschen [EMAIL PROTECTED] * net.cc (fdsock): Raise default SO_RCVBUF/SO_SNDBUF buffer sizes to the same values as on Linux. change reverted and see if that changes things? That's the only thing in the 20060412 that I can see which would make a difference. Yes, removing the setsockopt calls from fdsock does get rsync working again. Sorry it took me so long to try. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Call for testing Cygwin snapshot
On Wed, May 10, 2006 at 01:38:58AM -0400, Christopher Faylor wrote: On Tue, May 09, 2006 at 10:30:50PM -0700, Yitzchak Scott-Thoennes wrote: On Tue, May 02, 2006 at 08:50:59PM -0700, Yitzchak Scott-Thoennes wrote: On Tue, May 02, 2006 at 11:47:09AM -0400, Christopher Faylor wrote: On Mon, May 01, 2006 at 11:11:57PM -0700, Yitzchak Scott-Thoennes wrote: On Mon, Apr 24, 2006 at 08:12:42PM +0200, Corinna Vinschen wrote: Please test the latest snapshot (at least 2006-Apr-24) from http://cygwin.com/snapshots/ Please report back in this thread when you encounter a problem, which you can't reproduce with 1.5.18 or 1.5.19. We're interested in regressions in the first place. I'm having problems with rsync'ing perl seeming to hang that didn't happen with 1.5.18/9 or snapshots up to 20060329. I'll try to post cygcheck output soon. Corinna changed ssh recently. Are you using the new version? No, not using ssh at all. Just: rsync --delete -avz public.activestate.com::perl-current perl cygcheck attached (after backing down to 20060329). I was mistaken. It is working in 20060403 and hangs in 20060412 and every snapshot afterward. Would you be willing to try building a cygwin DLL with Corinna's 2006-04-04 Corinna Vinschen [EMAIL PROTECTED] * net.cc (fdsock): Raise default SO_RCVBUF/SO_SNDBUF buffer sizes to the same values as on Linux. change reverted and see if that changes things? That's the only thing in the 20060412 that I can see which would make a difference. Yes, that looked like a possibility to me too. I'll try it tonight or tomorrow night. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Call for testing Cygwin snapshot
On Tue, May 02, 2006 at 08:50:59PM -0700, Yitzchak Scott-Thoennes wrote: On Tue, May 02, 2006 at 11:47:09AM -0400, Christopher Faylor wrote: On Mon, May 01, 2006 at 11:11:57PM -0700, Yitzchak Scott-Thoennes wrote: On Mon, Apr 24, 2006 at 08:12:42PM +0200, Corinna Vinschen wrote: Please test the latest snapshot (at least 2006-Apr-24) from http://cygwin.com/snapshots/ Please report back in this thread when you encounter a problem, which you can't reproduce with 1.5.18 or 1.5.19. We're interested in regressions in the first place. I'm having problems with rsync'ing perl seeming to hang that didn't happen with 1.5.18/9 or snapshots up to 20060329. I'll try to post cygcheck output soon. Corinna changed ssh recently. Are you using the new version? No, not using ssh at all. Just: rsync --delete -avz public.activestate.com::perl-current perl cygcheck attached (after backing down to 20060329). I was mistaken. It is working in 20060403 and hangs in 20060412 and every snapshot afterward. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Maintainer searched
On Wed, May 03, 2006 at 10:24:19PM +0200, Gerrit P. Haase wrote: Hello, there is not enough time to maintain all my packages. Who wants to maintain one or more of my packages, maybe Yaakov wants to take over some of the GTK+ related packages? Then there are some more major packages which really require a maintainer with more time than I have (i.e. GCC, Perl). If it's ok with you, I'll take perl.
Re: Call for testing Cygwin snapshot
On Mon, Apr 24, 2006 at 08:12:42PM +0200, Corinna Vinschen wrote: Please test the latest snapshot (at least 2006-Apr-24) from http://cygwin.com/snapshots/ Please report back in this thread when you encounter a problem, which you can't reproduce with 1.5.18 or 1.5.19. We're interested in regressions in the first place. I'm having problems with rsync'ing perl seeming to hang that didn't happen with 1.5.18/9 or snapshots up to 20060329. I'll try to post cygcheck output soon. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how t o read env variable in cygwin
On Mon, Mar 27, 2006 at 10:12:01AM -0500, Igor Peshansky wrote:
On Mon, 27 Mar 2006, Eric Blake wrote:
According to cyg_win_user on 3/27/2006 3:12 AM:
i m trying to read environment variable in perl using
$OSTY = $ENV{OSTYPE};
this will return os type as linux or solaris. but when i try for
cygwin it returns empty string. is the some other syntax of way of
finding value of env variable in cygwin
What shell are you using? OSTYPE is auto-set to cygwin by bash, but
not by other shells (including if you are starting perl directly from
cmd.com). Rather than reading an environment variable that is not
standardized and might not be set, you could always use 'uname -s'
instead.
Or use Perl's builtin $^O variable, which should be auto-set to cygwin
(all lowercase). man perlvar for more info.
All the possible values of $^O are listed in man perlport.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: PING binutils maintainer (was: Re: Can we get a new release of binutils?)
On Wed, Mar 22, 2006 at 01:20:09PM -0500, Christopher Faylor wrote: On Wed, Mar 22, 2006 at 10:00:52AM -0800, Yitzchak Scott-Thoennes wrote: On Mon, Mar 06, 2006 at 09:17:37AM -0800, Yitzchak Scott-Thoennes wrote: Can we get a new release of binutils? Nope. cgf OK. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
PING binutils maintainer (was: Re: Can we get a new release of binutils?)
On Mon, Mar 06, 2006 at 09:17:37AM -0800, Yitzchak Scott-Thoennes wrote: Can we get a new release of binutils? Thanks. See: http://www.cygwin.com/ml/cygwin/2006-02/msg00758.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Can we get a new release of binutils?
Can we get a new release of binutils? Thanks. See: http://www.cygwin.com/ml/cygwin/2006-02/msg00758.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
(ATTN: binutils maintainer) Re: cygwin ld --out-implib treats informational message as warning
Can cygwin binutils be updated to include this patch? Thanks. On Fri, Jan 27, 2006 at 05:26:37PM +, Nick Clifton wrote: Hi Yitzchak, 2006-01-27 Yitzchak Scott-Thoennes [EMAIL PROTECTED] * pe-dll.c (pe_dll_generate_implib): Issue Creating library file: as informational message, not warning Approved and applied. Cheers Nick PS. We might as well leave the message in for now. I see no reason for the linker not to be informative if the user has requested it.
Re: cygheap base mismatch detected
On Tue, Feb 21, 2006 at 09:25:45AM -0600, Dill, Jens (END-CHI) wrote: (2) Rebase the CygWin DLL so that it loads by default into a space not used in either memory map (I'd need help in choosing such a space). I've tried both Microsoft's rebase and CygWin's rebase, but the documentation for both is scanty (how is the -b argument to be formatted -- a hex number with 0x in front or without?), and the error messages I get in response are not helpful (error 6?). cygcheck -l rebase | grep README | xargs less -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygheap base mismatch detected ( Attn: rebase maintainer )
Jason, are you following this?
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote:
We are finally zeroing in on the problem.
Mark Geisert writes:
The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
offset 0x80
in the image. This was true in the early Windows days but has long since
been
generalized. The technique nowadays is to obtain the short integer value
e_lfanew
at offset 0x3C in the image, and use that as the offset to check for the
signature.
I dumped out a couple of dlls in hex to see if they supported Mark's
assertion.
Yes, indeed. And I was able to verify (see below) that all the DLLs that
were linked into my app and were not touched by rebase, in fact has
something
other than 0x0080 in that position of the image (see below).
I also did some experimentation that makes me much more certain that
a repaired rebase will fix the problem. The rebase documentation
talks about the fact that rebase exists to fix problems when one
process forks another that has the same DLLs based at an incompatible
address. This appears to be what is happening to my app.
I have verified that if any CygWin shell tries to launch my app (either
by fork/exec or just by exec), or if my my app tries to launch a CygWin
shell, we get the identical cygheap base mismatch problem. If the
launch is indirect (via a Windows .bat file), there is no problem.
So, I have a workaround of sorts. I can have my script launch my app
by writing the command line to a .bat file and executing it. Definitely
not something I can use to convince my management to go with CygWin.
(The latest word was that our VP thinks that there is no enterprise app
out there that uses cygwin so he is skeptical too.)
I finally found where to get the rebase source, and verified that in fact,
what Mark noticed in 2.3.1 is still true in 2.4.2-1. I can easily make the
obvious fix and change the is_rebaseable function to get the
pe_signature_offset
out of position 0x3c in the image rather than assuming it is 0x80.
But that only affects the bit of the code that decides if a DLL is
rebaseable. I would need more time and knowledge to convince myself
that the code that actually does the rebasing is not making the same
mistake.
It seems that there is indeed more to it. I did make the obvious change
and reran rebaseall. The message I got from the first Oracle DLL
it encountered was:
ReBaseImage (/cygdrive/d/oracle/app/oracle/product/9.2.0/bin/orasql9.dll)
failed with last error = 6
I can't do more without learning a lot more than I currently know
about the internals of DLLs and of rebase.
But, let us assume for the moment, that we have found the problem,
that someone can fix rebase, and we can use it to keep out of trouble.
How shall I represent this to my management?
Can someone tell me how long it might take for the fix to get into
a stable CygWin release? My management may be willing to use an
uncertified release for a short while, and even may be willing to
own the responsibility for making the change to rebase, but they'll
want to know how long they have to wait for it to be official.
And if rebase solves the problem, I presume we have to do it
after we've installed Oracle and before we run any of our apps.
What happens if we or one of our customers reinstalls Oracle?
Do we have to make sure that rerunning rebaseall is part of
the drill? The doc for rebase says:
WARNING
Note it is *strongly* recommended that users only use rebaseall unless
they *really* know what they are doing or are instructed by one of the
Cygwin developers.
/WARNING
Not something we want to have to hand off to our customers, or
even to our installation techs if we can avoid it.
-- Jens
below this line is the code I used to peek at our DLLs, and the results
---
$ cat dllpeek.c
#include stdlib.h
#include stdio.h
int main(int argc, char * * argv)
{
while (argc--)
{
int rc = 0;
unsigned char at3C[2];
char signature[4];
char * fname = *++argv;
FILE * fp = fopen(fname,rb);
if (!fp)
{ fprintf (stderr, %s: could not open file\n, fname);
continue;
}
rc = fseek(fp, 0x3c, SEEK_SET);
if (rc)
{ fprintf (stderr, %s: fseek returned %d\n, fname, rc);
continue;
}
rc = fread (at3C, 2, 1, fp);
if (rc != 1)
{ fprintf (stderr, %s: could not read at 0x3c\n, fname);
continue;
}
fprintf (stdout, %s: %02x%02x\n, fname, at3C[1], at3C[0]);
}
return 0;
}
$ ~/dllpeek.exe $(cygpath -u $(cygcheck ./acqjob.exe))
./acqjob.exe: 0080
/cygdrive/d/oracle/app/oracle/product/9.2.0/bin/orasql9.dll: 00e0
Re: cygwin ld --out-implib treats informational message as warning (attn: binutils maintainer)
Can cygwin binutils be updated to include this patch? Thanks. On Fri, Jan 27, 2006 at 05:26:37PM +, Nick Clifton wrote: Hi Yitzchak, 2006-01-27 Yitzchak Scott-Thoennes [EMAIL PROTECTED] * pe-dll.c (pe_dll_generate_implib): Issue Creating library file: as informational message, not warning Approved and applied. Cheers Nick PS. We might as well leave the message in for now. I see no reason for the linker not to be informative if the user has requested it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygheap base mismatch detected
On Sat, Feb 18, 2006 at 09:12:02PM -0600, Dill, Jens (END-CHI) wrote: So, I have a workaround of sorts. I can have my script launch my app by writing the command line to a .bat file and executing it. Definitely not something I can use to convince my management to go with CygWin. Wouldn't just system(cmd /c yourapp) work instead of writing a bat file? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CPAN: issues with homedirs containing spaces; how to install globally?
On Fri, Feb 17, 2006 at 02:32:22AM -0500, [EMAIL PROTECTED] wrote: Hi all, I think there's a bug with cpan and names containing spaces. Please report bugs in CPAN.pm to [EMAIL PROTECTED] This isn't unique to cygwin. I suggest you remove the space. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: The purpose of /etc/default ?
On Wed, Feb 08, 2006 at 06:29:40PM +0200, Jari Aalto wrote: The package contributors guide http://cygwin.com/setup.html Is silent about /etc/defaults. As is FHS 2.3. I don't even see any discussion of /etc/defaults on the FHS discussion list. /usr/share/foo/ may be a more appropriate place, depending on whether you view these files as configuration files (since their content is that of a configuration file) or data files (since they aren't actually *used* as configuration files, just compared to the live conf file and potentially copied to become the live configuration file). In Debian this directory has specific meaning: http://www.debian.org/doc/debian-policy/ch-opersys.html 9.3 System run levels and init.d scripts 9.3.2 Writing the scripts Often there are some variables in the init.d scripts whose values control the behaviour of the scripts, and which a system administrator is likely to want to change. As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in /etc/default, which typically will have the same base name as the init.d script. This extra file should be sourced by the script when the script runs. What does /etc/defaults mean under Cygwin? This should be documented in the package contributors guide as well. I think debian is on firmer ground than cygwin in putting files in /etc/defaults since they are sourced extensions of the real configuration files.
Re: make: rm: command not found
On Sat, Feb 11, 2006 at 03:15:37AM -0800, Tim Prince wrote: At 08:40 AM 2/10/2006, JefV wrote: -- View this message in context: http://www.nabble.com/make%3A-rm%3A-command-not-found-t1100243.html#a2873151 Sent from the Cygwin Users forum at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ SPAM: -- Spamnix Spam Report -- SPAM: Spamnix identified this message as spam. SPAM: Score: 52 SPAM: Action: Quarantine SPAM: --- End of Spamnix Spam Report -- How many of us do you expect to be viewing your message with spam filtering off? Why should your spam filtering be of any concern to anyone posting to the list? Perhaps if you were to figure out what contributed to that 52 score and make a concrete suggestion, it would be helpful. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: default PATH
On Sun, Feb 12, 2006 at 11:57:00AM -0500, Christopher Faylor wrote: If we don't get a single person indicating that they rely on the current behavior then I'm ok with changing it. We have a patch ready to be checked in, in fact. I assume that: $ PATH=/foo::$PATH cmd /c printenv PATH will continue to show /foo:./:yaddayadda with the patch? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange cygstart bug with current Cygwin versions
On Mon, Feb 06, 2006 at 11:40:22PM +0100, Michael Schaap wrote: What we basically need to do, is copy the Cygwin environment to the Windows environment, taking care of path conversion for all the appropriate variables. Maybe start with: http://www.cygwin.com/ml/cygwin-patches/2005-q4/msg9.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: readdir after rewinddir not working in 20060128 snapshot
On Mon, Jan 30, 2006 at 11:39:48AM +0100, Corinna Vinschen wrote:
On Jan 30 00:29, Yitzchak Scott-Thoennes wrote:
After a rewinddir, readdir seems to return as many empty entries as there
were actual entries left to read, followed by . and ..
Thanks for the testcase! Since the underlying NT call NtQueryDirectoryInfo
is able to return more than one directory entry in one call, I thought it
might be a good idea to implement readdir caching. Unfortunately I forgot
to reset the cache in case of rewinddir. I've applied a fix now.
Thanks, but..
With 20060202, that testcase now works, but if you read all the way to
the end, then rewind, you only get . and .. thereafter.
$ cat rewdir.c
#include stdio.h
#include dirent.h
#include errno.h
#include string.h
void readentries(DIR *dh, int limit) {
struct dirent *de;
int count;
for (count = 0; count limit; ++count) {
errno = 0;
if ((de = readdir(dh)) == NULL) {
if (errno != 0) printf (read error: %s\n, strerror (errno));
break;
}
printf (got: %s\n, de-d_name);
}
}
int main(int argc, char **argv)
{
DIR *dh;
int i;
if (argc != 2) return 1;
if ( (dh = opendir (argv[1])) == NULL ) {
fprintf (stderr, couldn't open '%s': %s\n, argv[1], strerror (errno));
return 1;
}
for (i = 0; i 3; ++i) {
readentries (dh, );
printf (rewinding.\n);
errno = 0;
rewinddir (dh);
if (errno != 0) printf (unexpected errno: %d\n, errno);
}
return 0;
}
$ rm -rf foo; mkdir foo; touch foo/{bar,baz,quux,quuux,qx}
$ gcc -Wall rewdir.c -o rewdir ./rewdir foo
got: .
got: ..
got: bar
got: baz
got: qx
got: quuux
got: quux
rewinding.
got: .
got: ..
rewinding.
got: .
got: ..
rewinding.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: g-b-s patch: upstream patch list
On Mon, Jan 30, 2006 at 10:45:10AM -0500, Igor Peshansky wrote: 2006-01-30 Eric Blake ebb9atbyu.net * templates/generic-build-script: Add ability to apply upstream patches, listed in CYGWIN-PATCHES/upstream_patches.lst. Now, for the upstream patches functionality, I think it would be easier if I actually posted my changes and we could compare on-list. I'll clean them up and post them in the next couple of days. FWIW, when I looked at this, it looked easiest just to apply the patches in unpack().
Re: /proc/pid/exe points to void
On Tue, Jan 24, 2006 at 06:45:28PM +0100, Corinna Vinschen wrote: On Jan 20 13:50, Sam Steingold wrote: On Mar 10 16:00, Sam Steingold wrote: /proc/pid/exe points to foo, not to foo.exe, so it cannot be opened c. how do I find out which file is running if /proc/pid/exe cannot be opened? access(2) or stat(2) http://www.opengroup.org/onlinepubs/009695399/functions/access.html the above spec of access appears to indicate that if access() succeeds then open() must succeed too. this is not the case in cygwin: /proc/self/exe cannot be open()ed. I've just checked in a patch which tacks on the .exe suffix to /proc/$PID/exe, as well as a patch to realpath which returns the pathname with .exe suffix, even if the original name has no suffix given. We will give this a try. Please test the next snapshot. Mostly for the archives, I note that this makes perl's $^X variable include the .exe suffix. This is probably a good thing, but at the moment triggers a test failure. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Heads-up: G-B-S changes (bash, logging)
On Sat, Jan 28, 2006 at 03:43:43PM -0500, Igor Peshansky wrote: I've just committed a change that turns off logging functionality in the generic-build-script by default. Um, why?
Re: LD_PRELOAD regression on 1.5.19-4 ? no more loaded library in child process
On Fri, Jan 27, 2006 at 06:31:29PM +0100, Louis Lecaroz wrote: from cmd.exe -Start bash --All environment variables from cmd.exe were propaged in bash environment+.profiles one. --Start vi sample.txt from this bash instance A new instance of bash is loaded with also all environment variables. -A VIM.exe instance is loaded but only with PATH, SYSTEMDRIVE, SYSTEMROOT, WINDIR ! I can't help you, but I can see that there's a lot of information missing here. What did you actually *do* to get from one step to the next in the above? Where does your MSVC-linked DLL come into it? What loads that DLL? What is your system like (the information requested in http://cygwin.com/problems.html)? I tried also to verify with the win32 system routine called GetEnvironmentStrings(), but it is exactly the same data retrieved with getenv() ! So it (I feel) seems that this new version of cygwin did not propaged all environment variable to all child process ! Don't know why :( but I Just tested it on the 1.5.18 patched with the snapshot mentioned below, just reinstall the 1.5.19-4 over it (after having removed the previous), my conclusion (but I am not the Cygwin Expert ;) ), is that LD_PRELOAD since 1.5.19-4 previuous does have the same behavior as environment variable appears to be correctly propagated in 1.5.18-x not in 1.5.19-4. I saw (but did not verify) one report that 1.5.19 doesn't keep the windows copy of the environment in some situations where 1.5.18 did, so manually using CreateProcess or the like may work differently. AFAICT, this falls in the category of implementation detail that you shouldn't be counting on. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
binutils testsuite failures? (was: Re: Errors compiling cdrtools under cygwin 1.5.19)
On Tue, Jan 24, 2006 at 10:28:50PM -0500, Christopher Faylor wrote:
I should point out that I didn't rebuild my packages under 1.5.19 either
so I'm just as guilty as any other package maintainer in this regard.
Speaking of which, in the course of making a small patch to ld (which
I hope the binutils folk will apply and will find its way into an
updated cygwin package at some point) I tried building binutils and
got 2 unexpected test failures and 1 unexpected pass for ld (see
attached). I didn't revert to 1.5.18 to see if that made any
difference though. I probably just have something not set up
correctly.
make[1]: Entering directory `/usr/src/binutils-20050610-1/ld'
Making check in po
make[2]: Entering directory `/usr/src/binutils-20050610-1/ld/po'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/usr/src/binutils-20050610-1/ld/po'
make[2]: Entering directory `/usr/src/binutils-20050610-1/ld'
make check-DEJAGNU
make[3]: Entering directory `/usr/src/binutils-20050610-1/ld'
Making a new site.exp file...
srcroot=`cd .././ld pwd`; export srcroot; \
r=`pwd`; export r; \
LC_COLLATE=; LC_ALL=; LANG=; export LC_COLLATE LC_ALL LANG; \
EXPECT=expect; export EXPECT; \
if [ -f ./../expect/expect ]; then \
TCL_LIBRARY=`cd .././ld/../tcl/library pwd`; \
export TCL_LIBRARY; \
fi; \
runtest=runtest; \
if /bin/sh -c $runtest --version /dev/null 21; then \
$runtest --tool ld --srcdir ${srcroot}/testsuite \
CC=gcc -L/usr/src/binutils-20050610-1/./ld CFLAGS=-g -O2 \
CXX=c++ -L/usr/src/binutils-20050610-1/./ld CXXFLAGS=-g -O2 \
CC_FOR_HOST=gcc CFLAGS_FOR_HOST=-g -O2 \
OFILES=ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o
ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o ei386pe.o
deffilep.o pe-dll.o BFDLIB=../bfd/.libs/libbfd.a \
LIBIBERTY=../libiberty/libiberty.a ./../intl/libintl.a LIBS= \
; \
else echo WARNING: could not find \`runtest' 12; :;\
fi
WARNING: Couldn't find the global config file.
WARNING: Couldn't find tool init file
Test Run By sthoenna on Fri Jan 27 00:23:25 2006
Native configuration is i686-pc-cygwin
=== ld tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /usr/src/binutils-20050610-1/ld/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-alpha/alpha.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-arm/arm-elf.exp ...
Running
/usr/src/binutils-20050610-1/ld/testsuite/ld-auto-import/auto-import.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest with -Ur
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-checks/checks.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cris/cris.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-crx/crx.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-cygwin/exe-export.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-d10v/d10v.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-discard/discard.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/exclude.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/frame.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elf/sec64k.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfcomm/elfcomm.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfvers/vers.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfvsb/elfvsb.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-elfweak/elfweak.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-fastcall/fastcall.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/fdpic.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/frv-elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-frv/tls.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-h8300/h8300.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-i386/i386.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-ia64/ia64.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-linkonce/linkonce.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-m68hc11/m68hc11.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-maxq/maxq.exp ...
Running
/usr/src/binutils-20050610-1/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-mips-elf/mips-elf.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-mmix/mmix.exp ...
Running /usr/src/binutils-20050610-1/ld/testsuite/ld-pe/pe.exp ...
Running
Re: [ANNOUNCEMENT] GNU CLISP 2.38 (2006-01-24) released
On Thu, Jan 26, 2006 at 11:07:28AM +0100, Dr. Volker Zell wrote: Sam Steingold writes: o There is NO requires line in setup.ini at least at the following download side: http://mirrors.kernel.org whereas the clisp executables depend on various dlls. setup.hint contains this: requires:crypt cygwin libdb4.3 libiconv2 libintl3 libncurses8 libpcre0 libreadline6 zlib But the GENERATED file on the mirrors doesn't include a requires line. Maybe because of no space between requires: and crypt? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: new cygwin dlls
On Thu, Jan 26, 2006 at 11:43:29AM +0900, djh wrote: Has a fix been found for building emacs on the new cygwin versions 5.19 and up yet? There is at least one problem with d_ino as you know. I thought you said you'd worked around that (though you didn't share what your actual changes). An possibly another, since temacs crashes with a stack dump, during bootstrap. I saw you made a partial report of this, and but didn't see any response to the person who tried to help a step further in your investigation via gdb. cygwin distribution has an early emacs in it. Will it still run on the newer 5.19 versions? Has any regression testing been carryied out? Yes. Has anyone been assigned to look into these problems? s/been assigned/volunteered/ you mean? Nobody gets assigned or paid to do anything, unless perhaps through a RedHat support contract. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: apache 1.3.34 can not compile anymore
On Tue, Jan 24, 2006 at 12:31:11AM -0800, Brian Dessent wrote: [EMAIL PROTECTED] wrote: Tried to roll back to 1.5.18-1 from the setup.exe, but now I get 10s of error messages from packages who do not find getline in the cygwin dll. You would have to also use a previous version of any programs that need getline(). I think this includes findutils and coreutils. Also readline and libreadline6 need 1.5.19 I think. (There's a pattern here...) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Setup: Fatal Error: Uncaught Exception
On Mon, Jan 23, 2006 at 02:56:39PM -0500, Igor Peshansky wrote: Moving to cygwin-apps, as this is likely to get technical. On Mon, 23 Jan 2006, Brian Dessent wrote: Igor Peshansky wrote: I've looked at this a bit. Here's the weird part: the error says Uncaught Exception, but all the throws of that exception appear to be properly wrapped in try/catch blocks. So a simple change exception into an mbox kind of solution won't work here. More debugging is needed. The reason for the box is that the md5 checking was changed to run in a different thread than originally designed (now in the main thread instead of the download thread IIRC) and that thread does not have any particular catch handler for that exception, only the TOPLEVEL_CATCH which punts with the generic error. Do you mean packagemeta::ScanDownloadedFiles() calling packageversion::scan(), which calls check_for_cached()? Then yes, this isn't properly wrapped in a try/catch. I'd like to verify that this is the culprit (when someone sends me the corrupt tarball), but I think I see a proper fix for this. Will submit a patch shortly. Just to reemphasize, these are *not* corrupt tarballs. They are tarballs exactly as downloaded, extracted, and installed. It's just that later the versions on the cygwin mirror became different while keeping the same version/filename. I verified in a couple of the cases that the newer version actually had executables rebuilt, with slightly different file sizes and timestamps. I don't think I have any of them around any more, but if you were to pick a current tarball in your local package directory and un-bzip2 it and re-bzip2 it with a different compression level, you should see the problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors compiling cdrtools under cygwin 1.5.19
On Tue, Jan 24, 2006 at 10:43:30PM +0100, [EMAIL PROTECTED] wrote: I used cygwin happily for very long time to compile apache/php/postgresql and enjoy symlinks, and now I am cut-off from one day to the next. The apache folks do not seem to care. The bug I submitted is still without reply - http://issues.apache.org/bugzilla/show_bug.cgi?id=38364 Apache 2.x/php 5.x do not want to play on cygwin so far. So I am three days in the dark and testing like hell vmware and minigw to save my skin. I don't understand why you haven't just reverted cygwin to the previous version (yes, including packages that depend on 1.5.19 - a brief perusal of the cygwin-announce archives from the release of 1.5.19 onward would show you which packages may fall into this category). The cygwin distribution provides access to previous versions *because* it is known that things break from time to time, whether due to a problem in or out of cygwin's control. Additionally, if cygwin is that mission critical to you, you need to have a testing phase between downloading new versions and putting them into live production, just like for any other mission critical software. Seems this getline() breaks quite a lot and I am not quite sure this is _very_ positive for cygwin. People just get left alone in the dark (no everybody can debug and patch) and the pride of cygwin is somehow self focused. I don't understand the self focused part. Re: alone in the dark, If your concerns aren't addressed in the next few months, I think you can make that claim. I would expect such dramatic moves to be done with more care. The only care that really could be taken to prevent things like this is more users testing pre-release versions. Development snapshots of cygwin with getline() have been available for a long time now. Note that this isn't just addressed to you; if package maintainers heeded the release coming soon, please test a snapshot messages cgf sends out by testing that their packages build and run with the snapshot, there'd be less scope for problems. Otherwise I could call cygwin nice, but not reliable. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Setup: Fatal Error: Uncaught Exception
On Sun, Jan 22, 2006 at 09:37:12PM -0800, Brian Dessent wrote: Linda Walsh wrote: Is an application crash the expected behavior when package validation fails? Maybe it should mark it unusable or delete it? Yuck. I went through this, too. It appeared to me that there were a large number (a dozen? I no longer remember) of packages uploaded more than once, without bumping the version, and if you were so fortunate as to get the earlier rather than the later copy, setup won't have updated to the later. It might be easier to blow away your local package directory than to run setup over and over, each time identifying one more package to rename/delete. At the moment, yes. It's a consequence of a change in the md5 checking. It just means you need to delete the package, as it has the wrong size or checksum. It's on the todo list to clean this up. Is there a snapshot that has this fixed? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: can I tell setup.exe NOT to upgrade a specific package from now on?
On Sat, Jan 21, 2006 at 02:54:05PM +, Urs Rau wrote: I need to keep a version of postgresql server at level 7.x, but now that 8.x is out setup.exe suggests an upgrade every single time it runs. And one of these days I am going to forget to manually toggle the entry back to 'keep' instead of the suggested 'upgrade'. Is there any mechanism at all where I can either tell setup.exe to ignore future versions of posgresql or else actually be as precise, as to tell it that I want to stay at version 7.x for now? A couple of suggestions: Remove the line for postgresql in /etc/setup/installed.db. Then setup will no longer think you have it installed, and won't upgrade it (unless something else you have has postgresql as a dependency). Always use a .bat file for upgrading that runs setup twice; once to download and once to install, with the postgresql directory renamed during the install phase: cd local-package-dir .\setup -D (now make your package choices and download them) cd *%2f* ren release\postgresql postgresql-noinst cd .. .\setup -L (now install) cd *%2f* ren release\postgresql-noinst postgresql cd .. (AIUI due to a bug in setup.exe, the -D and -L flags won't actually help at the moment, but they don't hurt either.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
snapshot installation bat file (was: Re: [PATCH] Proposed clarification of the snapshot installation FAQ)
On Wed, Jan 18, 2006 at 06:41:27PM -0800, Joshua Daniel Franklin wrote: On 1/13/06, Yitzchak Scott-Thoennes wrote: It would be nice to have a sample batch file that automated the cygwin1.dll replacement, too. I've prettied up a batch file I use for installing cygwin-inst-* snapshots, and added stuff to handle spacey pathnames and inetd (which AIUI isn't always a cygrunsrv service), neither of which I personally use. Just drag and drop the tarball onto the batch file, or run with absolute tarball name as argument via a dos prompt. This batch file worked great for me on XP. The only issue I see is that if someone set their cygrunsrv or inetd to Manual this would actually start it up. I can put a note to that effect. Any objections to putting this up at http://cygwin.com/faq/faq.setup.html#faq.setup.snapshots ? I don't have any, but... I just tried it again drag-and-dropping a tarball *without* spaces in the path (spaces make Windows include around the parameter), and the \'s weren't properly quoted. Anybody know how to get it to work either way? Also be nice if it could be made to work on just the dll.bz2 file also. If we can come up with a general purpose, no extra packages required, bat file, maybe it could be downloadable directly from the snapshots page. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
please upload fortune-1.99.1-2
http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2-src.tar.bz2 http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2.tar.bz2 http://zipcon.net/~sthoenna/fortune/setup.hint setup.hint: sdesc: Print a random, perhaps interesting, adage; may contain offsensive material category: Games requires: cygwin libiconv2 test: 1.99.1-2 curr: 1.99.1-1 prev: 1.8-2
Re: please upload fortune-1.99.1-2
On Mon, Jan 16, 2006 at 10:58:15AM +0100, Corinna Vinschen wrote: On Jan 16 00:08, Yitzchak Scott-Thoennes wrote: http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2-src.tar.bz2 http://zipcon.net/~sthoenna/fortune/fortune-1.99.1-2.tar.bz2 http://zipcon.net/~sthoenna/fortune/setup.hint Uploaded. I'm curious, why is this marked as test? 1. Because I built it with a recent snapshot, so it requires a snapshot or 1.5.19 (which I hope will come soon...) 2. In case building with the generic build script causes any problems, I wanted people to have the option of keeping the 1.99.1-1 version, but I didn't want that to be prev, since the older version is a lot faster, and there may be some people still wanting to use it. After a while, I'd like 1.99.1-2 to replace 1.99.1-1 as curr.
some comments on the generic build script
I'd like some feedback on changes I made to the gbs for
fortune-1.99.1-2.
--- gbs.sh 2006-01-15 17:46:43.875859200 -0800
+++ fortune-1.99.1-2.sh 2006-01-15 22:26:48.129188800 -0800
@@ -66,6 +66,8 @@
fi
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
+export debian_patch=fortune-mod_1.99.1-3.diff.gz
+export debian_patch_name=${topdir}/$debian_patch
# determine correct names for generated files
export src_pkg_name=${FULLPKG}-src.tar.bz2
@@ -179,7 +184,8 @@
# change this if the original package was not tarred
# or if it doesn't unpack to a correct directory
unpack() {
- tar xv${opt_decomp}f $1
+ tar xv${opt_decomp}f $1 \
+ zcat $debian_patch_name | patch -p0
}
mkdirs() {
@@ -349,6 +352,7 @@
if [ -e ${src_orig_pkg}.sig ] ; then \
cp ${src_orig_pkg}.sig ${srcinstdir}/ ; \
fi \
+ cp ${debian_patch_name} ${srcinstdir}/${debian_patch} \
cp $0 ${srcinstdir}/`basename $0` \
name=$0 text=SCRIPT sigfile \
if [ ${SIG} -eq 1 ] ; then \
@@ -195,7 +201,7 @@
unpack ${src_orig_pkg} \
cd ${topdir} \
if [ -f ${src_patch} ] ; then \
-patch -Z -p0 ${src_patch} ;\
+patch -p0 ${src_patch} ;\
fi \
mkdirs \
if [ -f ${topdir}/${log_pkg_name} ] ; then \
These hunks include what are basically upstream patches and keep/regenerate
my patches separately.
The last hunk was needed because the debian patch file has no
timestamps, so patch complained about the timestamp being not as
expected for files in both it and my patch.
Would it be worthwhile doing s/debian_/upstream_/ and folding the
other hunks in to the regular version, with the zcat|patch and cp
omitted if the variable isn't set?
@@ -127,6 +129,9 @@
THANKS \
TODO \
USAGE \
+ Offensive \
+ cookie-files \
+ debian \
export install_docs=`for i in ${install_docs}; do echo $i; done | sort -u`
export test_rule=check
These are added install_docs. debian includes
debian/{README.Debian,README.Debian.offensive,changelog,copyright}. At
first, I had debian/ \, because there seemed to be code to support
that, but it included two copies of the files in the binary tarball,
one under /usr/share/doc/fortune-1.99.1 and one under
/usr/share/doc/fortune-1.99.1/debian. This seemed a little odd.
Another minor issue was that install_docs has NOTES, which picked up
the Notes file (which I wanted), but stored it with the name all in
caps. Is there an easy way in bash to go through a list of filenames
and set the capitalization the way it actually is on disk?
@@ -203,16 +209,12 @@
tar xvjf ${topdir}/${log_pkg_name}
fi )
}
+# fortune isn't autoconfusticated, just make objdir - srcdir symlinks
conf() {
(cd ${objdir} \
- CFLAGS=${MY_CFLAGS} LDFLAGS=${MY_LDFLAGS} \
- ${srcdir}/configure \
- --srcdir=${srcdir} --prefix=${prefix} \
- --exec-prefix='${prefix}' --sysconfdir=${sysconfdir} \
- --libdir='${prefix}/lib' --includedir='${prefix}/include' \
- --mandir='${prefix}/share/man' --infodir='${prefix}/share/info' \
- --libexecdir='${sbindir}' --localstatedir=${localstatedir} \
- --datadir='${prefix}/share' 21 | tee ${configurelogfile} )
+ (cd ${srcdir} find * -type d) | xargs mkdir -p \
+ (for dir in `find`; do find ${srcdir}/$dir -maxdepth 1 -type f | xargs ln -s
-t $dir; done) \
+ touch ${configurelogfile} )
}
reconf() {
(cd ${topdir} \
No configure, so I just made symlinks under objdir for all the files
under srcdir (except toplevel directories starting with .).
Would it make sense to include something like that in the regular
version whenever there's no configure file?
@@ -222,7 +224,7 @@
}
build() {
(cd ${objdir} \
- make CFLAGS=${MY_CFLAGS} 21 | tee ${makelogfile} )
+ make 21 | tee ${makelogfile} )
}
check() {
(cd ${objdir} \
The Makefile set a lot of important stuff in CFLAGS= (including -O2)
which this overrode. Is this a common problem? Should I have patched
the Makefile to use a different variable name and include CFLAGS in it?
@@ -250,6 +252,7 @@
find ${instdir}${prefix}/share/info -name *.info | xargs -r gzip -q ; \
fi \
if [ -d ${instdir}${prefix}/share/man ] ; then \
+true breaks cause unstr.8 is symlink to strfile.8 || \
find ${instdir}${prefix}/share/man -name *.1 -o -name *.3 -o \
-name *.3x -o -name *.3pm -o -name *.5 -o -name *.6 -o \
-name *.7 -o -name *.8 | xargs -r gzip -q ; \
Took me a while to figure out why this was breaking things. I have
these:
-rw-r--r-- 1 sthoenna None 11485 Jan 15 22:27 ./man6/fortune.6
-rw-r--r-- 1 sthoenna None 7512 Jan 15 22:27 ./man8/strfile.8
lrwxrwxrwx 1 sthoenna None 9 Jan 15 22:27 ./man8/unstr.8 - strfile.8
and when gzip tried to compress unstr.8, strfile.8 was no longer there
(having become strfile.8.gz), causing the whole build process to stop.
Any easy fixes to suggest?
@@ -331,7 +334,7 @@
unpack ${src_orig_pkg} \
mv ${BASEPKG} ../${BASEPKG}-orig \
cd ${topdir} \
- diff -urN -x '.build' -x '.inst' -x
findutils maintainer: setup.hint lost?
Last I checked findutils had: curr: 4.2.25-2 prev: 20041227-1 test: 4.2.27-1 Now I see: curr: 20041227-1 prev: 4.2.27-1 as if the test: line were gone and 20041227 is assumed to be curr because it's greater than 4.
Re: findutils maintainer: setup.hint lost?
Subject should have been setup.hint test: lost? On Tue, Jan 17, 2006 at 01:10:42AM -0500, Christopher Faylor wrote: On Mon, Jan 16, 2006 at 09:52:37PM -0800, Yitzchak Scott-Thoennes wrote: Last I checked findutils had: curr: 4.2.25-2 prev: 20041227-1 test: 4.2.27-1 Now I see: curr: 20041227-1 prev: 4.2.27-1 as if the test: line were gone and 20041227 is assumed to be curr because it's greater than 4. Since 20041227-1 was my last release, I've taken the liberty of removing it. So, this should no longer be a problem. Thanks. And thanks for 1.5.19.
Re: Installing cygwin by manually copying c:\cygwin to another machine
On Mon, Jan 16, 2006 at 10:08:03AM +0200, Adrian Maier wrote: On 1/16/06, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote: I'm not sure what this approach buys you over running setup.exe in unattended install mode on a copied local package cache, except fragility. Is there an unattended install mode? I thought that there is no such thing , because according to http://www.cygwin.com/cygwin-ug-net/setup-net.html : Unfortunately setup.exe does not yet support unattended installs. In fact, that's precisely why I asked the question in the first place: i needed a way to install cygwin without the need of choosing individual packages; and with no need of internet connection ... I think the key word there is does not yet *support*. Run setup --help from a command prompt, and setup will output a list of its command line options into setup.log.full. Play with running it using them on a previously prepared local download directory, with non-default packages included either by changing setup.ini to add Base to their category or adding a dummy mirror directory with a setup.ini having a dummy package that has category Base and requires the other packages you want. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: fortune-1.99.1-2 (experimental)
This version of fortune contains many tweaks to the fortune data files from the debian 1.99.1-2 and 1.99.1-3 releases, including the new off/disclaimer file, and adds a new, undocumented, -u switch to fortune. It is now built using the cygwin generic build script, and requires a recent snapshot or 1.5.19. Assuming there are no reported problems, it will become the current version shortly after cygwin 1.5.19 is released. = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing cygwin by manually copying c:\cygwin to another machine
On Mon, Jan 16, 2006 at 12:23:00PM +0200, Adrian Maier wrote: On 1/16/06, Chris Taylor [EMAIL PROTECTED] wrote: Adrian Maier wrote: On 1/16/06, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote: I think the key word there is does not yet *support*. Run setup --help from a command prompt, and setup will output a list of its command line options into setup.log.full. Play with running it using them on a previously prepared local download directory, with non-default packages included either by changing setup.ini to add Base to their category or adding a dummy mirror directory with a setup.ini having a dummy package that has category Base and requires the other packages you want. I see: this functionality is in development and therefore is well hidden for the moment. It's a shame that it's not clearly documented . setup --help displays nothing for me I suspect this is a cmd.exe or win2000 - related problem , because i have seen the same happening with other programs as well (namely qemu). Adrian Maier Please re-read what Yitzchak said - it outputs the list of options into setup.log.full Just for emphasis, I'll say that again: *setup.log.full* Open that for the options. Uh, you are right. Sorry guys, I haven't read the entire phrase written by Yitzchak ... my fault. It looks like I am too used to the idea of programs writing their messages to stdin/stdout . It certainly qualifies as quaint behavior. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated: fortune-1.99.1-2 (experimental)
This version of fortune contains many tweaks to the fortune data files from the debian 1.99.1-2 and 1.99.1-3 releases, including the new off/disclaimer file, and adds a new, undocumented, -u switch to fortune. It is now built using the cygwin generic build script, and requires a recent snapshot or 1.5.19. Assuming there are no reported problems, it will become the current version shortly after cygwin 1.5.19 is released. = To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: once more unto the breech - please try a snapshot so I can release this thing
On Sat, Jan 14, 2006 at 05:58:32PM -0800, Yitzchak Scott-Thoennes wrote: On Thu, Jan 12, 2006 at 08:35:18PM -0500, Christopher Faylor wrote: On Wed, Jan 11, 2006 at 10:46:24PM -0800, Yitzchak Scott-Thoennes wrote: Just in case it's relevant, note that I have experimental bash, readline, libreadline6, findutils, and coreutils. Does the latest snapshot behave any differently? Neither Corinna nor I can duplicate this problem so neither of us can do anything other than shoot in the dark to try to solve it. I haven't had it happen again using 20060112. I spoke too soon :(, but I wouldn't think you should hold up the release on this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Installing cygwin by manually copying c:\cygwin to another machine
On Fri, Jan 13, 2006 at 08:59:25PM -0500, Brett Serkez wrote: [snip] Not particularly, assuming you use the same local package cache on each machine, especially if you use the trick for pulling in all the packages you want automatically. Right. I don't know about chere, chere must have settings in the registry, as it adds a 'bash here' menu option in explorer when you right click on a directory. You'd have to run 'chere -i' on the new system. That means that setup, services like sshd, cron, inetd, etcetera will be available for installation. Right, available for installation, you'd have to run the setup scripts. I suppose running ssh-host-config wouldn't be a bad idea, not only would it install the Windows sshd service on the new system, but it would generate unique host keys, otherwise both the new and old systems would have the same key. Sounds like this is doable, but there may be a series of commands that need to be run, depending on the original installation. I'm not sure what this approach buys you over running setup.exe in unattended install mode on a copied local package cache, except fragility. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: once more unto the breech - please try a snapshot so I can release this thing
On Thu, Jan 12, 2006 at 08:35:18PM -0500, Christopher Faylor wrote: On Wed, Jan 11, 2006 at 10:46:24PM -0800, Yitzchak Scott-Thoennes wrote: Just in case it's relevant, note that I have experimental bash, readline, libreadline6, findutils, and coreutils. Does the latest snapshot behave any differently? Neither Corinna nor I can duplicate this problem so neither of us can do anything other than shoot in the dark to try to solve it. I haven't had it happen again using 20060112. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Please upload: perl-Tk-804.027-4
On Thu, Jan 12, 2006 at 04:40:43PM -0600, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Please update the setup.hint as well. Hmm, is --enable-auto-image-base working right? Some of these are in what I thought was system-reserved space above 6800: Tk/Canvas/Canvas.dll ImageBase 681c Tk/Compound/Compound.dll ImageBase 6fc8 Tk/Entry/Entry.dll ImageBase 6454 Tk/Event/Event.dll ImageBase 6258 Tk/HList/HList.dll ImageBase 6490 Tk/InputO/InputO.dll ImageBase 6644 Tk/IO/IO.dll ImageBase 62a4 Tk/JPEG/JPEG.dll ImageBase 7020 Tk/Listbox/Listbox.dll ImageBase 6900 Tk/Menubutton/Menubutton.dll ImageBase 63a0 Tk/Mwm/Mwm.dll ImageBase 625c Tk/NBFrame/NBFrame.dll ImageBase 69ac Tk/Pixmap/Pixmap.dll ImageBase 6cf4 Tk/PNG/PNG.dll ImageBase 6bbc Tk/Scale/Scale.dll ImageBase 6fc4 Tk/Scrollbar/Scrollbar.dll ImageBase 67e8 Tk/Text/Text.dll ImageBase 70a0 Tk/TixGrid/TixGrid.dll ImageBase 69c8 Tk/Tk.dll ImageBase 7028 Tk/TList/TList.dll ImageBase 6c14 Tk/WinPhoto/WinPhoto.dll ImageBase 6f94 Tk/X/X.dll ImageBase 6cb4 Tk/Xlib/Xlib.dll ImageBase 6578
