Commit: efa5488448771f9cf6554b137d388ea5f3dc90c6
https://github.com/bagder/curl/commit/efa5488448771f9cf6554b137d388ea5f3dc90c6
Author: Marc Hoersken i...@marc-hoersken.de
Date: 2013-04-06 (Sat, 06 Apr 2013)
..
ftp.pm: Made Perl testsuite able to kill Windows processes
This patch
Hi Gisle,
2013/4/6 Gisle Vanem gva...@broadpark.no:
ftp.pm: Made Perl testsuite able to kill Windows processes
This patch uses a tool from Windows-XP Professional:
system(taskkill $filter nul 21);
I run Windows-XP Home and have no such tool. AFAICS,
one cannot get this from MS w/o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.04.2013 14:49, Marc Hoersken wrote:
Hi Gisle,
2013/4/6 Gisle Vanem gva...@broadpark.no:
ftp.pm: Made Perl testsuite able to kill Windows processes
This patch uses a tool from Windows-XP Professional:
system(taskkill $filter nul 21);
Hi LRN,
2013/4/6 LRN lrn1...@gmail.com:
You can use Win32API Perl module and TerminateProcess or
SafeTerminateProcess.
Also, CreateJobObject + AssignProcessToJobObject can be used to
implement behaviour similar to kill -pid. Obviously, that also
requires Win32API module.
I added support for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.04.2013 19:12, Marc Hoersken wrote:
Hi LRN,
2013/4/6 LRN lrn1...@gmail.com:
You can use Win32API Perl module and TerminateProcess or
SafeTerminateProcess. Also, CreateJobObject +
AssignProcessToJobObject can be used to implement
Hi LRN,
2013/4/6 LRN lrn1...@gmail.com:
The only advice i can give is to treat tskill failures gracefully. W32
is known to put processes into a state in which they still exist, but
cannot be interacted with, probably due to the fact that OS is
dismantling them at the moment. Killing such
Hello!
I'm trying to build libcurl 2.29.0 under Ubuntu Linux (lucid). Build fails
on running tests stage: only test number 237 has failed:
./runtests.pl 237
* System characteristics
* curl 7.29.0 (x86_64-pc-linux-gnu)
* libcurl/7.29.0 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
*
On Sat, 6 Apr 2013, GitHub wrote:
getpart.pm: Strip carriage returns to fix Windows support
Note that even on non-windows we check for CRLF line endings in places, so
possibly such unconditional code will remove some level of checks in tests now
on msys/mingw...
--
/ daniel.haxx.se
On Sat, 6 Apr 2013, Dmitry Sukhov wrote:
I'm trying to build libcurl 2.29.0 under Ubuntu Linux (lucid). Build fails
on running tests stage: only test number 237 has failed:
(it is 7.29.0, not 2.29.0...)
The build is not the test though. It seems the build is fine but a test case
fails.
2013/4/6 Daniel Stenberg dan...@haxx.se:
Note that even on non-windows we check for CRLF line endings in places, so
possibly such unconditional code will remove some level of checks in tests
now on msys/mingw...
Do you think we should add an attribute to the test data files to
specify that the
On Sat, 6 Apr 2013, Marc Hoersken wrote:
Do you think we should add an attribute to the test data files to specify
that the text should be converted to a specific line ending or the one
corresponding to the current OS?
Do we really need that? The line endings are already carefully tuned to
On Sat, 6 Apr 2013, Marc Hoersken wrote:
I think so, yes. I know that the line endings are tuned, usually to
LF, but for some reason curl actually generates output with CRLF for
some tests.
curl generates whatever it gets from the server (unless in the very rare case
--crlf is used).
For
On Sun, 7 Apr 2013, Daniel Stenberg wrote:
The test server outputs the directory with LFs only. That's a flaw we should
fix. ftpserver.pl clearly has the directory stored internally with CRLF
endings but for some reason the CRs get lost in transition! (I suspect the
sockfilt handling is to
13 matches
Mail list logo
