2009/9/22 Lapo Luchini:
> On a second reading, I guess you meant that *ONLY for LANG=C* and leave
> the current usage for LANG=xx_XX.UTF-8, is that so?
Yes, this thread is solely about the C locale.
Andy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygw
2009/9/22 Lapo Luchini:
> Andy Koppe wrote:
>> This way, the non-ASCII needs of most users are covered
>> out-of-the-box [...]
>> Windows filenames show up correctly in Cygwin as long as they're
>> limited to the ANSI codepage.
>
> I fail to see how that is a desiderable thing.
> Filesystem is UTF-
Lapo Luchini wrote:
> I fail to see how that is a desiderable thing.
> Filesystem is UTF-16, Cygwin is now Unicode-aware, but anything that
> doesn't fit ANSI is thrown away for the sake of retro-compatibility of
> Cygwin-1.5 which was not Unicode-aware?
On a second reading, I guess you meant that
Andy Koppe wrote:
> This way, the non-ASCII needs of most users are covered
> out-of-the-box [...]
> Windows filenames show up correctly in Cygwin as long as they're
> limited to the ANSI codepage.
I fail to see how that is a desiderable thing.
Filesystem is UTF-16, Cygwin is now Unicode-aware, bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Joel Eidsath wrote, On 21.9.2009 21:35:
> Boost has had a good number of libraries added between 1.33 and 1.40. Is
> there any chance we will get a version upgrade?
>
The Cygwin Boost package is currently unmaintained. Feel free to grab it,
prepare
Corinna Vinschen wrote:
> Sure. I was specificially asking for a testcase, preferrably in
> plain C, which allows to reproduce this under a debugger.
Actually, I can't reproduce that, but I guess it's a problem of the
specific console he's using (Thomas, which one is that?): on mintty it
works ok
Angelo Graziosi wrote:
> $ ls -lrt gnat1.exe*
> -rwxr-xr-x 1 root root 10045440 12 Mar 2009 gnat1.exe.orig
> -rw-r--r-- 1 root root 42546570 21 Sep 17:58 gnat1.exe
>
> (*Note* the size!)
*facepalm* doh. I must have rebuilt and installed a debug version on top of
my system install! Sorry! H
On 09/21/2009 08:27 PM, Kyle Stanek wrote:
Hello,
I'm having trouble getting the sshd service running under
cygwin. I am running Cygwin on Windows XP SP3. I have successfully
run ssh-host-config, however I get errors when I try and start the
service using cygrunsrv or net:
[fido ~]$ cygrun
On Mon, Sep 21, 2009 at 06:42:18PM -0500, Yaakov (Cygwin/X) wrote:
>On 21/09/2009 09:48, Christopher Faylor wrote:
>> gdb said that the failure was coming from libxcb-1.dll so I rebuilt
>> libxcb-1.dll with debugging information and with a version of
>> libcygwin.a containing debugging symbols.
>
>
Try run /usr/sbin/sshd and tell me the output.
2009/9/22 Kyle Stanek
>
>
> Hello,
>
> I'm having trouble getting the sshd service running under
> cygwin. I am running Cygwin on Windows XP SP3. I have successfully
> run ssh-host-config, however I get errors when I try and start the
> service us
Hello,
I'm having trouble getting the sshd service running under
cygwin. I am running Cygwin on Windows XP SP3. I have successfully
run ssh-host-config, however I get errors when I try and start the
service using cygrunsrv or net:
[fido ~]$ cygrunsrv --start sshd
cygrunsrv: Error starting a
On 21/09/2009 09:48, Christopher Faylor wrote:
gdb said that the failure was coming from libxcb-1.dll so I rebuilt
libxcb-1.dll with debugging information and with a version of
libcygwin.a containing debugging symbols.
Wait, did I just hear an argument for split debug packages? :-)
The fix fo
2009/9/21 Corinna Vinschen:
> Back from vacation I re-read this thread now and I have to say I just
> don't know what is the best course of action here.
I'm afraid I can only reiterate what I said previously.
Let's use the Windows "ANSI" codepage as the character set for the C
locale, for both th
On Thu, Sep 17, 2009 at 11:30:37AM -0400, Christopher Faylor wrote:
>On Thu, Sep 17, 2009 at 05:26:04AM -0600, Eric Blake wrote:
>>Is the transition to 1.7 a good time to change the ABI and offer a 64-bit
>>time_t type that won't overflow in 2038? Would we have to do the same
>>sort of transition
Boost has had a good number of libraries added between 1.33 and 1.40. Is
there any chance we will get a version upgrade?
--
Joel Eidsath
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
U
On Sep 17 01:55, Shaddy Baddah wrote:
> Hi Larry,
>
> Larry Hall (Cygwin) wrote:
>>
>>
>>
>>> Genuine bug?
>>
>> No, a feature. Having the existing drives show up under '/cygdrive'
>> is a convenience
>> for things like bash and other shells so that they can do completion
>> on the paths to
>
any chance rsnapshot 1.3.1 will be made available for cygwin
anytime soon?
thanks,
david
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubs
2009/9/21 Corinna Vinschen:
>> % cat t.c
>> int main() {
>> fopen("a-\xF6\xE4\xFC\xDF", "w"); //ISO-8859-1
>> fopen("b-\xF6\xE4\xFC\xDFz", "w");
>> fopen("c-\xF6\xE4\xFC\xDFzz", "w");
>> fopen("d-\xF6\xE4\xFC\xDFzzz", "w");
>> fopen("e-\xF6\xE4\xFC\xDF\xF6\xE4\xFC\xDF", "w");
>>
On Mon, Sep 21, 2009 at 05:19:35PM +0100, Dave Korn wrote:
> Therefore Cygwin should never be deployed to provide services to untrusted
>users on a 'net-facing server. It's just not a real OS(*).
Cygwin is not a floor wax either. It's just barely a dessert topping.
cgf
--
Problem reports:
On Mon, Sep 21, 2009 at 05:13:39PM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>>I can say that any DLL built with cygwin-1.7.0-51 - cygwin-1.7.0-56 is
>>probably suspect. That's 2009-07-13 - 2009-08-13 .
>
>Argh, that's my fault isn't it? Sorry for not figuring out we should
>have done th
On Mon, Sep 21, 2009 at 06:01:49PM +, Waldemar Rachwal wrote:
>Christopher Faylor writes:
>>This comment comes from a bug report which eventually resulted in a fix
>>to the linux kernel.
>
>Linux is useful, but isn't any proof. From the fact they change it,
>one of the implementation may be wr
Christopher Faylor cygwin.com> writes:
> >
> >To satisfy the condition (quoted from posix) "action is anything other
> >than to ignore", SIGCHLD (and all other signals which default action is
> >to ignore) must be setup a handler even if it seems "not useful".
> >Being blocked is not sufficient.
On Sep 21 18:52, Lapo Luchini wrote:
> Corinna Vinschen wrote:
> > On Sep 16 13:48, Thomas Wolff wrote:
> >> Hi,
> >> I see one small remaining glitch with Unicode display; non-BMP characters
> >> (those with Unicode value > 0x) are displayed as two boxes.
> >
> > Can you please create a simp
Corinna Vinschen wrote:
> On Sep 16 13:48, Thomas Wolff wrote:
>> Hi,
>> I see one small remaining glitch with Unicode display; non-BMP characters
>> (those with Unicode value > 0x) are displayed as two boxes.
>
> Can you please create a simple self-contained testcase? I'm not exactly
> sure
On Sep 16 13:48, Thomas Wolff wrote:
> Hi,
> I see one small remaining glitch with Unicode display; non-BMP characters
> (those with Unicode value > 0x) are displayed as two boxes.
> The reason is probably related to their representation as two
> surrogates at some point.
> I do not expect to
On Sep 14 14:29, Dmitry Semyonov wrote:
> Hello all,
>
> I recently had to switch CYGWIN environment of sshd service from
> 'ntsec' to 'nontsec' (because of 'sed -i' breaking inherited access
> rights to some files used by native Windows apps). All seem to work
> fine after the change, including p
On Sep 13 16:32, Christopher Faylor wrote:
> I just modified the test case from the original report:
>
> >>>cut here<<<
> #include
> #include
> #include
> #include
>
> main()
> {
> int flags = O_RDWR | O_NONBLOCK | O_CREAT | O_EXCL;
> struct mq_attr attr;
> char queue[80];
> char *e;
> m
Dave Korn wrote:
It's for
/usr/lib/gcc/i686-pc-cygwin/4.3.2/gnat1.exe,
While waiting for your answer, I did that, but it does not work. It
still hangs:
[...]
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada...
Now that you confirmed that gnat1.exe, I retrie
On Sep 16 00:38, Lapo Luchini wrote:
> Andy Koppe wrote:
> > Hmm, we've lost the \xDF somewhere, and I'd guess it was when the
> > filename got translated to UTF-16 in fopen(), which would explain what
> > you're seeing
>
> More data: it's not simply "the last character", is something more
> compl
Andrew McGill wrote:
> I can pwn the box from IIS by writing content to
> these files -- and not much creativity is needed to think of many more:
Waittaminnit, are you saying IIS by default lets you write any file you like
anywhere on the server and relies on ACLs to save it? I think you hav
Christopher Faylor wrote:
> I can say that any DLL built with cygwin-1.7.0-51 - cygwin-1.7.0-56
> is probably suspect. That's 2009-07-13 - 2009-08-13 .
Argh, that's my fault isn't it? Sorry for not figuring out we should have
done this when we first fixed that bug and thanks for putting in th
Angelo Graziosi wrote:
> Dave Korn wrote:
>> Alternatively, apply the attached hotfix using bspatch!
>
> Hi Dave,
>
> I think I haven't understood which file should be patched...
>
> I have tried this (which does not help):
ROFL, dur me; I didn't think about how this format doesn't have heade
On Mon, Sep 21, 2009 at 08:32:47AM +, Waldemar Rachwal wrote:
>Christopher Faylor cygwin.com> writes:
>>On Sat, Sep 19, 2009 at 10:31:58AM +, Waldemar Rachwal wrote:
>>>If the action associated with a blocked signal is anything other than
>>>to ignore the signal, and if that signal is gene
In cygwin 1.5, symlink("a",d) correctly failed with EEXIST regardless of
whether d was "dir", "dir/", or "dir/.". But in 1.7, it is failing with ENOENT
for just "dir/", and failing a gnulib test as a result. STC:
$ mkdir dir
$ ln -sT nowhere dir/.
ln: creating symbolic link `dir/.': File exist
On Sep 16 15:41, Dave Korn wrote:
> Dave Korn wrote:
>
> > I downloaded ftp://oss.sgi.com/projects/xfs/cmd_tars/attr_2.4.43-1.tar.gz
> > and found it builds OOTB, but my first attempt to use setfattr got me an
> > error:
> >
> >> $ ./setfattr/.libs/setfattr.exe -n bar -v baz foo
> >> setfattr:
On Mon, Sep 21, 2009 at 02:51:50AM -0500, Yaakov (Cygwin/X) wrote:
>On 20/09/2009 21:24, Christopher Faylor wrote:
>>This should be fixed in the next Cygwin snapshot and, subsequently, in
>>the next release.
>>
>>If you could test this and confirm that the snapshot fixes the problem
>>I'll roll a n
Corinna Vinschen wrote:
> The problem is, I don't know for sure what the best appraoch is, and it
> seems nobody except you and Iwamuro are actually interested to discuss
> this.
I don't know about anyone else, but I haven't chimed in because I don't
know enough about the issue to have an intellig
Corinna Vinschen wrote:
>> And if you try to create 'b\344h' in Cygwin 1.7, you actually get a file
>> called 'b', because the '\344' (0xE4) in ISO-8859-1 turns into an
>> encoding error when interpreted as UTF-8, and the name simply seems to
>> be truncated at that point.
>
> Yes, that *is* a pro
Lee D. Rothstein wrote:
> why are th e following files left in /etc/postinstall after each
> update/reinstall or initial install?:
>
> gcc-mingw-ada-3.4.4-20050522-1.tgz
> gcc-mingw-core-3.4.4-20050522-1.tgz
> gcc-mingw-g++-3.4.4-20050522-1.tgz
> gcc-mingw-g77-3.4.4-20050522-1.tgz
> gcc-mingw-gdc-
On Sep 9 13:42, Christopher Faylor wrote:
> On Wed, Sep 09, 2009 at 04:36:39PM +, Eric Blake wrote:
> >Eric Blake byu.net> writes:
> POSIX states that rename must fail with EINVAL if either argument ends
> in '.' or '..' (after trailing slashes are stripped). Cygwin 1.7 is
> dete
On Sep 3 10:38, Vince Indriolo wrote:
> Interesting, the location of the file seems to matter.
> [...]
> For a file on my desktop:
> $ ls -l foo
> -rwx--+ 1 vince None 6 Sep 3 10:28 foo
> $ ls -l .\\foo
> -rw-r--r-- 1 vince None 6 Sep 3 10:28 .\foo
It's not the location, it'
On Sep 8 22:49, Andy Koppe wrote:
> ps:
> > Maximum 1.5 compatibility (what for and how long?) vs. maximum
> > default usability in the long run (at least I hope so).
>
> Compatibilty for users upgrading to 1.7, who are used to being able to
> use the non-ASCII chars in their ANSI codepage, whic
Hi,
I ran setup.ext to install cygwin in c:\cygwin on a (fairly) fresh
installation of Windows Server 2008. On this server, the permissions of C:\
were set to allow new files to be created in subdirectories by BUILTIN\Users.
The cygwin folder inherited from the default permissions on C:\ the
Christopher Faylor cygwin.com> writes:
>
> On Sat, Sep 19, 2009 at 10:31:58AM +, Waldemar Rachwal wrote:
> >
> >If the action associated with a blocked signal is anything other than to
> >ignore the signal, and if that signal is generated for the thread,
> >
>
> Since the "above" never ment
On 20/09/2009 21:24, Christopher Faylor wrote:
This should be fixed in the next Cygwin snapshot and, subsequently, in the
next release.
>
If you could test this and confirm that the snapshot fixes the problem I'll
roll a new release. It turns out to be a pretty serious bug.
For me this fixe
45 matches
Mail list logo