Re: directories named '...' (dotdotdot) do not work

Hello, and thanks for investigating this, > On 02/02/2011 02:53 PM, Corinna Vinschen wrote: > > Given that it works fine on Vista and Windows 7 anyway, is it really > > worth to add this extra code just to support an old OS in a very rare > > situation? FWIW, not for me. I was merely trying to

"file" command missing magic file (problem and solution)

I encountered the following problem with command "file" in CYGWIN_NT-5.1 v1.7.7 on a PC running Windows XP Professional. It took me half an hour to figure out what the issue was so I thought I will share this and hopefully spare others from having to go through the same. I have done a quick ch

Re: 16-bit wchar_t on Windows and Cygwin

Hi Eric, > I was asking: > > should wwchar_t (or xwchar_t, but not xchar_t) be 2-bytes on cygwin, but > unlike the POSIX definition of wchar_t being always 1 character per > unit, the new type is explicitly documented as being multi-unit on some > platforms but with sane semantics > > or should

Re: bad PATH conversion under XP

Le 02/02/2011 11:04, Corinna Vinschen a écrit : On Feb 1 23:41, Cyrille Lefevre wrote: I'm reporting a cygwin bug... of course I know I could edit the windows environment variables. however, this problem has to be fixed. I agree. It's not the user's fault that Windows applications and Wind

Re: 16-bit wchar_t on Windows and Cygwin

On 02/02/2011 04:03 PM, Bruno Haible wrote: >> Are you thinking of making a sane wrapping around either 4-byte wchar_t >> or which maps to 2-byte wchar_t but sanely handles UTF-16 (which makes >> it a thin wrapper on both Linux and Cygwin, but needing more work on >> mingw), or are you thinking tha

Re: 16-bit wchar_t on Windows and Cygwin

Hello Eric, > > Here's a new proposal: > > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > > on Windows platforms and to 'wchar_t' otherwise. > > - Define functions 'mbrtowwc', 'iswwalpha', 'wwcwidth', and similar. > > Their definition will be a trivial redirectio

Re: Bug in libiconv?

On 2/2/2011 4:19 PM, Corinna Vinschen wrote: > On Feb 2 19:58, Bruno Haible wrote: >> charset.alias is requested on Linux, even though it normally does not exist, >> so that packagers and users have a chance to modify the behaviour. > > I beg to keep this choice to Cygwin users as well. It will

Re: directories named '...' (dotdotdot) do not work

On Feb 2 23:11, Corinna Vinschen wrote: > On Feb 2 15:01, Eric Blake wrote: > > On 02/02/2011 02:53 PM, Corinna Vinschen wrote: > > > [...] > > > To fix that, we would have to scan the entire path for path components > > > which contain leading spaces or trailing dots or spaces. That makes > > >

Re: directories named '...' (dotdotdot) do not work

On Feb 2 15:01, Eric Blake wrote: > [re-adding Ralf, in case he's not subscribed] > > On 02/02/2011 02:53 PM, Corinna Vinschen wrote: > >> No, I'm using tcsh. Apparently you're right, it doesn't work in > >> XP, but it works in W7. Looks like Microsoft reworked the CreateProcess > >> call at so

Re: directories named '...' (dotdotdot) do not work

On Feb 2 22:55, Christian Franke wrote: > Corinna Vinschen wrote: > > > >Btw., the "..." directory is not recognized at all by cmd.exe. If you > >try to cd into it, it's simply ignored. If you set the CWD to it > >and start cmd, cmd thinks it is in the parent directory. This occurs > >on XP *an

Re: directories named '...' (dotdotdot) do not work

[re-adding Ralf, in case he's not subscribed] On 02/02/2011 02:53 PM, Corinna Vinschen wrote: >> No, I'm using tcsh. Apparently you're right, it doesn't work in >> XP, but it works in W7. Looks like Microsoft reworked the CreateProcess >> call at some point. I have an idea how this might be pos

Re: directories named '...' (dotdotdot) do not work

Corinna Vinschen wrote: Btw., the "..." directory is not recognized at all by cmd.exe. If you try to cd into it, it's simply ignored. If you set the CWD to it and start cmd, cmd thinks it is in the parent directory. This occurs on XP *and* W7. At least on XP cmd and others could not be

Re: directories named '...' (dotdotdot) do not work

On Feb 2 22:28, Corinna Vinschen wrote: > On Feb 2 13:56, Eric Blake wrote: > > On 02/02/2011 01:45 PM, Corinna Vinschen wrote: > > > Works fine for me: > > > > > > $ uname -a > > > CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin > > > $ cd tmp > > > $ mkdir ... > > >

Re: 16-bit wchar_t on Windows and Cygwin

On Feb 2 14:24, Eric Blake wrote: > [dropping coreutils at this point] > > On 02/02/2011 04:29 AM, Bruno Haible wrote: > > Good point. I agree then that overriding wchar_t should better not be > > done. > > > > Here's a new proposal: > > - Define a type 'wwchar_t' on all platforms, equivalent

bug#7971: Acknowledgement (Bug in libiconv?)

Thank you for filing a new bug report with GNU. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has be

Re: directories named '...' (dotdotdot) do not work

On Feb 2 22:28, Corinna Vinschen wrote: > On Feb 2 13:56, Eric Blake wrote: > > On 02/02/2011 01:45 PM, Corinna Vinschen wrote: > > > Works fine for me: > > > > > > $ uname -a > > > CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin > > > $ cd tmp > > > $ mkdir ... > > >

Re: directories named '...' (dotdotdot) do not work

On Feb 2 13:56, Eric Blake wrote: > On 02/02/2011 01:45 PM, Corinna Vinschen wrote: > > Works fine for me: > > > > $ uname -a > > CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin > > $ cd tmp > > $ mkdir ... > > $ cd ... > > $ cp /usr/bin/ls.exe . > > $ ./ls > >

Re: Windows 2008 64-bit install

On 2/2/2011 3:11 PM, Bryan Slatner wrote: > Thorsten Kampe thorstenkampe.de> writes: > >> I'd just delete everything and do a fresh minimal installation. If this >> fails again, you can continue here. First check >> http://cygwin.com/faq/faq.using.html#faq.using.bloda > > I'll do my best, but

Re: 16-bit wchar_t on Windows and Cygwin

[dropping coreutils at this point] On 02/02/2011 04:29 AM, Bruno Haible wrote: > Good point. I agree then that overriding wchar_t should better not be > done. > > Here's a new proposal: > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > on Windows platforms and to 'wcha

Re: Bug in libiconv?

Hi Bruno, On Feb 2 19:58, Bruno Haible wrote: > [resent to the cygwin list; please add bug-gnu-libiconv to your replies] Done. > Hi Corinna, > > Thanks for your reply > > > > Please CC the bug-gnu-libiconv mailing list when discussing possib

Re: directories named '...' (dotdotdot) do not work

On 02/02/2011 04:13 PM, Lee Rothstein wrote: On 2/2/2011 3:51 PM, marco atzeri wrote: > On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen wrote: >> On Feb 1 19:37, Ralf Wildenhues wrote: >>> The following fails for me (and web and list search haven't been helpful): >>> $ mkdir ... >>> $ cd

Re: directories named '...' (dotdotdot) do not work

On 2/2/2011 3:51 PM, marco atzeri wrote: > On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen wrote: >> On Feb 1 19:37, Ralf Wildenhues wrote: >>> The following fails for me (and web and list search haven't been helpful): >>> $ mkdir ... >>> $ cd ... >>> $ cp /usr/bin/ls.exe . >>> $ ./ls.exe

Re: Windows 2008 64-bit install

Thorsten Kampe thorstenkampe.de> writes: > I'd just delete everything and do a fresh minimal installation. If this > fails again, you can continue here. First check > http://cygwin.com/faq/faq.using.html#faq.using.bloda I'll do my best, but my order of operations when I got the failure was: 1

Re: directories named '...' (dotdotdot) do not work

On 02/02/2011 01:45 PM, Corinna Vinschen wrote: > Works fine for me: > > $ uname -a > CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin > $ cd tmp > $ mkdir ... > $ cd ... > $ cp /usr/bin/ls.exe . > $ ./ls > ls.exe > > I tried on NTFS, Samba and NFS. Difference

Re: directories named '...' (dotdotdot) do not work

On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen wrote: > On Feb  1 19:37, Ralf Wildenhues wrote: >> Hello Cygwin developers, >> >> The following fails for me (and web and list search haven't been helpful): >> >> $ mkdir ... >> $ cd ... >> $ cp /usr/bin/ls.exe . >> $ ./ls.exe >> bash: ./ls.exe: No

Re: directories named '...' (dotdotdot) do not work

On Feb 1 19:37, Ralf Wildenhues wrote: > Hello Cygwin developers, > > The following fails for me (and web and list search haven't been helpful): > > $ mkdir ... > $ cd ... > $ cp /usr/bin/ls.exe . > $ ./ls.exe > bash: ./ls.exe: No such file or directory > > Same with code compiled in this direc

Re: bug#7948: 16-bit wchar_t on Windows and Cygwin

On 2 February 2011 18:57, Bruno Haible wrote: > Hi Paul, > >> >   - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t >> >     on Windows platforms and to 'wchar_t' otherwise. >> >> As a minor point, would it be OK to call this type >> 'xchar_t' instead?  'x' is the successor to 'w'

Re: ssh-keygen command not doing anything OR github problem

On 2/2/2011 2:29 PM, mearrex wrote: > However, when I type in the commands > ssh > ssh-keygen > ssh-keygen -t rsa -C "xxx...@xxx.com" > ssh g...@github.com > ssh -v g...@github.com > > nothing happens. It just returns a new line. I am attaching a screenshot. > What am I doing wrong? What do I nee

ssh-keygen command not doing anything OR github problem

In my cygwin installation, I cannot seem to use github.com. However, here are the problems I am seeing. When I type in: git remote add origin g...@github.com:/first_app.git I got no issue. However, when I type in: git push origin master I get an error: fatal: The remote end hung up unexpectedly

Re: 16-bit wchar_t on Windows and Cygwin

On 2 February 2011 16:35, Corinna Vinschen wrote: > On Feb  2 17:28, Corinna Vinschen wrote: >> On Feb  2 17:02, Bruno Haible wrote: >> > But if you say that the application should convert UTF-16 surrogates >> > to UTF-32 before calling iswalpha: That's certainly a requirement >> > for Cygwin 1.7.x

Re: fiemap ioctl wishlist

On Wed, Feb 02, 2011 at 12:54:20PM -0700, Eric Blake wrote: >coreutils 8.10 is due soon, and has some (impressive) speedups for >copying sparse files on systems that support the FIEMAP ioctl. It seems >like Windows already has APIs for determining where the holes are in a >sparse file, so given en

fiemap ioctl wishlist

coreutils 8.10 is due soon, and has some (impressive) speedups for copying sparse files on systems that support the FIEMAP ioctl. It seems like Windows already has APIs for determining where the holes are in a sparse file, so given enough time and someone to write the patch, it would be nice to se

Re: cygwin bash-4.1.9-2

[adding the list: http://cygwin.com/acronyms/#PPIOSPE] On 02/02/2011 09:38 AM, Philipp Wiendl wrote: > Hello, > > today i installed cygwin v1.7 with the new v4 bash package. > I tried to run ssh-host-config and got following error: > > $ ssh-host-config -y > *** Query: Overwrite existing /etc/ss

directories named '...' (dotdotdot) do not work

Hello Cygwin developers, The following fails for me (and web and list search haven't been helpful): $ mkdir ... $ cd ... $ cp /usr/bin/ls.exe . $ ./ls.exe bash: ./ls.exe: No such file or directory Same with code compiled in this directory. Is this a bug or by design? This is from an Automake t

Re: Bug in libiconv?

[resent to the cygwin list; please add bug-gnu-libiconv to your replies] Hi Corinna, Thanks for your reply > > Please CC the bug-gnu-libiconv mailing list when discussing possible > > bugs in GNU libiconv. > > Ok Thanks for giving it a try. Bu

Re: bug#7948: 16-bit wchar_t on Windows and Cygwin

Hi Paul, > > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > > on Windows platforms and to 'wchar_t' otherwise. > > As a minor point, would it be OK to call this type > 'xchar_t' instead? 'x' is the successor to 'w', after all, > and it can be thought of as an abbrevi

Re: bug#7948: 16-bit wchar_t on Windows and Cygwin

On 02/02/11 03:29, Bruno Haible wrote: > - Define a type 'wwchar_t' on all platforms, equivalent to uint32_t > on Windows platforms and to 'wchar_t' otherwise. As a minor point, would it be OK to call this type 'xchar_t' instead? 'x' is the successor to 'w', after all, and it can be thought

Re: Where to find a reliable provider of CygwinX?

I want to terminate this discussion, originating from my concern for consistency among distribution providers. Originally I reported on a successful installation of basic Cygwin, i.e. without X, followed by a failing attempt to install X. Of course I have been aware all the way that X did not

Re: 1.7.7: window cuts off output / saving output

On 2/2/2011 10:44 AM, Jeremy Bopp wrote: > All of that is just a quick hack though because you could always have > output that is longer than your scrollback buffer. What follows is not > Cygwin-specific, but you don't seem to know about this stuff yet. Sorry to reply to myself, but I just realiz

Re: 1.7.7: window cuts off output / saving output

On Wed, Feb 2, 2011 at 10:13 AM, Rachel Trent wrote: > > Long version: > Within a larger script, I copied over a thousand files from one server > to another using the following command: > cp -R -n -p -v "$package" "$destination" | tee -a > "$destination"/copiedfiles.txt > > However, several file

Re: 1.7.7: window cuts off output / saving output

On 2/2/2011 10:13 AM, Rachel Trent wrote: > I have a seemingly simple problem that I either haven't found the > answer to or I didn't understand the answer when I saw it. I presume > I'm not describing it with the correct terminology... > > Short version: > In layman's terms, the Cygwin window cut

Fw: 1.7.7: window cuts off output / saving output

>On Feb 2 11:13, Rachel Trent wrote: >> I have a seemingly simple problem that I either haven't found the >> answer to or I didn't understand the answer when I saw it. I presume >> I'm not describing it with the correct terminology... >> >> Short version: >> In layman's terms, the Cygwin window c

Re: 1.7.7: window cuts off output / saving output

On Feb 2 11:13, Rachel Trent wrote: > I have a seemingly simple problem that I either haven't found the > answer to or I didn't understand the answer when I saw it. I presume > I'm not describing it with the correct terminology... > > Short version: > In layman's terms, the Cygwin window cuts off

Re: 16-bit wchar_t on Windows and Cygwin

On Feb 2 17:28, Corinna Vinschen wrote: > On Feb 2 17:02, Bruno Haible wrote: > > But if you say that the application should convert UTF-16 surrogates > > to UTF-32 before calling iswalpha: That's certainly a requirement > > for Cygwin 1.7.x application that want to support the entire Unicode > >

1.7.7: window cuts off output / saving output

I have a seemingly simple problem that I either haven't found the answer to or I didn't understand the answer when I saw it. I presume I'm not describing it with the correct terminology... Short version: In layman's terms, the Cygwin window cuts off at the top, and I'd like to know if the output t

Re: 16-bit wchar_t on Windows and Cygwin

Hi Bruno, On Feb 2 17:02, Bruno Haible wrote: > Hello Corinna, > > > And, please note the wording in SUSv4, for instance in > > http://calimero.vinschen.de/susv4/functions/iswalpha.html > > Likewise in POSIX:2008, at the URL > http://www.opengroup.org/onlinepubs/9699919799/functions/iswalpha.ht

Re: 16-bit wchar_t on Windows and Cygwin

Hello Corinna, > And, please note the wording in SUSv4, for instance in > http://calimero.vinschen.de/susv4/functions/iswalpha.html Likewise in POSIX:2008, at the URL http://www.opengroup.org/onlinepubs/9699919799/functions/iswalpha.html > The wc argument is a wint_t, the value of which the ap

Re: Looking for pointers to extended installation help

- Original Message - From:Larry Hall (Cygwin) > There's the section in the FAQ for common setup questions/issues: Thank you. We haven't started yet on the setup - there's always something that needs to be fixed... - I just thought I would do some pre-emptive research so that we had som

Re: Looking for pointers to extended installation help

On 2/2/2011 9:10 AM, Larry W. Virden wrote: A few years ago, I attempted to install cygwin on Windows XP and found that despite following the standard instructions, I was unsuccessful in getting cron to run, had some problems with gcc, etc. Are there additional cygwin tutorials, guides, helps, b

Looking for pointers to extended installation help

A few years ago, I attempted to install cygwin on Windows XP and found that despite following the standard instructions, I was unsuccessful in getting cron to run, had some problems with gcc, etc. Are there additional cygwin tutorials, guides, helps, books  that might provide more in-depth help

Re: 16-bit wchar_t on Windows and Cygwin

On Feb 2 13:14, Corinna Vinschen wrote: > On Feb 2 12:29, Bruno Haible wrote: > > Hello Eric, > > > > > ... POSIX requires that 1 wchar_t corresponds to 1 character > > > ... > > > > What consequences does this have? > > > > > > > > 1) All code that uses the functions from (wide character >

Re: 16-bit wchar_t on Windows and Cygwin

On Feb 2 12:29, Bruno Haible wrote: > Hello Eric, > > > ... POSIX requires that 1 wchar_t corresponds to 1 character > > ... > > > What consequences does this have? > > > > > > 1) All code that uses the functions from (wide character > > > classification and mapping) or wcwidth() malfunc

Re: Windows 2008 64-bit install

* Bryan Slatner (Tue, 1 Feb 2011 15:25:26 + (UTC)) > Thorsten Kampe thorstenkampe.de> writes: > > Why don't you simply run (at least) one of the scripts manually and > > see if you see an error?! > > I ran them all, with the following results: > > bash-3.2# /etc/postinstall/000-cygwin-post-i

Re: 16-bit wchar_t on Windows and Cygwin

Hello Eric, > ... POSIX requires that 1 wchar_t corresponds to 1 character > ... > > What consequences does this have? > > > > 1) All code that uses the functions from (wide character > > classification and mapping) or wcwidth() malfunctions on strings that > > contains Unicode chara

Re: bad PATH conversion under XP

On Feb 2 11:54, Matthias Andree wrote: > Am 02.02.2011 11:04, schrieb Corinna Vinschen: > > On Feb 1 23:41, Cyrille Lefevre wrote: > >> I'm reporting a cygwin bug... > >> of course I know I could edit the windows environment variables. > >> however, this problem has to be fixed. > > > > I agree.

Re: bad PATH conversion under XP

Am 02.02.2011 11:04, schrieb Corinna Vinschen: > On Feb 1 23:41, Cyrille Lefevre wrote: >> I'm reporting a cygwin bug... >> of course I know I could edit the windows environment variables. >> however, this problem has to be fixed. > > I agree. It's not the user's fault that Windows applications

Re: err.h declarations not marked noreturn.

On Feb 2 10:58, Corinna Vinschen wrote: > On Feb 1 16:45, Eric Blake wrote: > > On 02/01/2011 03:41 PM, Rusty Russell wrote: > > > OK, your /usr/include/err.h doesn't have the annotations to tell gcc that > > > it > > > doesn't return. > > > > I'm a bit surprised that cygwin provides the BSD in

Re: bad PATH conversion under XP

On Feb 1 23:41, Cyrille Lefevre wrote: > I'm reporting a cygwin bug... > of course I know I could edit the windows environment variables. > however, this problem has to be fixed. I agree. It's not the user's fault that Windows applications and Windows itself add paths to the environment using qu

Re: err.h declarations not marked noreturn.

On Feb 1 16:45, Eric Blake wrote: > On 02/01/2011 03:41 PM, Rusty Russell wrote: > > OK, your /usr/include/err.h doesn't have the annotations to tell gcc that it > > doesn't return. > > I'm a bit surprised that cygwin provides the BSD interface err() but > lacks the glibc interface error() from "

Re: err.h declarations not marked noreturn.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Eric Blake wrote, On 2.2.2011 0:45: > On 02/01/2011 03:41 PM, Rusty Russell wrote: >> OK, your /usr/include/err.h doesn't have the annotations to tell gcc that it >> doesn't return. > > I'm a bit surprised that cygwin provides the BSD interface err(