Re: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 01:17, Christopher Faylor wrote:
> On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
> >In investigating this, I believe the issue I am having is due to how
> >stat() handles tilde prefixed paths. On linux we see:
> >
> >linux$ $ python -c 'import os; print os.stat("~/..")'
> >Traceback (most recent call last):
> > File "", line 1, in
> >OSError: [Errno 2] No such file or directory: '~/..'
> >
> >and on cygwin we see:
> >
> >cygwin$ python -c 'import os; print os.stat("~/..")'
> >posix.stat_result(st_mode=16832, st_ino=562949953496729L,
> >st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
> >st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
>
> It is a bug. It's not just "~". Any nonexistent directory will
> work, like "foo/..".
And it's a bug which isn't easily fixed. Since about the dawn of time,
Cygwin's core path handling evaluates the path in a non-POSIX manner,
mainly for performance reasons.
POSIX demands to evaluate a path from left to right (thus tripping over
the non-existant "~" or "foo" directory). Windows OTOH skips testing
all parent directories of a path, and while this can be changed(*), it's
the default setting since the earliest Windows NT versions.
So, since Cygwin can't rely on the OS to this job when it has to convert
a POSIX path to a Windows path internally, Cygwin would have to check
the existence of every single path component from left to right to
emulate the POSIX requirements. But that would be a big performance
hit, so Cygwin's path handling code tries to be clever to avoid having
to call too many OS functions:
The first step of converting a POSIX path to a Windows path is to
normalize the path. "." and ".." components are simply dropped:
"a/b/./c" -> "a\b\c"
"a/b/../c" -> "a\c"
Then the path prefix is replaced by the matching mount point.
Eventually it evaluates the path from right to left. Consider a valid,
normalized path with 10 components. Under POSIX rules this requires 10
checks for existence. No problem for the Linux kernel since it has
everything under control anyway and the test is blazingly fast.
But Cygwin is not the OS so it has to call the necessary OS functions 10
times. By checking from right to left, Cygwin has to call the OS
functions only once, if the file exists, two times if the file does not
exist, but its parent dir exists, and so on. On top of that, the entire
chore has to restart when tripping over a symbolic link.
Since the predominant number of file operations are performed on
existing paths, or at least paths for which the parent dir exists,
Cygwin reduces the number of OS operations to convert a POSIX to a
Windows path. The price we're paying is this very deviation from the
POSIX standard.
Corinna
(*) User right "Bypass Traverse Checking", by default enabled for
everyone.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Another issue with CLANG
Il 13/01/2013 16.20, Jon TURNEY ha scritto:
On 13/01/2013 14:44, Angelo Graziosi wrote:
Il 13/01/2013 15.31, Jon TURNEY ha scritto:
On 11/01/2013 12:54, Angelo Graziosi wrote:
An application which need to be built with clang++, fails to build when it
includes glx.h and indirectly windows.h headers like in the test case shown
below.
In short, X11/Xlib.h define Status as a macro (an alias for int) instead
rpcdce.h uses Status a a pointer variable name...
I don't think there's anything clang-specific about this problem. The same
issue can be seen with gcc.
If your application needs both Xlib and Win32 interfaces, you should include
rather than , which wraps any conflicting
declarations.
(xcb uses a sensible namespace, so this is not necessary for applications
which use xcb and Win32.)
You probably need the latest upstream x11proto (not yet packaged for cygwin)
for this wrapping to work correctly with the mingw-w64 w32api headers [1]
Alternatively you can work around this yourself e.g. as in [2]
Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true
application those headers were included indirectly... :-(
In file included from input_line_87:1:
In file included from include/TX11GL.h:29:
In file included from /usr/include/GL/glx.h:45:
In file included from /usr/include/w32api/GL/gl.h:13:
This looks very wrong, mixing native and X GL headers isn't going to work.
Assuming you mean to build an X application, this should be finding
/usr/include/GL/gl.h, so maybe an include path issue?
For the record...
ROOT guys have fixed this issue with the following patch to their
patched version of llvm/clang:
$ cat InitHeaderSearch.cpp.diff
---
ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2013-01-01 11:50:05.0 +0100
+++
root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2013-01-14 12:10:43.90625 +0100
@@ -305,7 +305,8 @@
case llvm::Triple::RTEMS:
break;
case llvm::Triple::Cygwin:
-AddPath("/usr/include/w32api", System, true, false, false);
+// The headers in w32api/ are not cygwin-compatible (but native)
+//AddPath("/usr/include/w32api", System, true, false, false);
break;
case llvm::Triple::MinGW32: {
// mingw-w64 crt include paths
Ciao,
Angelo.
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:70:
/usr/include/w32api/rpcdce.h:142:88: error: expected ')'
typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID
*TypeUuid,RPC_STATUS *Status);
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RES: hiding cursor on text terminals
>Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: >> Hello list, >> >> I have compiled a Linux ncurses gcc application on Cygwin. Everything works >> fine except for curs_set(0) calls which do not hide the cursor on text mode >> terminals (they work on X though). Does anybody know of a way to achieve >> this, even if it's not a portable solution? >The feature has been added to the cygwin console for the next release. >Thomas Nice, so I see you guys aren't so mean after all. Damian. Pelo quarto ano consecutivo, a Itautec é a empresa latino-americana melhor posicionada no ranking Fintech 100 que lista as maiores fornecedoras globais de TI para o setor financeiro. Saiba mais: www.itautec.com.br --- 0 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RES: hiding cursor on text terminals
On Jan 14 10:37, Damian Rodriguez Sanchez wrote: > >Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: > >> Hello list, > >> > >> I have compiled a Linux ncurses gcc application on Cygwin. Everything > works > >> fine except for curs_set(0) calls which do not hide the cursor on text > mode > >> terminals (they work on X though). Does anybody know of a way to achieve > >> this, even if it's not a portable solution? > >The feature has been added to the cygwin console for the next release. > >Thomas > > Nice, so I see you guys aren't so mean after all. What's that? Are you trying to undermine our bad reputation? ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Another issue with CLANG
On 14/01/2013 11:47, Angelo Graziosi wrote:
> Il 13/01/2013 16.20, Jon TURNEY ha scritto:
>> On 13/01/2013 14:44, Angelo Graziosi wrote:
>>> Il 13/01/2013 15.31, Jon TURNEY ha scritto:
On 11/01/2013 12:54, Angelo Graziosi wrote:
> An application which need to be built with clang++, fails to build when it
> includes glx.h and indirectly windows.h headers like in the test case
> shown
> below.
>
> In short, X11/Xlib.h define Status as a macro (an alias for int) instead
> rpcdce.h uses Status a a pointer variable name...
I don't think there's anything clang-specific about this problem. The same
issue can be seen with gcc.
If your application needs both Xlib and Win32 interfaces, you should
include
rather than , which wraps any conflicting
declarations.
(xcb uses a sensible namespace, so this is not necessary for applications
which use xcb and Win32.)
You probably need the latest upstream x11proto (not yet packaged for
cygwin)
for this wrapping to work correctly with the mingw-w64 w32api headers [1]
Alternatively you can work around this yourself e.g. as in [2]
>>>
>>>
>>> Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the
>>> true
>>> application those headers were included indirectly... :-(
>>>
>>> In file included from input_line_87:1:
>>> In file included from include/TX11GL.h:29:
>>> In file included from /usr/include/GL/glx.h:45:
>>> In file included from /usr/include/w32api/GL/gl.h:13:
>>
>> This looks very wrong, mixing native and X GL headers isn't going to work.
>>
>> Assuming you mean to build an X application, this should be finding
>> /usr/include/GL/gl.h, so maybe an include path issue?
>
> For the record...
>
> ROOT guys have fixed this issue with the following patch to their patched
> version of llvm/clang:
>
> $ cat InitHeaderSearch.cpp.diff
> --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
> 2013-01-01 11:50:05.0 +0100
> +++
> root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
> 2013-01-14 12:10:43.90625 +0100
> @@ -305,7 +305,8 @@
>case llvm::Triple::RTEMS:
> break;
>case llvm::Triple::Cygwin:
> -AddPath("/usr/include/w32api", System, true, false, false);
> +// The headers in w32api/ are not cygwin-compatible (but native)
> +//AddPath("/usr/include/w32api", System, true, false, false);
Well, ok. But this comment is almost completely wrong.
cygwin clang has /usr/include/w32api in the default include path (try
compiling your test program with clang -v), and since it appears *after*
/usr/include, including glx.h works correctly.
I have no idea what the right way to solve this problem is.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebuilding make
On 14.01.2013 10:19, Christopher Faylor wrote: Calm down and READ the message you received. It surely didn't tell you to send implied profanity to the Cygwin mailing list. Sorry, i don't really understand you. What do you mean under profanity ? Is it not allowed to post patches here ? -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -c 'import os; print os.stat("~/..")'
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 2] No such file or directory: '~/..'
and on cygwin we see:
cygwin$ python -c 'import os; print os.stat("~/..")'
posix.stat_result(st_mode=16832, st_ino=562949953496729L,
st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
It is a bug. It's not just "~". Any nonexistent directory will
work, like "foo/..".
And it's a bug which isn't easily fixed. Since about the dawn of time,
Cygwin's core path handling evaluates the path in a non-POSIX manner,
mainly for performance reasons.
Thank you both for your explanations. If my understanding is correct,
stat() will be returning for the current working directory.
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is the quick win to determine that.
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function, perhaps
called tilde_file_exists(), which determines if the tilde prefix forms
a directory component of the path (strchr('/')?). If it does not, the
file_exists() check is sufficient. If it does, then the check of if
that directory exists is logically and'ed to the result of
file_exists().
Does that sound about right?
--
Regards,
Shaddy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebuilding make
>On 14.01.2013 10:19, Christopher Faylor wrote: >On Mon, Jan 14, 2013 at 01:19:54AM -0500, Christopher Faylor wrote: >>On Mon, Jan 14, 2013 at 10:12:12AM +0400, Fedin Pavel wrote: >>>On 10.01.2013 23:47, Reini Urban wrote: Great! Can you gist the patches somewhere please? >>>I tried to post patches from my home email address. But messages get >>>rejected as spam. WTF ??? >> >>Calm down and READ the message you received. It surely didn't tell you >>to send implied profanity to the Cygwin mailing list. > >Sorry, i don't really understand you. What do you mean under profanity >? Is it not allowed to post patches here ? I was referring to your "WTF ???". I didn't say anything about not posting patches. Of course you can post patches. You apparently knew that your mail was rejected as spam because you received a bounce. The bounce gave you information which did not tell you to send a complaint here. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Rebuilding make
Fedin Pavel wrote: > On 14.01.2013 10:19, Christopher Faylor wrote: >> Calm down and READ the message you received. It surely didn't tell you >> to send implied profanity to the Cygwin mailing list. > > Sorry, i don't really understand you. What do you mean under profanity > ? Is it not allowed to post patches here ? "WTF" is implied profanity. cgf's point was that rather than complaining that your message was rejected, you'd have better luck reading the rejection email and follow the instructions there. -- Adam Dinwoodie Messages posted to this list are made in a personal capacity. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RES: hiding cursor on text terminals
On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: >On Jan 14 10:37, Damian Rodriguez Sanchez wrote: >> ???>Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: >> >> Hello list, >> >> >> >> I have compiled a Linux ncurses gcc application on Cygwin. Everything >> works >> >> fine except for curs_set(0) calls which do not hide the cursor on text >> mode >> >> terminals (they work on X though). Does anybody know of a way to achieve >> >> this, even if it's not a portable solution? >> >The feature has been added to the cygwin console for the next release. >> >Thomas >> >> Nice, so I see you guys aren't so mean after all. > >What's that? Are you trying to undermine our bad reputation? Well, just for that, how about if we don't release 1.7.18 until February at the latest? That will show everyone. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
>On Jan 14 01:17, Christopher Faylor wrote:
>> On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
>> >In investigating this, I believe the issue I am having is due to how
>> >stat() handles tilde prefixed paths. On linux we see:
>> >
>> >linux$ $ python -c 'import os; print os.stat("~/..")'
>> >Traceback (most recent call last):
>> > File "", line 1, in
>> >OSError: [Errno 2] No such file or directory: '~/..'
>> >
>> >and on cygwin we see:
>> >
>> >cygwin$ python -c 'import os; print os.stat("~/..")'
>> >posix.stat_result(st_mode=16832, st_ino=562949953496729L,
>> >st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
>> >st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
>>
>> It is a bug. It's not just "~". Any nonexistent directory will
>> work, like "foo/..".
>
>And it's a bug which isn't easily fixed. Since about the dawn of time,
>Cygwin's core path handling evaluates the path in a non-POSIX manner,
>mainly for performance reasons.
>
>POSIX demands to evaluate a path from left to right (thus tripping over
>the non-existant "~" or "foo" directory). Windows OTOH skips testing
>all parent directories of a path, and while this can be changed(*), it's
>the default setting since the earliest Windows NT versions.
>
>So, since Cygwin can't rely on the OS to this job when it has to convert
>a POSIX path to a Windows path internally, Cygwin would have to check
>the existence of every single path component from left to right to
>emulate the POSIX requirements. But that would be a big performance
>hit, so Cygwin's path handling code tries to be clever to avoid having
>to call too many OS functions:
>
>The first step of converting a POSIX path to a Windows path is to
>normalize the path. "." and ".." components are simply dropped:
>
> "a/b/./c" -> "a\b\c"
> "a/b/../c" -> "a\c"
>
>Then the path prefix is replaced by the matching mount point.
>
>Eventually it evaluates the path from right to left. Consider a valid,
>normalized path with 10 components. Under POSIX rules this requires 10
>checks for existence. No problem for the Linux kernel since it has
>everything under control anyway and the test is blazingly fast.
>
>But Cygwin is not the OS so it has to call the necessary OS functions 10
>times. By checking from right to left, Cygwin has to call the OS
>functions only once, if the file exists, two times if the file does not
>exist, but its parent dir exists, and so on. On top of that, the entire
>chore has to restart when tripping over a symbolic link.
>
>Since the predominant number of file operations are performed on
>existing paths, or at least paths for which the parent dir exists,
>Cygwin reduces the number of OS operations to convert a POSIX to a
>Windows path. The price we're paying is this very deviation from the
>POSIX standard.
Also:
c:\>dir foo\bar\..\..
Volume in drive S is share Serial number is e620:3c3d
Directory of S:\*
1/11/2013 9:58 .
12/26/2012 21:34 ..
1/12/2013 16:27 bin
1/14/2013 10:20 cgf
...
I don't have a foo directory but cmd was happy to just ignore that
fact and show my the root directory. This is YA place where Windows
and Linux differ drastically.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 10:27, Christopher Faylor wrote: > On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote: > >The first step of converting a POSIX path to a Windows path is to > >normalize the path. "." and ".." components are simply dropped: > > > > "a/b/./c" -> "a\b\c" > > "a/b/../c" -> "a\c" > >[...] > Also: > > c:\>dir foo\bar\..\.. > >Volume in drive S is share Serial number is e620:3c3d >Directory of S:\* > >1/11/2013 9:58 . > 12/26/2012 21:34 .. >1/12/2013 16:27 bin >1/14/2013 10:20 cgf >... > > I don't have a foo directory but cmd was happy to just ignore that > fact and show my the root directory. This is YA place where Windows > and Linux differ drastically. Indeed. Before writing my mail I tested the "GetFullPathName" function, and I was not exactly surprised to find that it behaves as you describe for CMD. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Jan 15 01:36, Shaddy Baddah wrote:
> Hi,
>
> On 14/01/13 21:00, Corinna Vinschen wrote:
> >On Jan 14 01:17, Christopher Faylor wrote:
> >>On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
> >>>In investigating this, I believe the issue I am having is due to how
> >>>stat() handles tilde prefixed paths. On linux we see:
> >>>
> >>>linux$ $ python -c 'import os; print os.stat("~/..")'
> >>>Traceback (most recent call last):
> >>> File "", line 1, in
> >>>OSError: [Errno 2] No such file or directory: '~/..'
> >>>
> >>>and on cygwin we see:
> >>>
> >>>cygwin$ python -c 'import os; print os.stat("~/..")'
> >>>posix.stat_result(st_mode=16832, st_ino=562949953496729L,
> >>>st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
> >>>st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
> >>
> >>It is a bug. It's not just "~". Any nonexistent directory will
> >>work, like "foo/..".
> >
> >And it's a bug which isn't easily fixed. Since about the dawn of time,
> >Cygwin's core path handling evaluates the path in a non-POSIX manner,
> >mainly for performance reasons.
>
> Thank you both for your explanations. If my understanding is correct,
> stat() will be returning for the current working directory.
In the above case, yes.
> It seems to me then that a patch to bash may be in order? I can see how
> the bash check is the right thing to do. It doesn't want the special
> tilde expansion to mask and disallow referencing of real tilde prefixed
> paths. So the stat() check is the quick win to determine that.
>
> From what I make of it, there needs to be a patch that, although can
> work generically, adds checks only required for Cygwin. And therefore
> is specific to the Cygwin package.
>
> The check would be an extension of the file_exists() function, perhaps
> called tilde_file_exists(), which determines if the tilde prefix forms
> a directory component of the path (strchr('/')?). If it does not, the
> file_exists() check is sufficient. If it does, then the check of if
> that directory exists is logically and'ed to the result of
> file_exists().
>
> Does that sound about right?
A check like this might be a good idea. Ultimately I would be glad to
be able to come up with more correct code in Cygwin while not getting
slower, of course. But that's wishful thinking for now.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On Mon, Jan 14, 2013 at 05:04:17PM +0100, Corinna Vinschen wrote: >On Jan 14 10:27, Christopher Faylor wrote: >> On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote: >> >The first step of converting a POSIX path to a Windows path is to >> >normalize the path. "." and ".." components are simply dropped: >> > >> > "a/b/./c" -> "a\b\c" >> > "a/b/../c" -> "a\c" >> >[...] >> Also: >> >> c:\>dir foo\bar\..\.. >> >>Volume in drive S is share Serial number is e620:3c3d >>Directory of S:\* >> >>1/11/2013 9:58 . >> 12/26/2012 21:34 .. >>1/12/2013 16:27 bin >>1/14/2013 10:20 cgf >>... >> >> I don't have a foo directory but cmd was happy to just ignore that >> fact and show my the root directory. This is YA place where Windows >> and Linux differ drastically. > >Indeed. Before writing my mail I tested the "GetFullPathName" function, >and I was not exactly surprised to find that it behaves as you describe >for CMD. Right. It's not just CMD. A standard windows program will behave similarly. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebuilding make
Hello, Christopher. 14 января 2013 г., 18:17:33, you wrote: > You apparently knew that your mail was rejected as spam because you > received a bounce. The bounce gave you information which did not tell > you to send a complaint here. Ah, sorry for being impolite... I asked only because there was no meaningful or useful information in the bounce message. It had only one line: "Spam score is too high". Well, does not matter any more. -- Kind regards, Pavel mailto:pavel_fe...@mail.ru -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RES: hiding cursor on text terminals
On Jan 14 10:20, Christopher Faylor wrote: > On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: > >On Jan 14 10:37, Damian Rodriguez Sanchez wrote: > >> ???>Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: > >> >> Hello list, > >> >> > >> >> I have compiled a Linux ncurses gcc application on Cygwin. Everything > >> works > >> >> fine except for curs_set(0) calls which do not hide the cursor on text > >> mode > >> >> terminals (they work on X though). Does anybody know of a way to achieve > >> >> this, even if it's not a portable solution? > >> >The feature has been added to the cygwin console for the next release. > >> >Thomas > >> > >> Nice, so I see you guys aren't so mean after all. > > > >What's that? Are you trying to undermine our bad reputation? > > Well, just for that, how about if we don't release 1.7.18 until February > at the latest? That will show everyone. The particulary mean part here is that you neglected to mention the year ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RES: hiding cursor on text terminals
On Mon, Jan 14, 2013 at 07:31:19PM +0100, Corinna Vinschen wrote: >On Jan 14 10:20, Christopher Faylor wrote: >>On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: >>>On Jan 14 10:37, Damian Rodriguez Sanchez wrote: ???>Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: >>Hello list, >> >>I have compiled a Linux ncurses gcc application on Cygwin. Everything works >>fine except for curs_set(0) calls which do not hide the cursor on text mode >>terminals (they work on X though). Does anybody know of a way to >>achieve this, even if it's not a portable solution? >The feature has been added to the cygwin console for the next release. >Thomas Nice, so I see you guys aren't so mean after all. >>> >>>What's that? Are you trying to undermine our bad reputation? >> >>Well, just for that, how about if we don't release 1.7.18 until >>February at the latest? That will show everyone. > >The particulary mean part here is that you neglected to mention the >year ;) Bwahaha. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 01:17, Christopher Faylor wrote: " It is a bug. It's not just "~". Any nonexistent directory will " work, like "foo/..". Corinna wrote: " And it's a bug which isn't easily fixed. Since about the dawn of time, " Cygwin's core path handling evaluates the path in a non-POSIX manner, " mainly for performance reasons. and: " Cygwin would have to check " the existence of every single path component from left to right to " emulate the POSIX requirements. and: " The first step of converting a POSIX path to a Windows path is to " normalize the path. "." and ".." components are simply dropped: " " "a/b/./c" -> "a\b\c" " "a/b/../c" -> "a\c" " " Then the path prefix is replaced by the matching mount point. and: " Ultimately I would be glad to " be able to come up with more correct code in Cygwin while not getting " slower, of course. But that's wishful thinking for now. Perhaps (as you may well have already considered): - replace the path prefix by the mount point first? (this may be naïve on my part, but it's not clear to me that .. early in a path should be able to influence which mount point is substituted) - test directory existence of the component preceding .. before collapsing (in the example above) b/.. to nothing. - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b before collapsing b/.. to nothing implies existence of b2 and b3 so no further tests are needed for 'runs' of .. components with enough components before them Understood that this is still going to cause a slowdown because paths with .. are not uncommon, but it would reduce the number of additional existence checks from one-per-path-component to one-per-run-of-.., which means none in the case of paths without .. in them. stephan();
adding noreturn attribute to pthread_exit
Hi, Calling pthread_exit() at the end of a routine marked noreturn produces a compiler warning/error on cygwin: error: 'noreturn' function does return Is it possible to add the attribute to the cygwin pthread.h: --- pthread.h.orig 2012-10-19 14:40:13.0 +0200 +++ pthread.h 2013-01-14 21:40:00.018198900 +0100 @@ -137,7 +137,7 @@ void *(*)(void *), void *); int pthread_detach (pthread_t); int pthread_equal (pthread_t, pthread_t); -void pthread_exit (void *); +void pthread_exit (void *) __attribute__((__noreturn__)); int pthread_getcpuclockid (pthread_t, clockid_t *); int pthread_getschedparam (pthread_t, int *, struct sched_param *); void *pthread_getspecific (pthread_key_t); (note, i didn't check how it needs to trickle down in the cygwin implementation of pthread_exit()) - antti -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: adding noreturn attribute to pthread_exit
On Mon, Jan 14, 2013 at 09:55:38PM +0100, Antti Kantee wrote: >Hi, > >Calling pthread_exit() at the end of a routine marked noreturn produces >a compiler warning/error on cygwin: > >error: 'noreturn' function does return > >Is it possible to add the attribute to the cygwin pthread.h: > >--- pthread.h.orig 2012-10-19 14:40:13.0 +0200 >+++ pthread.h 2013-01-14 21:40:00.018198900 +0100 >@@ -137,7 +137,7 @@ > void *(*)(void *), void *); > int pthread_detach (pthread_t); > int pthread_equal (pthread_t, pthread_t); >-void pthread_exit (void *); >+void pthread_exit (void *) __attribute__((__noreturn__)); > int pthread_getcpuclockid (pthread_t, clockid_t *); > int pthread_getschedparam (pthread_t, int *, struct sched_param *); > void *pthread_getspecific (pthread_key_t); I added a ChangeLog entry and checked this in. Thanks for the patch. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
On 14/01/2013 3:24 PM, Stephan Mueller wrote: Perhaps (as you may well have already considered): - replace the path prefix by the mount point first? (this may be naïve on my part, but it's not clear to me that .. early in a path should be able to influence which mount point is substituted) If I mount something at /foo/bar/baz, then /foo/bar/baz/../../blah definitely shouldn't end up inside baz. - test directory existence of the component preceding .. before collapsing (in the example above) b/.. to nothing. - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b before collapsing b/.. to nothing implies existence of b2 and b3 so no further tests are needed for 'runs' of .. components with enough components before them Understood that this is still going to cause a slowdown because paths with .. are not uncommon, but it would reduce the number of additional existence checks from one-per-path-component to one-per-run-of-.., which means none in the case of paths without .. in them. The rest seems totally reasonable to me, FWIW. I wouldn't put it past a Makefile (esp. one generated by autotools) or a gcc header search path to generate paths like: /a/b/c/d/../e/../f/../../../g/h (which resolves to a/g/h, if I counted dots correctly). Even then, though, it's "only" three checks to achieve posix-compliant behavior. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: stat() and tilde prefix (was bad bash tab completion)
Am 14.01.2013 11:00, schrieb Corinna Vinschen: ... The first step of converting a POSIX path to a Windows path is to normalize the path. "." and ".." components are simply dropped: "a/b/./c" -> "a\b\c" "a/b/../c" -> "a\c" which isn't correct already (even if everything exists) because if b is a symbolic link, "b/.." is *not* "." - (I think I came across this bug a few times already without really noticing it as a bug, having taken it as some spurious glitch...) (Not sure whether this case is covered by further arguments in this thread) -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Ctrl-C not working in snapshot
Am 13.01.2013 18:58, schrieb Thomas Wolff: When I tried the recent snapshot (2013-01-11) it turned out that Ctrl-C does not work anymore to interrupt a JVM program. There had been a similar discussion last year (http://cygwin.com/ml/cygwin/2012-07/msg00185.html) but it does not seem to be the same problem; in contrast to previous symptoms (http://cygwin.com/ml/cygwin/2012-08/msg00062.html), this time it fails in mintty but still works in the cygwin console. Also, it still worked for me with the 1.7.17 release. Bug gone with today's snapshot (*2013-01-14*). As I don't see in ChangeLog what might have fixed it, I checked further and it appeared with *2013-01-02.* At the same time, with an interactive Windows program (actually, the Scala interpreter), unlike Ctrl-C, Ctrl-D now works to terminate it, which it did not in the 1.7.17 release. Have to withdraw this. -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Another issue with CLANG
On Mon, 14 Jan 2013 13:43:26 +, Jon TURNEY wrote:
> On 14/01/2013 11:47, Angelo Graziosi wrote:
> > For the record...
> >
> > ROOT guys have fixed this issue with the following patch to their patched
> > version of llvm/clang:
> >
> > $ cat InitHeaderSearch.cpp.diff
> > --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
> >
> > 2013-01-01 11:50:05.0 +0100
> > +++
> > root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
> > 2013-01-14 12:10:43.90625 +0100
> > @@ -305,7 +305,8 @@
> >case llvm::Triple::RTEMS:
> > break;
> >case llvm::Triple::Cygwin:
> > -AddPath("/usr/include/w32api", System, true, false, false);
> > +// The headers in w32api/ are not cygwin-compatible (but native)
> > +//AddPath("/usr/include/w32api", System, true, false, false);
>
> Well, ok. But this comment is almost completely wrong.
>
> cygwin clang has /usr/include/w32api in the default include path (try
> compiling your test program with clang -v), and since it appears *after*
> /usr/include, including glx.h works correctly.
>
> I have no idea what the right way to solve this problem is.
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=blob;f=3.1-cygwin-includes.patch;h=1444765;hb=HEAD
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
deadlock with busy waiting on sigfe
Caused by executing following command and ctrl+c to interrupt in bash shell. sh -c "cd /tmp/openjpeg/src/bin/jp2 && /usr/bin/i686-pc-mingw32-gcc.exe -DOPJ_EXPORTS -ffast-math -O3 -DNDEBUG @CMakeFiles/opj_compress.dir/includes_C.rsp -o CMakeFiles/opj_compress.dir/convert.c.obj -c /tmp/openjpeg/src/bin/jp2/convert.c" SleepEx is being spammed across threads. some thread got tls lock but didn't released it. how can i fix the problem? (gdb) thread apply all bt Thread 3 (Thread 8576.0x1b30): #0 0x571ec771 in filename_completion_function () from /usr/bin/cygreadline7.dll #1 0x7c958f81 in ntdll!LdrShutdownThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x571ec3c0 in filename_completion_function () from /usr/bin/cygreadline7.dll #3 0x7c97fc9b in ntdll!RtlExitUserThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #4 0x7c97fc73 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/WINDOWS/system32/ntdll.dll #5 0x in ?? () Thread 2 (Thread 8576.0xe38): #0 0x7c801e8c in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll #1 0x610873f2 in yield () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251 #2 0x610d6da4 in _cygtls::lock() () from /usr/bin/cygwin1.dll #3 0x6103035e in sigpacket::setup_handler (this=0xc3ac34, handler=0x6102fdb0 , siga=..., tls=0x22ce64) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:797 #4 0x610319bb in sigpacket::process (this=0xc3ac34) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:1278 ---Type to continue, or q to quit--- #5 0x610dd38c in wait_sig () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/sigproc.cc:1415 #6 0x61003ea5 in cygthread::callfunc (this=0x6118b400 , issimplestub=) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:51 #7 0x6100442f in cygthread::stub (arg=0x6118b400 ) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:93 #8 0x6100538d in _cygtls::call2 (this=, func=0x610043e0 <_ZN9cygthread4stubEPv@4>, arg=0x6118b400 , buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99 #9 0x00c3ffb8 in ?? () #10 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #11 0x in ?? () Thread 1 (Thread 8576.0x27b8): #0 0x7c801e8d in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll #1 0x610873f2 in yield () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251 #2 0x610d6c8c in _sigfe () from /usr/bin/cygwin1.dll #3 0x61103990 in pthread_kill () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/thread.cc:3024 #4 0x610075fa in _cygwin_exit_return () ---Type to continue, or q to quit--- at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/dcrt0.cc:978 #5 0x6100538d in _cygtls::call2 (this=, func=0x61006bf0 , arg=0x0, buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99 #6 0x0022ff78 in ?? () #7 0x00465672 in ?? () #8 0x00401033 in ?? () #9 0x7c82f243 in ProcessIdToSessionId () from /cygdrive/c/WINDOWS/system32/kernel32.dll #10 0x in ?? () -- Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
