More information as promised, after getting the new run and checkX
(run2) packages announced this morning.
$ checkX -v
run2 0.3.2
- QUOTE -
Lothar Brendel wrote:
Timares, Brian (Patriot) wrote:
The X window showed up, but it blew up real good (the windows
disappeared, then the X icon.
Hi!
More information as promised, after getting the new run and checkX
(run2) packages announced this morning.
$ checkX -v
run2 0.3.2
0.3.2 announced? I didn't get any such message, and setup still only offers
0.3.1-1 to me.
vhaisbtim...@isb-timaresbrian-lt ~
$ XWin -multiwindow
[1]
On Thu, Dec 03, 2009 at 12:25:14AM +0100, Lothar Brendel wrote:
More information as promised, after getting the new run and checkX
(run2) packages announced this morning.
$ checkX -v
run2 0.3.2
0.3.2 announced? I didn't get any such message, and setup still only offers
0.3.1-1 to me.
Ken Brown wrote:
On 10/28/2009 6:07 PM, Andy Koppe wrote:
2009/10/28 Ken Brown:
Maybe my terminology is wrong. But if you start mintty with no
.minttyrc
and with LANG unset, mintty will set LANG=C.UTF-8.
Yep. That's primarily for emacs' benefit, which parses the locale env
variables itself
Linda Walsh wrote:
C.UTF_8 doesn't exist.
You're wrong. Please read the whole of this thread -- and the last two
months' worth of cygwin-developers.
mintty is broken.
No, it isn't. It just doesn't work the way *you* expect it to.
Might want to try 'Console' nstead of using mintty. Not
2009/12/3 Linda Walsh:
C.UTF_8 doesn't exist.
Well, guess what: it does in Cygwin 1.7, and it's the default locale.
And it's also in the next Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776.
Cygwin 1.7 also supports C.ISO-8859-1, C.CP1252, ...
Might want to try 'Console'
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-12-02 09:36:55
Modified files:
winsup/doc : ChangeLog setup2.sgml
Log message:
* setup2.sgml (setup-env): Clarify that Windows environment gets
copied over. Add paragraph about
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2009-12-02 15:23:03
Modified files:
winsup/cygwin : ChangeLog fhandler_socket.cc syslog.cc
Log message:
* fhandler_socket.cc (send_internal): Don't split datagram messages
into pieces.
Larry Hall (Cygwin) a écrit :
Thanks. Since cygcheck for 1.5 doesn't find gcc and you have tools from
other sources installed,
This is legitimate, i understand.
I have to ask, are you comparing Cygwin's 1.5
build
tools with Cygwin's 1.7 build tools?
I use only cygwin1 stuff in cygwin1.
Hi,
I am trying to display the help options of the very latest
setup-1.7.exec in a cmd prompt on a Windows 2000 host:
.\setup-1.7 --help
and seeing no output at all. Is this expected?
Regards,
Shaddy
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Andy Koppe wrote:
2009/12/2 Dave Korn:
Andy Koppe wrote:
2009/12/2 jeffunit:
My program ran fine under cygwin 1.5 as well as many versions of
linux including mandriva 2009, mandriva 2009.1 and mandriva 2010.0
When compiled with
gcc cal.c -o cal
and run with
cal 2009
I get a segmentation
On Dec 1 21:14, Jon TURNEY wrote:
On 01/12/2009 20:17, Jon TURNEY wrote:
On 01/12/2009 19:37, John Morrison wrote:
Ok, I've removed the X11R6 from the path and unset TMP and TEMP in the
skel/.bashrc. Are there any other changes folks would like before I roll
this up?
It would be nice to
On Dec 1 19:37, John Morrison wrote:
Ok, I've removed the X11R6 from the path and unset TMP and TEMP in the
skel/.bashrc. Are there any other changes folks would like before I roll
this up?
We should keep /usr/X11R6/bin in for now, see
http://cygwin.com/ml/cygwin/2009-12/msg00089.html
And
syslog() produces bogus lines in /var/log/messages.
Testcase (with syslog-ng):
$ echo -e 'one\ntwo\nthree' | logger -t test
$ tail /var/log/messages
...
Dec 2 10:12:31 localhost kernel:
Dec 2 10:12:31 localhost test: one
Dec 2 10:12:31 localhost kernel:
Dec 2 10:12:31 localhost test: two
On Dec 1 16:59, Ken Brown wrote:
On 12/1/2009 4:08 PM, Corinna Vinschen wrote:
On Dec 1 19:24, John Morrison wrote:
On Tue, December 1, 2009 4:32 pm, Ken Brown wrote:
OK, my patch is attached. It anticipates the change to the default
.bashrc file that we've been discussing in the thread
On Dec 2 10:31, Christian Franke wrote:
syslog() produces bogus lines in /var/log/messages.
Testcase (with syslog-ng):
$ echo -e 'one\ntwo\nthree' | logger -t test
$ tail /var/log/messages
...
Dec 2 10:12:31 localhost kernel:
Dec 2 10:12:31 localhost test: one
Dec 2 10:12:31
Corinna Vinschen wrote:
And I'd like to ask you to add two one-liner files to your package:
http://cygwin.com/ml/cygwin-developers/2009-12/msg00026.html
In my system (XPSP3), some Windows application defined LANG=it_IT.UTF-8
at Windows level (all users), and it works just fine with all Cygwin
2009/12/2 Angelo Graziosi:
Corinna Vinschen wrote:
And I'd like to ask you to add two one-liner files to your package:
http://cygwin.com/ml/cygwin-developers/2009-12/msg00026.html
In my system (XPSP3), some Windows application defined LANG=it_IT.UTF-8 at
Windows level (all users), and it
Andy Koppe wrote:
See the continuation of the thread Corinna linked to. LANG should only
be set to C.UTF-8 if it isn't set already.
Indeed. I was just proposing something like this:
if test -n ${LANG}; then
# LANG is not empty
[...]
else
# LANG is empty
[...]
fi
Thanks,
Angelo.
--
Corinna Vinschen wrote:
On Dec 2 10:31, Christian Franke wrote:
I presume that the root of the problem is that the
writev(fd, { { PRI , . }, { MSG, . } }, 2)
used within syslog() sends PRI and MSG in
two separate datagrams to /dev/log.
Probably not. The kernel: message is
Andy Koppe wrote:
2009/12/2 jeffunit:
When compiled with
gcc cal.c -o cal
and run with
cal 2009
I get a segmentation fault.
When I uncomment line 62, the program runs successfully.
It's the line after that that has the bug: it's writing to index 432
of a 432-element array.
I disagree -- I
On 12/2/09, Eliot Moss m...@cs.umass.edu wrote:
Andy Koppe wrote:
2009/12/2 jeffunit:
When compiled with
gcc cal.c -o cal
and run with
cal 2009
I get a segmentation fault.
When I uncomment line 62, the program runs successfully.
It's the line after that that has the bug: it's writing to
Still, it could be some other overflow somewhere else; as I'd guess you were
reasoning, that's the commonest reason for this sort of bug that crops up on
some platforms with some stack and memory layouts and not others.
Jeff, recompile your code, adding the -g flag, then run it under gdb,
On 12/2/09, jeffunit j...@jeffunit.com wrote:
Still, it could be some other overflow somewhere else; as I'd guess you
were
reasoning, that's the commonest reason for this sort of bug that crops up on
some platforms with some stack and memory layouts and not others.
Jeff, recompile your
On Dec 2 12:07, Christian Franke wrote:
Corinna Vinschen wrote:
On Dec 2 10:31, Christian Franke wrote:
I presume that the root of the problem is that the
writev(fd, { { PRI , . }, { MSG, . } }, 2)
used within syslog() sends PRI and MSG in
two separate datagrams to
On Wed, Dec 02, 2009 at 07:43:37PM +1100, Shaddy Baddah wrote:
Hi,
I am trying to display the help options of the very latest
setup-1.7.exec in a cmd prompt on a Windows 2000 host:
.\setup-1.7 --help
and seeing no output at all. Is this expected?
Yes. The API for reattaching to the console
On Dec 2 15:17, Corinna Vinschen wrote:
On Dec 2 12:07, Christian Franke wrote:
Corinna Vinschen wrote:
On Dec 2 10:31, Christian Franke wrote:
I presume that the root of the problem is that the
writev(fd, { { PRI , . }, { MSG, . } }, 2)
used within syslog() sends PRI
Corinna Vinschen wrote:
On Dec 2 12:07, Christian Franke wrote:
Another test:
This sends one UDP package on 1.5, but two on 1.7:
int sd = socket(AF_LOCAL, SOCK_DGRAM, 0);
struct sockaddr_un sa; sa.sun_family = AF_LOCAL;
strcpy(sa.sun_path, /dev/log);
connect(sd, (struct
I'm running 1.7.0-67 on Windows 7 64 bit:
$ uname -v
2009-11-27 15:38
and I'm getting sporadic for errors like this one:
$ svn commit -m xxx yyy
2 [main] svn 5924 fork: child -1 - died waiting for longjmp
before initialization, retry 0, exit code 0xC005, errno 11
svn: Commit failed
Luis P Caamano wrote:
I'm running 1.7.0-67 on Windows 7 64 bit:
$ uname -v
2009-11-27 15:38
and I'm getting sporadic for errors like this one:
$ svn commit -m xxx yyy
2 [main] svn 5924 fork: child -1 - died waiting for longjmp
before initialization, retry 0, exit code 0xC005, errno
Corinna Vinschen wrote in another thread about setting LANG:
... Andy and Thomas, please work
out the best solution together. It should work in sh and csh. Then
post it as reply to http://cygwin.com/ml/cygwin/2009-12/msg00090.html so
John can put it into the base-files package.
Our worked-out
Reini Urban schrieb:
perl has been updated to 5.10.1-1 as test in the Experimental section.
Important Changes since the last perl-5.10.0-5:
- for cygwin-1.7 and gcc-4 only
- added Win32CORE to the dll to enable libtool compilation (Yaakov).
This is a fragile hack but survived all attempts to
On Dec 2 18:21, Thomas Wolff wrote:
Corinna Vinschen wrote in another thread about setting LANG:
... Andy and Thomas, please work
out the best solution together. It should work in sh and csh. Then
post it as reply to http://cygwin.com/ml/cygwin/2009-12/msg00090.html so
John can put it into
On Wed, Dec 02, 2009 at 07:21:40PM +0100, Corinna Vinschen wrote:
On Dec 2 18:21, Thomas Wolff wrote:
Corinna Vinschen wrote in another thread about setting LANG:
... Andy and Thomas, please work
out the best solution together. It should work in sh and csh. Then
post it as reply to
On Wed, Dec 2, 2009 at 3:29 PM, Eliot Moss, wrote
Date: Wed, 02 Dec 2009 11:43:44 -0500
Subject: Re: 1.7 fork errors in Win7
Luis P Caamano wrote:
I'm running 1.7.0-67 on Windows 7 64 bit:
$ uname -v
2009-11-27 15:38
and I'm getting sporadic for errors like this one:
$ svn commit -m
Luis P Caamano wrote:
Thanks Eliot, I'll try that later tonight and I'll report back.
I'm also getting this kind of error from gvim (that I built myself to
add python to it):
2 [main] vim 7580 C:\cygwin\usr\local\bin\vim.exe: *** fatal
error - unable to remap
- Original Message -
From: Larry W. Virden
To: Cygwin
Sent: Wednesday, December 02, 2009 15:28
|I have been struggling to get Cygwin 1.7 cron to execute. I've been working
with the admin who
has rights to install Cygwin to get things set up appropriately. After another
round of
Hi!
I'm using cygwin and this command in a function works when I'm logged in as
me:
gzip -f ./$1.sql 2 error.log
so it zips hyperquest_v2.sql as the argument I send it is hyperquest_v2.
When this is run from NT AUTHORITY\SYSTEM as a scheduled task, I get an
error. So I put in some debug
Almo wrote:
Hi!
I'm using cygwin and this command in a function works when I'm logged in as
me:
gzip -f ./$1.sql 2 error.log
so it zips hyperquest_v2.sql as the argument I send it is hyperquest_v2.
When this is run from NT AUTHORITY\SYSTEM as a scheduled task, I get an
error. So I put in
kiorky wrote:
My related new 2.out, without improvments in term of performances (20min of
compilation).
Look, this is a completely wacky and random WAG, and it's not likely to
work, but... try turning off the shell icon overlays in the tortoisesvn
explorer shell extension, if you happen to
On 12/02/2009 04:47 PM, Almo wrote:
When this is run from NT AUTHORITY\SYSTEM as a scheduled task, I get an
error. So I put in some debug output: (I also have to specify where gzip.exe
is so that account can find it, hence the /usr/bin/ part)
echo /usr/bin/gzip -f ./$1.sql 2 error.log
Almo wrote:
echo /usr/bin/gzip -f ./$1.sql 2 error.log error.log
usr/bin/gzip -f ./$1.sql 2 error.log
The output I get is:
hyperquest_v2.sql
/usr/bin/gzip -f ./hyperquest_v2.sql 2 error.log
usr/bin/gzip: No such file or directory
It's not really as simple as the missing leading
Dave Korn-6 wrote:
Almo wrote:
echo /usr/bin/gzip -f ./$1.sql 2 error.log error.log
usr/bin/gzip -f ./$1.sql 2 error.log
The output I get is:
hyperquest_v2.sql
/usr/bin/gzip -f ./hyperquest_v2.sql 2 error.log
usr/bin/gzip: No such file or directory
It's not really as simple
On 12/02/2009 05:39 PM, Almo wrote:
Regarding Moss's suggestion, I did an echo `pwd` in there, and it IS in the
directory I think it is. I do an explicit cd command to make sure of that.
The missing slash is a typo in the message, sorry about that. I've copied
gzip.exe into my working
Dave Korn a écrit :
kiorky wrote:
Look, this is a completely wacky and random WAG, and it's not likely to
Not worth to try it ;)
work, but... try turning off the shell icon overlays in the tortoisesvn
explorer shell extension, if you happen to have them turned on.
Tried:
real
Have a script:
#!/usr/bin/bash
f=$(ls $1)
for v_file in $f; do
echo $v_file
done
named FileGroupContentsChange.sh.
Twos things do not work as they should. By order:
1) Output in command line for nest commands
ls /cygdrive/d/install/buf/*.html
dir /cygdrive/d/install/buf/*.html
is same:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Stephen @ gmail.com on 12/2/2009 2:24 PM:
Erik (et All).
Misspelled.
The same failure is happening under NTFS/Cygwin.
If so, then it is not happening on Win98SE, so your subject line is wrong.
You would have been better off
On 12/02/2009 08:20 PM, Sergey Ivanov wrote:
Have a script:
#!/usr/bin/bash
f=$(ls $1)
for v_file in $f; do
echo $v_file
done
named FileGroupContentsChange.sh.
Twos things do not work as they should. By order:
1) Output in command line for nest commands
ls /cygdrive/d/install/buf/*.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sergey Ivanov on 12/2/2009 6:12 PM:
Have a script:
#!/usr/bin/bash
f=$(ls $1)
The quotes around $(), while nice for consistency, are not strictly
necessary (since $() forms a word without quoting, and variable assignment
is not
I was in bash, and was using shell auto complete to cd to a directory.
I got to a point where it had placed backslashes in the path to quote dollar
signs and CYGWIN mistakenly threw-up, or threwout an error message about
using DOS PATHS. I wish it would revert to previous behavior and just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Linda Walsh on 12/2/2009 7:32 PM:
signs and CYGWIN mistakenly threw-up, or threwout an error message about
using DOS PATHS.
Read the manual. You can disable that warning, with the right CYGWIN
environment variable setting, if it
Hi,
Sorry to dredge up this thread from a few months ago, but I found myself
wanting to comment on more than just the segment I was originally
intending to cut and paste into a new discussion.
On 28/08/2009 7:50 AM, Christopher Faylor wrote:
On Thu, Aug 27, 2009 at 10:02:08PM +0100, Dave Korn
On Wed, Dec 02, 2009 at 07:44:42PM -0700, Eric Blake wrote:
According to Linda Walsh on 12/2/2009 7:32 PM:
signs and CYGWIN mistakenly threw-up, or threwout an error message
about using DOS PATHS.
Read the manual. You can disable that warning, with the right CYGWIN
environment variable setting,
I sometimes need to run bash scripts with directory references developed
in cygwin on Linux (Ubuntu) and very occasionally on SUA (Billy linux).
Any opinions as to if using /dev/fs/C is better or worse than
/cygdrive/C when mounting windozes disks in linux?
(/dev/fs seems best for SUA)
Thx
--
Hi all,
I put the following code into a shell script, e.g., test.sh:
awk 'FILENAME==ARGV[1]{a[$0]++; next} NF !a[$0]++' file1 file2
Then I invoke this shell script via a dos batch file which sit in the
same directory as the above shell script.
The dos batch file includes the following line
55 matches
Mail list logo
