I want to provide X – Services on a Windows Terminal Server.
Cygwin is on a file share
To get xwin to work, i have to mount /tmp to %temp%
But with 1.7 the mount points aren’t saved in the registry any more
So a „Windows - batch – file „ like this doesnt work
mount %TEMP% /tmp
xwin –ac –que
On Aug 13 21:35, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > Well, there *is* a quick flash console window, but it prints an error
> > message I don't grok:
> >
> > Unable to connect to the rxvt-unicode daemon: No such file or directory
>
> Well, this string only appears in the urxvt
Bugfixes:
=
- Fix and workaround a bug in the implementation of the C++ memory
allocation support introduced in 1.7.0-49. A structure pointer got
accidentally manipulated when DLLs got loaded at runtime via dlopen.
When dlclose'ing the same DLL, the pointer content pointed into the
Further tests with this little program show that the observed error only
occurs when the socket is dup()'ed to STDIN (fd = 0), but not when
dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup
call with any positive integer (except 3 and 4).
Also, explicitly closing STDIN in a
I forgot to add that the same binary copy of the executable of the test
program (compiled under 1.7) works without error if I place the
cygwin1.dll version 1.5 into the same directory.
cygwin wrote:
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a fil
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a file descriptor obtained from socketpair() is
dup2()'ed into STDIN and then closed. The close call fails.
Output from the program is as follows:
socket 1 = 3
socket 2 = 4
dup2 socket 1...
closing socket
Haojun Bao wrote:
> "Larry Hall (Cygwin)" writes:
>
>> On 08/13/2009 05:27 AM, Haojun Bao wrote:
>>> When I update/build cygwin, I must make sure to kill all cygwin
>>> processes, or I will be required to reboot.
>>
>>
>> Your reference to "build" doesn't make sense to me but if by "update" you
Corinna Vinschen wrote:
> Well, there *is* a quick flash console window, but it prints an error
> message I don't grok:
>
> Unable to connect to the rxvt-unicode daemon: No such file or directory
Well, this string only appears in the urxvtc-X code (the "client" code
for urxvtd-X). If you have
"Larry Hall (Cygwin)" writes:
> On 08/13/2009 05:27 AM, Haojun Bao wrote:
>>
>> When I update/build cygwin, I must make sure to kill all cygwin
>> processes, or I will be required to reboot.
>
>
>
> Your reference to "build" doesn't make sense to me but if by "update" you
> mean via 'setup.exe',
On 08/13/2009 09:06 AM, Corinna Vinschen wrote:
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-58.
I still refrain from telling stuff like "this is the last test release",
but I still hope we're getting really close now, even after I had
screwed up so nicely with the 1.7.0-53 a
A way to find the answer would be to recompile your rsync without
socketpair support (as shown in my previous message)
and retry your test case.
Angelo Graziosi wrote:
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is the discussion in this thread related to
what I flagged here:
http://cygwin.com/ml/cygwin/2007-04/msg00143.html
and here:
http://cygwin.com/ml/cygwin/2007-05/msg00677.html
After updating 2 other systems to cygwin 1.7, I find that they also work
fine in the same test.
However, that doesn't help much debugging this.
I found that the problem on the failing system is related to using Unix
domain sockets for the IPC pipes.
If I replace the socketpair() call in fd_p
- Original Message -
From: "Mike Schmidt"
To: cygwin
Sent: Thursday, August 13, 2009 2:09 PM
| On all the systems where cron works I did NOT run cron-config. I used
| the following line to install cron:
| cygrunsrv --install cron --path=/usr/sbin/cron --desc='Cygwin cron
| service' --t
Christopher Faylor cygwin.com> writes:
> >often this type of bug reappears, too - historical cygwin has had it in
> >the past with newlib's popen implementation (I fixed it 2006-08-22), as
>
> Just a point of order: Cygwin doesn't use the newlib version of
> popen.
It doesn't now, but did prior
On Thu, Aug 13, 2009 at 07:52:01PM +, Eric Blake wrote:
>cygwin sipxx.com> writes:
>
>>
>> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
>> - close(to_child_pipe[1]) < 0 ||
>> - close(from_child_pipe[0]) < 0 ||
>> - dup2(
cygwin sipxx.com> writes:
>
> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
> - close(to_child_pipe[1]) < 0 ||
> - close(from_child_pipe[0]) < 0 ||
> - dup2(from_child_pipe[1], STDOUT_FILENO) < 0) {
> -
On 08/13/2009 05:27 AM, Haojun Bao wrote:
When I update/build cygwin, I must make sure to kill all cygwin
processes, or I will be required to reboot.
Your reference to "build" doesn't make sense to me but if by "update" you
mean via 'setup.exe', then 'setup.exe' does warn of these situations
2009/8/13 Corinna Vinschen:
> I just tried that on W7 and W7 64. I can't reproduce any specific
> slowness starting with he second invocation of rxvt, incuding writing
> the utmp entry. The startup time is always the same, roughly a second,
> regardless of the number of already open rxvt windows.
On Thu, Aug 13, 2009 at 08:30:53PM +0200, Corinna Vinschen wrote:
>On Aug 13 13:17, cygwin wrote:
>>The RSYNC application fails in close() on the pipe streams to and from
>>child processes created when rsync starts. When running rsync.exe and
>>cygwin1.dll from cygwin 1.5 within the 1.7 installati
On Aug 13 13:17, cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation
cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation completes without err
Sorry. Even after 15 years of linux I still use man pretty much
exclusively and rarely think to check with info.
Thanks for the reminder that info exists. However, the entry about + in
the info manual is minimal at best - it says nothing about getfacl or
anything else useful. However, I will reme
Excellent. Thank you vey much. I have found and solved to problem I had
with acls on a file.
Mike
Dave Korn wrote:
Mike Schmidt wrote:
I have noticed that in many cases when listing files with ls there is a
+ at the end of the permissions. What does this mean? It seems to be
related to some
The RSYNC application fails in close() on the pipe streams to and from
child processes created when rsync starts.
When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
installation on the same system (WinXP pro),
the identical invocation completes without errors.
The problems ap
A new version of subversion is now available for download. This
version is built for Cygwin 1.7.
CYGWIN NEWS:
There were two test failures with Cygwin 1.7.
* All tests hang using the serf HTTP library. This package still
includes support for serf, but if you encounter problems, pl
A new version the Apache Portable Runtime utilities library is now
available for download. This version is built for Cygwin 1.7.
NEWS:
=
This is a new upstream release.
SECURITY: This release includes a fix for CVE-2009-2412.
See http://www.apache.org/dist/apr/CHANGES-APR-UTIL-1.3 for more
d
NEWS:
=
This is a new upstream release. See CHANGES (URL below) for more
information.
SECURITY: This release includes a fix for CVE-2009-2411.
IMPORTANT: This release will silently upgrade your Subversion
working copies to the 1.6 format, rendering them unusable with
previous major versions o
apr1 has been updated to the latest upstream release.
SECURITY: This release includes a fix for CVE-2009-2412.
NEWS:
=
Please see
http://www.apache.org/dist/apr/CHANGES-APR-1.3
for more details about the upstream changes
DESCRIPTION:
The mission of the Apache Portable Runtim
A new version the Apache Portable Runtime utilities library is now
available for download.
NEWS:
=
This is a new upstream release.
SECURITY: This release includes a fix for CVE-2009-2412.
See http://www.apache.org/dist/apr/CHANGES-APR-UTIL-1.3 for more
details.
This package includes plugins
apr1 has been updated to the latest upstream release.
SECURITY: This release includes a fix for CVE-2009-2412.
NEWS:
=
Please see
http://www.apache.org/dist/apr/CHANGES-APR-1.3
for more details about the upstream changes
DESCRIPTION:
The mission of the Apache Portable Runtim
Hi folks,
I just uploaded a new Cygwin 1.7 test release, 1.7.0-58.
I still refrain from telling stuff like "this is the last test release",
but I still hope we're getting really close now, even after I had
screwed up so nicely with the 1.7.0-53 and 1.7.0-54 releases :-P
You know the drill by no
On 2009-08-12 20:29, Yaakov (Cygwin/X) wrote:
> On 12/08/2009 14:55, Alec Kloss wrote:
> >I'm not having much luck with heimdal-1.2.1 from cygwin-ports trunk
> >on Cygwin 1.7 beta. This is all downloaded today. cygwin-ports
> >revision 7337.
>
> 1) If patch(1) is segfaulting, something else is w
Larry Hall (Cygwin) wrote:
> On 08/12/2009 10:33 PM, loody wrote:
>> Dear all:
>> I patch my kernel with the code below.
>>
>> #ifdef __CYGWIN__
>> #include
>> #else
>> #include
>> #endif
>>
>> and I cross compile it with mips toolchain.
>> But I get the error message below:
>> gcc -Wp,-MD,script
On 08/12/2009 10:33 PM, loody wrote:
Dear all:
I patch my kernel with the code below.
#ifdef __CYGWIN__
#include
#else
#include
#endif
and I cross compile it with mips toolchain.
But I get the error message below:
gcc -Wp,-MD,scripts/mod/.mk_elfconfig.d -Wall -Wstrict-prototypes -O2
-fomit-fr
- Original Message -
From: "Mike Schmidt"
To: cygwin
Sent: Thursday, August 13, 2009 10:10 AM
|I am running cygwin 1.5.25-15 on a number of sites, most of the Windows
| XP. I have at least one occasion where I have two identical systems
| side-by-side, configured the same way (same log
On Aug 12 13:35, Andy Koppe wrote:
> 2009/8/12:
> > I have been using for long time cygwin on WinXP Prof 32bit and the
> > terminal I always use is the rxvt. Everything has always worked properly.
> > Now I will get a new PC and I am thinking to switch to windows 7 64bit
> > (the official release j
Hi,
Dave Korn escribió:
... something as simple as that will assemble and work just fine on Cygwin.
But anything much more complex is liable to run into problems. For example,
on Linux you use the "int 80" instruction to perform a syscall; on Cygwin, you
just call a subroutine like any other.
Hi,
I'm trying to pass non-ASCII strings as environment variable values from one
program to another. It does not work when a mingw program invokes a cygwin
program, but works when the caller is a cygwin program or the callee is a
mingw program.
Cygwin in use is 1.5.25, on Windows XP.
How to repr
On Aug 13 15:10, Olumide wrote:
> Hi -
>
> I've noticed for sometime that Cygwin commands such as "ps" and "ls"
> (now) work in the Windows command line (cmd), and I'm not sure if its
> because something extra I installed on/did to my machine. (In fact, the
> command "pwd", when run in the cm
On Aug 13 10:10, Mike Schmidt wrote:
> I have noticed that in many cases when listing files with ls there is a
> + at the end of the permissions. What does this mean? It seems to be
> related to some problems I am having with file access from windows
> programs after the files have been modified by
Olumide wrote:
> I've noticed for sometime that Cygwin commands such as "ps" and "ls"
> (now) work in the Windows command line (cmd), and I'm not sure if its
> because something extra I installed on/did to my machine. (In fact, the
> command "pwd", when run in the cmd, shows a Cygwin path like
> /
Mike Schmidt wrote:
> I have noticed that in many cases when listing files with ls there is a
> + at the end of the permissions. What does this mean? It seems to be
> related to some problems I am having with file access from windows
> programs after the files have been modified by emacs in a cygwi
Hi -
I've noticed for sometime that Cygwin commands such as "ps" and "ls"
(now) work in the Windows command line (cmd), and I'm not sure if its
because something extra I installed on/did to my machine. (In fact, the
command "pwd", when run in the cmd, shows a Cygwin path like
/cygdrive/c/Docu
I have noticed that in many cases when listing files with ls there is a
+ at the end of the permissions. What does this mean? It seems to be
related to some problems I am having with file access from windows
programs after the files have been modified by emacs in a cygwin session.
example:
-rwx-
Javier Sedano wrote:
> On a first though I was about to say "no"... but on second though...
> not sure. I've got several .s files (assembly code) that seems to be
> hand-written (they have lots of the kind of comments that humans use
> to do, so does not seem to be compiled). See trace below.
I am running cygwin 1.5.25-15 on a number of sites, most of the Windows
XP. I have at least one occasion where I have two identical systems
side-by-side, configured the same way (same logons, etc). Both systems
run cron as a service installed via cygrunsrv, using the local system
account.
One one
On Aug 12 13:13, Charles Wilson wrote:
> Corinna Vinschen wrote:
>
> > I can confirm this. It only happens with urxvt-X for some reason.
> > I don't see this for xterm, or xeyes, or xclock.
>
> Me too.
> [...]
> I need another piece of information before deciding how to address this
> issue. If
When I update/build cygwin, I must make sure to kill all cygwin
processes, or I will be required to reboot. So I just wrote a script
using win32 native python to terminate all process that has cygwin1.dll
loaded:
terminateModule.py cygwin1.dll
Sadly, I can't simply post the .py file out, bec
49 matches
Mail list logo
