[PATCH 0/2] Setup patches
Here's a couple of bonus patches I wrote when I was looking at setup at the end of last year. These are probably not suitable for immediately applying as there's room for doubt that they do the right thing, but I was reminded of them by the misunderstanding shown in [1], so here they are for comment. [1] http://sourceware.org/ml/cygwin/2011-01/msg00262.html Jon TURNEY (2): Copy setup.exe to /bin/cygwin-setup.exe Add a self-update mechanism for setup.exe desktop.cc | 45 +- ini.cc | 70 +-- libgetopt++/include/getopt++/DefaultFormatter.h |6 +- main.cc | 110 ++- res.rc |7 +- threebar.cc | 14 +++- threebar.h |1 + 7 files changed, 235 insertions(+), 18 deletions(-) -- 1.7.3.3
[PATCH 2/2] Add a self-update mechanism for setup.exe
Updating setup.exe has 3 stages:
1) Download updated setup.exe to a temporary location
2) Execute that temporary copy of setup.exe with --copy-to instructing
it to copy itself over the setup.exe to be updated
3) Execute the updated setup.exe with --remove-from instructing it
to delete the temporary copy
A named mutex is used to ensure setup exits from each stage before
the next stage can start.
Unfortunately, at the moment, we don't usefully check the setup version number
until after we have downloaded and parsed setup.ini, which is perhaps a bit
late to offer to update setup.exe
2011-02-02 Jon TURNEY jon.tur...@dronecode.org.uk
* res.rc (IDS_OLD_SETUP_VERSION): Change text to offer to download
new version of setup.
* main.cc:
(self_update_remove_from, self_update_copy_to, WinMain): Add
--copy-to and --remove-from options for self-update process.
* ini.cc (self_update_download): New function to
create download updated setup.
(do_ini_thread): Prompt to download updated setup if a newer
version exists. Return a result indicating what should happen
next.
* threebar.h (PropertyPage::OnFinish): Add an implementation of
OnFinish virtual function for this class.
* threebar.cc (OnFinish): Ditto.
(OnMessageApp): Setup should finish on
WM_APP_SETUP_INI_DOWNLOAD_COMPLETE
if an updated setup was downloaded.
2011-02-02 Jon TURNEY jon.tur...@dronecode.org.uk
* include/getopt++/DefaultFormatter.h (DefaultFormatter): Fix option
string
formatting when it has no short option.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
ini.cc | 70 +--
libgetopt++/include/getopt++/DefaultFormatter.h |6 +-
main.cc | 110 ++-
res.rc |2 +-
threebar.cc | 14 +++-
threebar.h |1 +
6 files changed, 189 insertions(+), 14 deletions(-)
diff --git a/ini.cc b/ini.cc
index d99bc60..7f265c1 100644
--- a/ini.cc
+++ b/ini.cc
@@ -285,7 +285,60 @@ do_remote_ini (HWND owner)
return ini_count;
}
-static bool
+static int
+self_update_download(HWND owner)
+{
+ /*
+XXX: do we need a mechanism for source of setup.exe to be overriden in
.ini file
+for the benefit of people who use a patched version? Or can they just
patch this
+as well? :-)
+ */
+#define SETUP_URL http://cygwin.com/setup.exe;
+
+ /* Download new setup to a temporary location */
+ std::string downloadedSetup = local_dir + \\setup.tmp.exe;
+ get_url_to_file (SETUP_URL, downloadedSetup, 0, owner);
+
+ /* Create and claim a mutex so the new version invoked with --copy-to doesn't
+ try to overwrite us before we've exited */
+ HANDLE mutex = CreateMutex(NULL, TRUE, Global\\Cygwin.Setup);
+ if (!mutex)
+{
+ log (LOG_PLAIN) CreateMutex failed : GetLastError () endLog;
+}
+
+ /* Invoke setup with same options + --copy-to current location */
+ std::string newArgs = downloadedSetup;
+
+ for (int i = 1; _argv[i]; i++)
+{
+ newArgs += ;
+ newArgs += _argv[i];
+}
+ TCHAR filename[MAX_PATH+1];
+ GetModuleFileName(NULL, filename, MAX_PATH);
+ newArgs += --copy-to=;
+ newArgs += filename;
+
+#ifdef DEBUG
+ log (LOG_BABBLE) newArgs endLog;
+#endif
+
+ PROCESS_INFORMATION processInfo;
+ STARTUPINFO startupInfo;
+ GetStartupInfo(startupInfo);
+ if (!CreateProcess(downloadedSetup.c_str(), (char *)(newArgs.c_str()),
+NULL, NULL, FALSE, 0, NULL, NULL, startupInfo,
processInfo) 0)
+{
+ log (LOG_PLAIN) CreateProcess failed : GetLastError () endLog;
+ // XXX: message box saying execute failed
+ return IDD_CHOOSE;
+}
+
+ return -1;
+}
+
+static int
do_ini_thread (HINSTANCE h, HWND owner)
{
size_t ini_count = 0;
@@ -295,7 +348,7 @@ do_ini_thread (HINSTANCE h, HWND owner)
ini_count = do_remote_ini (owner);
if (ini_count == 0)
-return false;
+return 0;
if (get_root_dir ().c_str())
{
@@ -339,11 +392,14 @@ do_ini_thread (HINSTANCE h, HWND owner)
if (ini_setup_version.size())
{
if (version_compare(setup_version, ini_setup_version) 0)
- note (owner, IDS_OLD_SETUP_VERSION, setup_version,
- ini_setup_version.c_str());
+if (yesno (owner, IDS_OLD_SETUP_VERSION, setup_version,
+ ini_setup_version.c_str()))
+ {
+return self_update_download(owner);
+ }
}
- return true;
+ return IDD_CHOOSE;
}
static DWORD WINAPI
@@ -354,10 +410,10 @@ do_ini_thread_reflector(void* p)
try
{
-bool succeeded = do_ini_thread((HINSTANCE)context[0], (HWND)context[1]);
+int nextpage = do_ini_thread((HINSTANCE)context[0], (HWND)context[1]);
// Tell the progress page that
Re: Can't use XDMCP, winProcEstablishConnection - ProcEstablishConnection failed, bailing shows in log
On 28/01/2011 20:23, Alexander Pokluda wrote: The Windows PC that I'm using is on a different subnet from the VMs that I need to connect to (10.3.20.159/24), so does that mean it's not possible to use Cygwin/X in this case? (Changing either subnet is not an option). Ah, I had assumed that you were running the VMs locally with some form of virtual networking. It certainly should be possible to configure XWin to work in your case. If you have multiple network interfaces on your PC, then it's probably just a question of using the -from option to ensure traffic is sent with the correct source address. If that doesn't fix it, perhaps you could provide a wireshark trace of the connection attempt and some more details of the networking configuration (e.g. output of 'ipconfig' and 'route print') On Fri, Jan 28, 2011 at 3:16 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 28/01/2011 19:19, Alexander Pokluda wrote: I've been trying for a while to get Cygwin/X working with XDMCP for quite a while without any success; however, I am able to conenct without any any problem using Xming 6.9. I'm using a Windows 7 PC to connect to a different Linux VMs running CentOS 5.5. After starting XWin from the command line (either directly or using startxdmcp.bat), a window opens up that contains nothing but black. At first when I move the cursor over the winodow, it just disappears but after a while, the cursor will appear as an X and the following shows up in the log file: [266377.900] winProcEstablishConnection - Hello [266377.900] winProcEstablishConnection - ProcEstablishConnection failed, bailing. [266385.653] winAboutDlgProc - WM_COMMAND - IDOK or IDCANCEL [266489.784] XDM: too many retransmissions, declaring session dead Any help would be greatly appreciated. I've included part of the log from one attempt to connect to one of the CentOS 5.5 VMs that I can connect to with Xming using XDMCP. [266616.722] XDM: too many retransmissions, declaring session dead Possibly you need to use -query 10.3.147.100 -from corresponding local IP for the subnet containing that IP address Xming has a patch applied which adds some more intelligence to the way the local IP address is chosen, but unfortunately that is written to use the winsock API directly, so can't be used directly in XWin. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-02-02 09:59:10 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (conv_path_list): Remove enclosing quotes and trailing backslashes from Win32 environment path lists. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5140r2=1.5141 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.621r2=1.622
src/winsup/cygwin ChangeLog include/err.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-02-02 10:16:30 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include: err.h Log message: * include/err.h (err): Add noreturn attribute. (errx): Ditto. (verr): Ditto. (verrx): Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5141r2=1.5142 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/err.h.diff?cvsroot=srcr1=1.1r2=1.2
src/winsup/cygwin ChangeLog include/err.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-02-02 15:14:46 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/include: err.h Log message: * include/err.h: Fix loss of semicolons in previous patch. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5142r2=1.5143 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/err.h.diff?cvsroot=srcr1=1.2r2=1.3
src/winsup/cygwin ChangeLog libc/bsdlib.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-02-02 15:17:14 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/libc: bsdlib.cc Log message: * libc/bsdlib.cc: Include err.h. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5143r2=1.5144 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/libc/bsdlib.cc.diff?cvsroot=srcr1=1.15r2=1.16
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() but lacks the glibc interface error() from error.h, even though both interfaces are equally non-standard, and cygwin strives more for Linux compatibility. But that's besides the point. It should not be surprising. Cygwin strives to be Linux compatbile using source code from *BSD systems. Implementation of err() can just be copied from *BSD. The GNU stuff has to be implemented from scratch, if I understand the lincense correctly. [...] - -- VH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk1JFikACgkQeqrf2dJjGj46tgD/XjOchRFz1bs2SdBFSvLsASmD Mgg9KNnBqLTtclj1i/8A/i3puCnHek6RtDiMBi2otJk+bP0wBsjx0nKwyaz+mYEF =xYk0 -END PGP SIGNATURE- -- 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: 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 error.h, even though both interfaces are equally non-standard, and cygwin strives more for Linux compatibility. [...] That's a clear case of http://cygwin.com/acronyms/#SHTDI http://cygwin.com/acronyms/#PTC Mine looks like so (Ubuntu): extern void err (int __status, __const char *__format, ...) __attribute__ ((__noreturn__, __format__ (__printf__, 2, 3))); But it is indeed the case that the BSD interface err() always calls exit() (see cygwin/libc/bsdlib.cc in the sources), and could therefore be marked noreturn in the headers if someone were to provide a patch. ...as long as we don't just copy the Linux headers for licensing reasons. I've CC'd the cygwin list: there might be a good reason why they don't have annotations on their err.h, or it might just be an omission. An unintentional omission, because no one has complained about it in the past. In fact, there are a LOT of useful gcc attributes that could be added to various headers throughout the cygwin and newlib projects. See above. 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: 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 quotes and trailing backslashes. I applied a patch which removes those, but only when Cygwin actually fetches the Win32 environment and initially converts the path lists like %Path%. This is not done when calling the cygwin_conv_path_list function from the application. 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: 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 interface err() but lacks the glibc interface error() from error.h, even though both interfaces are equally non-standard, and cygwin strives more for Linux compatibility. [...] That's a clear case of http://cygwin.com/acronyms/#SHTDI http://cygwin.com/acronyms/#PTC Mine looks like so (Ubuntu): extern void err (int __status, __const char *__format, ...) __attribute__ ((__noreturn__, __format__ (__printf__, 2, 3))); But it is indeed the case that the BSD interface err() always calls exit() (see cygwin/libc/bsdlib.cc in the sources), and could therefore be marked noreturn in the headers if someone were to provide a patch. ...as long as we don't just copy the Linux headers for licensing reasons. For now I added the noreturn attribute to the [v]err[x] functions. 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: 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 and Windows itself add paths to the environment using quotes and trailing backslashes. I applied a patch which removes those, but only when Cygwin actually fetches the Win32 environment and initially converts the path lists like %Path%. This is not done when calling the cygwin_conv_path_list function from the application. No offense intended, but is it useful to introduce such distinctions as to when/where/how the variable is fetched? It might cause hard-to-debug problems later on, don't you think? -- Matthias Andree -- 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: 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. It's not the user's fault that Windows applications and Windows itself add paths to the environment using quotes and trailing backslashes. I applied a patch which removes those, but only when Cygwin actually fetches the Win32 environment and initially converts the path lists like %Path%. This is not done when calling the cygwin_conv_path_list function from the application. No offense intended, but is it useful to introduce such distinctions as to when/where/how the variable is fetched? It might cause hard-to-debug problems later on, don't you think? Existing applications might rely on the existing behaviour, especially related to the backslash. 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: 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 wctype.h (wide character classification and mapping) or wcwidth() malfunctions on strings that contains Unicode characters outside the BMP, i.e. outside the range U+..U+. Not necessarily. Such code falls outside of POSIX, but it may still be a well-behaved extension if given sane behavior for how to deal with surrogates. No. Code that uses wctype.h and wcwidth() is written precisely according to POSIX. The problem is that this code cannot work correctly when wchar_t[] is in UTF-16 encoding. There simply is no way to define these functions in a reasonable way for surrogates. For example: U+1031E = 0xD800 0xDF1E is a letter (iswalpha should be true) U+10320 = 0xD800 0xDF20 is not a letter (iswalpha should be false) U+1D31E = 0xD834 0xDF1E is not a letter (iswalpha should be false) U+1D320 = 0xD834 0xDF20 is not a letter (iswalpha should be false) U+1D71E = 0xD835 0xDF1E is a letter (iswalpha should be true) U+1D720 = 0xD835 0xDF20 is a letter (iswalpha should be true) There is no way that a system can provide this information through a function 'iswalpha' that takes a single wchar_t argument. It would be possible to provide this information - either through a function iswalpha2 (wchar_t wc1, wchar_t wc2) that takes two wchar_t arguments, - or through a function uc_is_alpha (ucs4_t uc), but that is not POSIX, and it would require rewriting each and every piece of code that currently uses wctype.h in the POSIX way. we can (try) to make the various wc* functions try to behave as smartly as possible (as is the case with Cygwin); where those smarts are only needed when you use surrogate pairs. The point is that this approach can work fine for mbrtowc() and wcrtomb(), but it cannot yield a working definition for the wctype.h functions and wcwidth(). 2) Code that uses mbrtowc() or wcrtomb() is also likely to malfunction. On Cygwin = 1.7 mbrtowc() and wcrtomb() is implemented in an intelligent but somewhat surprising way: wcrtomb() may return 0, that is, produce no output bytes when it consumes a wchar_t. Now with a chinese character outside the BMP: $ 1 4 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 3 6 On Cygwin 1.7.5 (with LANG=C.UTF-8 and 'wc' from GNU coreutils 8.5): $ printf 'a\xf0\xa1\x88\xb4b\n' | wc -w -m 1 5 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 2 7 So both the number of characters and the number of words are counted wrong as soon as non-BMP characters occur. Does this represent a bug in cygwin's mbrtowc routines that could be fixed by cygwin? Or, does this represent a bug in coreutils for using mbrtowc one character at a time instead of something like mbsrtowcs to do bulk conversions? We agree that it is a bug. And it is caused by - the fact that Cygwin's wchar_t[] encoding is UTF-16, and - there is no way to define the wctype.h POSIX functions sanely in this setting, and - coreutils and gnulib make use of the POSIX functions. Even if coreutils were to use mbsrtowcs instead of repeated use of mbrtowc, there would be no way for it to produce the correct result without combining surrogates into entire characters. And if we decide that cygwin's extensions are sane, how much harder is it to characterize what a program must do to be portable to both 16-bit and 32-bit wchar_t if they are guaranteed the same behavior for all hosts of the same-size wchar_t? In other words, would it really require that many #ifdefs in coreutils to portably and simultaneously support both sizes of wchar_t? It would require 1. to change the conversions that use mbrtowc to either convert an entire string at once (use mbsrtowcs), or make a second call to mbrtowc once the first call to mbrtowc has determined a low surrogate. 2. to change all uses of wctype.h and wcwidth() to use different functions, either functions that take 2 wchar_t arguments, or functions that require the caller to combine the surrogates. This means, lots of logic that goes against the spirit of wchar_t in ANSI C Amd. 1 and POSIX. I'm more in favour of overriding wchar_t and all functions that depend on it - like we did successfully for the socket functions. In practice, this would mean that on Windows (both native Windows and Cygwin = 1.7) the use of a 'wchar_t' module will - override wchar_t to be 32 bits, like in glibc, - cause functions from mbrtowc() to wcwidth() to be overridden. Since the corresponding system functions are unusable, the replacements will use the modules from libunistring (such as unictype/ctype-alnum and uniwidth/width). ... compiler primitives, like
Re: Windows 2008 64-bit install
* Bryan Slatner (Tue, 1 Feb 2011 15:25:26 + (UTC)) Thorsten Kampe thorsten at 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-install.sh bash-3.2# /etc/postinstall/base-files-mketc.sh bash: /etc/postinstall/base-files-mketc.sh: Permission denied bash-3.2# /etc/postinstall/base-files-profile.sh bash: /etc/postinstall/base-files-profile.sh: Permission denied bash-3.2# /etc/postinstall/bash.sh bash-3.2# /etc/postinstall/coreutils.sh bash-3.2# /etc/postinstall/joe.sh bash-3.2# /etc/postinstall/man.sh bash-3.2# /etc/postinstall/terminfo.sh Segmentation fault (core dumped) bash-3.2# /etc/postinstall/terminfo0.sh bash-3.2# 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 Thorsten -- 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: 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 wctype.h (wide character classification and mapping) or wcwidth() malfunctions on strings that contains Unicode characters outside the BMP, i.e. outside the range U+..U+. Not necessarily. Such code falls outside of POSIX, but it may still be a well-behaved extension if given sane behavior for how to deal with surrogates. No. Code that uses wctype.h and wcwidth() is written precisely according to POSIX. The problem is that this code cannot work correctly when wchar_t[] is in UTF-16 encoding. There simply is no way to define these functions in a reasonable way for surrogates. For example: U+1031E = 0xD800 0xDF1E is a letter (iswalpha should be true) U+10320 = 0xD800 0xDF20 is not a letter (iswalpha should be false) U+1D31E = 0xD834 0xDF1E is not a letter (iswalpha should be false) U+1D320 = 0xD834 0xDF20 is not a letter (iswalpha should be false) U+1D71E = 0xD835 0xDF1E is a letter (iswalpha should be true) U+1D720 = 0xD835 0xDF20 is a letter (iswalpha should be true) There is no way that a system can provide this information through a function 'iswalpha' that takes a single wchar_t argument. iswalpha takes wint_t, not wchar_t. Since sizeof (wint_t) is 4 byte, the function can return the correct value, provided that the application converts the UTF-16 surrogate to UTF-32 before calling iswalpha. We agree that it is a bug. And it is caused by - the fact that Cygwin's wchar_t[] encoding is UTF-16, and - there is no way to define the wctype.h POSIX functions sanely in this setting, and See above. 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: 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 wctype.h (wide character classification and mapping) or wcwidth() malfunctions on strings that contains Unicode characters outside the BMP, i.e. outside the range U+..U+. Not necessarily. Such code falls outside of POSIX, but it may still be a well-behaved extension if given sane behavior for how to deal with surrogates. No. Code that uses wctype.h and wcwidth() is written precisely according to POSIX. The problem is that this code cannot work correctly when wchar_t[] is in UTF-16 encoding. There simply is no way to define these functions in a reasonable way for surrogates. For example: U+1031E = 0xD800 0xDF1E is a letter (iswalpha should be true) U+10320 = 0xD800 0xDF20 is not a letter (iswalpha should be false) U+1D31E = 0xD834 0xDF1E is not a letter (iswalpha should be false) U+1D320 = 0xD834 0xDF20 is not a letter (iswalpha should be false) U+1D71E = 0xD835 0xDF1E is a letter (iswalpha should be true) U+1D720 = 0xD835 0xDF20 is a letter (iswalpha should be true) There is no way that a system can provide this information through a function 'iswalpha' that takes a single wchar_t argument. iswalpha takes wint_t, not wchar_t. Since sizeof (wint_t) is 4 byte, the function can return the correct value, provided that the application converts the UTF-16 surrogate to UTF-32 before calling iswalpha. And, please note the wording in SUSv4, for instance in http://calimero.vinschen.de/susv4/functions/iswalpha.html The wc argument is a wint_t, the value of which the application shall ^^ ^^^ ensure is a wide-character code corresponding to a valid character in the current locale, or equal to the value of the macro WEOF. If the argument has any other value, the behavior is undefined. I don't see any words in that which would disallow to convert UTF-16 wchar_t surrogates to a wint_t UTF-32 value before calling one of the wctype functions. Just like you have to be careful not to call the ctype functions with a signed char. 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
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 for someone not particularly knowledgable in administering a unix setup? Maybe something oriented towards someone with more Windows experience? Thank you for any pointers you might be able to provide. -- Tcl - It's the real thing. http://wiki.tcl.tk/ http://www.facebook.com/lvirden/ Anything in this posting represents only my personal opinion. -- 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: Looking for pointers to extended installation help
- Original Message - From:Larry Hall (Cygwin) reply-to-list-only...@cygwin.com 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 some useful links before hand. I know that when we did this before, we used the FAQs, instructions, etc. but just could not figure out how to get things to work. I think this time we will probably start fresh, but I am going to see if I can figure out what packages are currently installed, so that we can at least start out with those already installed. -- Tcl - It's the real thing. http://wiki.tcl.tk/ http://www.facebook.com/lvirden/ Anything in this posting represents only my personal opinion. -- 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: 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 application shall ^^ ^^^ ensure is a wide-character code corresponding to a valid character in the current locale, or equal to the value of the macro WEOF. If the argument has any other value, the behavior is undefined. What this sentence means in formulas, is that when an application passes a 'wint_t x' to iswalpha(), it has to satisfy x == (wint_t) (wchar_t) x || x == EOF iswalpha takes wint_t, not wchar_t. Since sizeof (wint_t) is 4 byte, the function can return the correct value, provided that the application converts the UTF-16 surrogate to UTF-32 before calling iswalpha. When an application does this, is passes an invalid wint_t value to iswalpha(), according to the spec paragraph that you have just cited. So the application uses an extension to POSIX functionality, not POSIX itself. I see that Cygwin 1.7.x iswalpha() works in this way you describe (but mingw's iswalpha() doesn't). So this means that gnulib's proposed iswwalpha(wwchar_t) function could be implemented using iswalpha() on Cygwin 1.7.x and will not cause the Unicode based tables to be included in the executable. This is good and nice. 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 character set. But it's outside of POSIX, and many GNU programs will not want to include this added complexity. Just try to apply this suggestion to gnulib's quotearg.c, then estimate the time someone would need to apply it also to regcomp.c, strftime.c, mbscasestr.c, coreutils/src/wc.c, and so on. For this reason I propose the wwchar_t type with an API that is similar to POSIX wctype.h but includes the surrogate handling, rather than pushing it into each application's code. Bruno -- In memoriam Carl Friedrich Goerdeler http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler -- 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: 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.html Oops, sorry for the wrong URL! I'm using a local copy of SUSv4 for speed, but forgot that entirely when copy/pasting it. The wc argument is a wint_t, the value of which the application shall ^^ ^^^ ensure is a wide-character code corresponding to a valid character in the current locale, or equal to the value of the macro WEOF. If the argument has any other value, the behavior is undefined. What this sentence means in formulas, is that when an application passes a 'wint_t x' to iswalpha(), it has to satisfy x == (wint_t) (wchar_t) x || x == EOF Sure, I agree. But it doesn't say this *exactly*, so I took the liberty to stretch the limits a bit so that there is *some* way for applications to use the wctype functions despite using UTF-16 and despite having a surrogate value. iswalpha takes wint_t, not wchar_t. Since sizeof (wint_t) is 4 byte, the function can return the correct value, provided that the application converts the UTF-16 surrogate to UTF-32 before calling iswalpha. When an application does this, is passes an invalid wint_t value to iswalpha(), according to the spec paragraph that you have just cited. So the application uses an extension to POSIX functionality, not POSIX itself. Well, given that the description doesn't explicitely talk about a value given as wchar_t, but instead about a wide-character code corresponding to a valid character I saw some room for interpretation... I see that Cygwin 1.7.x iswalpha() works in this way you describe (but mingw's iswalpha() doesn't). So this means that gnulib's proposed iswwalpha(wwchar_t) function could be implemented using iswalpha() on Cygwin 1.7.x and will not cause the Unicode based tables to be included in the executable. This is good and nice. I'm glad you see it that way. 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 character set. But it's outside of POSIX, and many GNU programs will not want to include this added complexity. Just try to apply this suggestion to gnulib's quotearg.c, then estimate the time someone would need to apply it also to regcomp.c, strftime.c, mbscasestr.c, coreutils/src/wc.c, and so on. Cygwin's regcomp is taken from FreeBSD and is UTF-16 capable, including surrogate handling. It only required two changes in the code. But I see what you mean. Another layer which abstracts this problem looks like the right thing to do. 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
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 that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. 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 files failed to copy due to permissions issues/etc, and the copiedfiles.txt file does not include the error information. The onscreen output does include this information (due to using the -v verbose option), however I can only scroll up to see about 300 lines of information (surprise! I wasn't expecting this). My question is: can I somehow access the output that was cut off? In the Cygwin FAQ, there seem to be some references to limited memory and increasing buffers, but I'm not sure I fully understand them. Also, I have already run the script and the process has already been printed to the screen. I'm hoping for a retroactive fix. Seems like a simple issue, but I can't find anyone else talking about it! Thanks for your help, Rachel -- 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: 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 character set. But it's outside of POSIX, and many GNU programs will not want to include this added complexity. Just try to apply this suggestion to gnulib's quotearg.c, then estimate the time someone would need to apply it also to regcomp.c, strftime.c, mbscasestr.c, coreutils/src/wc.c, and so on. Cygwin's regcomp is taken from FreeBSD and is UTF-16 capable, including surrogate handling. It only required two changes in the code. Btw., I would be sure glad if Cygwin would use a wchar_t of 4 bytes as well. The problem is that this requires too many changes at once to work right, and it would introduce a lot of backward compatibility problems which would have to be handled. If only the one's who decided that wchar_t in Cygwin should have the same size as WCHAR_T in the underlying Windows would have thought twice about the implications... 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: 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 at the top, and I'd like to know if the output that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. 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 files failed to copy due to permissions issues/etc, and the copiedfiles.txt file does not include the error information. The onscreen output does include this information (due to using the -v verbose option), however I can only scroll up to see about 300 lines of information (surprise! I wasn't expecting this). My question is: can I somehow access the output that was cut off? This is not a Cygwin problem. The scrollback buffer is provided by the underying Windows console. You can change that in the console window properties dialog. 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
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 cuts off at the top, and I'd like to know if the output that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. 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 In the future, to capture the errors as well: cp -R -n -p -v $package $destination 21 | tee -a $destination/copiedfiles.txt However, several files failed to copy due to permissions issues/etc, and the copiedfiles.txt file does not include the error information. The onscreen output does include this information (due to using the -v verbose option), however I can only scroll up to see about 300 lines of information (surprise! I wasn't expecting this). My question is: can I somehow access the output that was cut off? This is not a Cygwin problem. The scrollback buffer is provided by the underying Windows console. You can change that in the console window properties dialog. -- 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: 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 cuts off at the top, and I'd like to know if the output that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. The exact solution for increasing your scrollback buffer is dependent upon the terminal you're using. If you're using mintty, you can find the option in the Options dialog within the Window section. If you're using the Windows cmd terminal, and it sounds like you are, you can find the option you need in the Properties dialog on the Layout tab. Change the height of the screen buffer to whatever you need. 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. If you need to be sure to always have your command's complete output available, you need to redirect its output to a file. e.g.) create_output --lots-of-it out.log If you would like to see the output as it goes by and still save it all, pipe your command's output to the tee program and give tee the path to a file as an argument into which the output will also be recorded. e.g.) create_output --lots-of-it | tee out.log Now you can review out.log at your leisure using a text editor or a simple pager. You can also just send the output to a nice pager such as less if you don't mind interacting with the pager a bit in order to let your command complete. e.g.) create_output --lots-of-it | less -Jeremy -- 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: 1.7.7: window cuts off output / saving output
On Wed, Feb 2, 2011 at 10:13 AM, Rachel Trent retr...@ncsu.edu wrote: snip 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 files failed to copy due to permissions issues/etc, and the copiedfiles.txt file does not include the error information. The onscreen output does include this information (due to using the -v verbose option), however I can only scroll up to see about 300 lines of information (surprise! I wasn't expecting this). My question is: can I somehow access the output that was cut off? I don't happen to think that tee is the right tool here. The standard way to do this and record the error messages is with redirection. In standard linux the screen output is from the stdout device and the error message is printed to the stderr device with a standard screen setup both stdout and stderr are the screen, but when you are recording data to a log file for historical needs, you have to redirect stderr to stdout so that the tee command can actually see it. add a 21 to the cp command at the end before the pipe, and tee will get the errors as well. BTW this is generically true for all POSIX compatible screen based tools. Rance -- 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: 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 realized that you *do* know about the tee program. That's what I get for being too aggressive with pruning quoted messages. -Jeremy -- 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: 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 come with the basic installation, and I have no idea of how to install X on top of it without using setup.exe by Cygwin. Still I am asked to specify how I obtained the packages for X, because they are not part of the basic installation. I see no reason to spend more time on this, the experience of which is like being part of an absurd comedy, to say it mildly. I feel confident that I can overcome the technical issues if I use the time on them instead. End of discussion. Jørgen -- 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: 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 of as an abbreviation for 'eXtended'. A problem with the 'ww' prefix is that mentally I start thinking World Wide ... -- 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: 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 abbreviation for 'eXtended'. 'wwchar_t' means wide wide character. In fact it's not really an extended character or complex character. It's just what POSIX calls a 'wchar_t'. I like the analogy between strtol and strtoll. In the beginning, people thought a 'long int' would be enough for everything. Then they discovered a 'long long int' is needed. The same story repeats itself here with the wide characters which turn out to be not wide enough, and wide wide characters are needed. A problem with the 'ww' prefix is that mentally I start thinking World Wide ... Indeed this meaning can come to mind, but I think it's not dangerous since the term world wide has no meaning in a programming language. Bruno -- In memoriam Carl Friedrich Goerdeler http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler -- 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: Bug in libiconv?
[resent to the cygwin list; please add bug-gnu-libiconv to your replies]
Hi Corinna,
Thanks for your reply http://cygwin.com/ml/cygwin/2011-01/msg00410.html
Please CC the bug-gnu-libiconv mailing list when discussing possible
bugs in GNU libiconv.
Ok
Thanks for giving it a try. But although you CCed bug-gnu-libiconv, your message
did not reach the list (but Charles' one and Eric's one did). I guess this is
because the cygwin.com mail server refuses to deliver to corinna-cygwin,
therefore the spam detection at gnu.org recognized your sending address as a
spammer's one. This makes it hard for me to detect that you replied to me,
since I'm not reading the cygwin mailing list on a regular basis.
I don't think defining __STDC_ISO_10646__
is compliant with ISO C 99 in this situation.
...
I don't read that from your above quote. The core is that the *type*
wchar_t is a *coded* *representation* of the characters defined in
10646.
OK.
What is the Cygwin wchar_t[] encoding? Is it UTF-16, like on Win32?
Yes.
...
yes, for the forseeable future, Cygwin will define wchar_t == UTF-16.
Thanks for confirming it. I've started thinking about how gnulib can
cope with it, now.
I've put a lot of effort in 2009 and early 2010 to make the wchar_t
representation in Cygwin and newlib as much Unicode 5.2 compatible as
possible. Even the wcrtomb and mbrtowc functions in newlib are capable
of dealing with UTF-16 surrogates.
I appreciate your effort on internationalization of Cygwin. You went as
far as you could get with the given choice of wchar_t. It's just a fact
that the wctype.h functions and wcwidth() cannot work right when wchar_t[]
is UTF-16. And these functions are the only reasons why gnulib and coreutils
code uses wide characters strings at all.
I'm not criticizing the Cygwin choice. Even if Cygwin had chosen to define
'wchar_t' to a 32-bit type, the same problem would have remained for mingw
programs running in UTF-8 or GB18030 locales. (I understand that such
locales exist in Windows 7.)
I don't quite grok the code at this point:
#if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__
if (sizeof(wchar_t) == 4) {
index = ei_ucs4internal;
break;
}
if (sizeof(wchar_t) == 2) {
index = ei_ucs2internal;
break;
}
if (sizeof(wchar_t) == 1) {
index = ei_iso8859_1;
break;
}
#endif
...
I *don't* understand that you do the same for Win32. Old
Windows versions are using the basic UCS-2 character plane, but newer
versions, at least since Windows XP are using UTF-16.
Thank you for this remark. I have corrected this in libiconv, and also
added support for Cygwin = 1.7 at the same place.
the application tests to convert a UTF-8 to WCHAR_T string in four
combinations of the current locale, in this order:
- iconv_open C, iconv C
- iconv_open C, iconv C.UTF-8
- iconv_open C.UTF-8, iconv C
- iconv_open C.UTF-8, iconv C.UTF-8
...
My testcase is a result of trying
to build a real-life application, gencat from glibc. For some reason
gencat thinks it has to set the locale back to C in a hardcoded manner.
This works fine for glibc systems, but the invisible and, IMHO,
intransparent behaviour of libiconv on other systems makes it pretty
hard to understand the behaviour of an application when porting it.
I don't see this as a particular intransparent behaviour of libiconv.
When taking code that was tested only in a single environment (glibc in this
case), you always have to make some effort to make it portable.
Is cygwin_conv_to_posix_path deprecated? Does it introduce limitations of
some kind?
Like the underlying Windows functions, Cygwin 1.7 now supports paths of
up to 32K chars. The old cygwin_conv_to_posix_path function and it's
friends are written with the Windows ANSI API in mind, so they only
support paths of up to MAX_PATH == 260 chars.
Thanks for explaining. I'll try to avoid this function.
The usage of a fixed table instaed of the charset.alias file in
libcharset/lib/localcharset.c, function get_charset_aliases() is
not good, not good at all.
The alternative is to have this table stored in a file charset.alias;
but then every package that includes the module 'localcharset' from
gnulib (that is, libiconv, gettext, coreutils, and many others) will
want to modify this file during make install. And this causes a lot of
headaches to packaging systems. Therefore, on platforms which have
widely used packaging systems (Linux, MacOS X, Cygwin), it's better to
avoid the need for this file.
Now I'm puzzled. If that's the case, why does libiconv request the
charset.alias file on *any* other system than DARWIN7, VMS, and Windows?
Especially on Linux?
I optimized only the MacOS X, VMS, and Windows OSes. It would have been
more work to optimize all versions of Solaris, FreeBSD, AIX, etc. in the
same
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 test failure, where configure failed in such a directory because the programs produced by a compilation could not be run: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7849. I would like to know whether we can close the bug as wontfix (and skip the test in question on Cygwin) due to system limitations. Thanks for maintaining Cygwin! Ralf -- 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: 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/ssh_config file? (yes/no) yes *** Info: Creating default /etc/ssh_config file Segmentation fault (core dumped) After a fallback to v3 bash package the setup for the sshd works fine. Maybe you can reproduce this issue and fix it. I have not seen that issue, and you're the first to report it, but I'll see if I can reproduce it. Meanwhile, could you run: bash -vx ssh-host-config -y to pinpoint where it crashes? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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 see the fiemap ioctl implemented in cygwin. http://www.mjmwired.net/kernel/Documentation/filesystems/fiemap.txt -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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 enough time and someone to write the patch, it would be nice to see the fiemap ioctl implemented in cygwin. http://www.mjmwired.net/kernel/Documentation/filesystems/fiemap.txt Maybe we should start adding wishlist items like this to the cygwin bugzilla. It would be nice to use it for something. 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: 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 application that want to support the entire Unicode character set. But it's outside of POSIX, and many GNU programs will not want to include this added complexity. Just try to apply this suggestion to gnulib's quotearg.c, then estimate the time someone would need to apply it also to regcomp.c, strftime.c, mbscasestr.c, coreutils/src/wc.c, and so on. Cygwin's regcomp is taken from FreeBSD and is UTF-16 capable, including surrogate handling. It only required two changes in the code. Btw., I would be sure glad if Cygwin would use a wchar_t of 4 bytes as well. The problem is that this requires too many changes at once to work right, and it would introduce a lot of backward compatibility problems which would have to be handled. Cygwin 1.7 might have been a good point for that change, because the lack of proper locale and charset support in previous versions meant that backward compatibility was much less of a concern than it is now. But it's a difficult change indeed, and it's not entirely clear that it's worthwhile. I guess 64-bit Cygwin (if or when it happens) might be the next opportunity. If only the one's who decided that wchar_t in Cygwin should have the same size as WCHAR_T in the underlying Windows would have thought twice about the implications... Windows Unicode support was introduced with Windows NT in 1993, whereas Unicode was only extended beyond 16 bits with version 2.0 in 1996. Cygwin was first released the year before. If the Unicode extension was a consideration at all (which I'd doubt), wchar_t != WCHAR probably seemed far more daunting than having to deal with surrogates at some point down the line. Andy -- 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
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:username/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 I have tried to do that using these instructions: http://help.github.com/msysgit-key-setup/ http://help.github.com/troubleshooting-ssh/ 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 need to do to get this to work? http://old.nabble.com/file/p30829947/screenshot.jpg -- View this message in context: http://old.nabble.com/ssh-keygen-command-not-doing-anything-OR-github-problem-tp30829947p30829947.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: 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 need to do to get this to work? My guess is that your Cygwin installation is incomplete or corrupted. Follow these instructions to provide the Cygwin developers the information they need to help you out: http://cygwin.com/problems.html -Jeremy -- 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: 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', after all, and it can be thought of as an abbreviation for 'eXtended'. 'wwchar_t' means wide wide character. In fact it's not really an extended character or complex character. It's just what POSIX calls a 'wchar_t'. It's extended in the sense that the original Unicode was only 16 bits wide (which of course is why wchar_t on Windows is 16 bits). Also, I think 'xchar_t' is less prone to typos, in particular forgetting one of the dubyas. Andy -- 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: 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 directory. Is this a bug or by design? 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. 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: 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 such file or directory Same with code compiled in this directory. Is this a bug or by design? 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. Corinna not working also here: $ uname -a CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin $ ./ls.exe bash: ./ls.exe: No such file or directory $ ./ls bash: ./ls: No such file or directory $ ls -l total 128 -rwxr-xr-x+ 1 Marco Administrators 129550 Feb 2 20:55 ls.exe Marco -- 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: 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 in Windows version? $ uname -a CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ pwd /tmp/... $ ls ls.exe $ ./ls bash: ./ls: No such file or directory or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Windows 2008 64-bit install
Thorsten Kampe thorsten at 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) Spin up a brand new EC2 Windows 2008 64-bit instance 2) Log in 3) Install Cygwin I literally did nothing else. So, if there is some dodgy software causing an issue, I may not have the luxury of uninstalling it. I haven't tried it myself, but I am told the same does NOT happen on a 32-bit W2K8 instance. Thanks, Bryan -- 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: 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 bash: ./ls.exe: No such file or directory Same with code compiled in this directory. Is this a bug or by design? 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. Corinna not working also here: $ uname -a CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin $ ./ls.exe bash: ./ls.exe: No such file or directory $ ./ls bash: ./ls: No such file or directory $ ls -l total 128 -rwxr-xr-x+ 1 Marco Administrators 129550 Feb 2 20:55 ls.exe Works for me on NTFS. $ uname -a CYGWIN_NT-6.0-WOW64 GW2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Conceivably, this could be a bug that might be important, but I have to ask: How good an idea is it to name a directory '...'? Let me take a crack at an answer: About as good an idea as embedding spaces in PATH names! I.e, don't do it unless Mr. Bill holds a gun to your head! Lee -- 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: 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 ... $ 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? 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. Corinna not working also here: $ uname -a CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin $ ./ls.exe bash: ./ls.exe: No such file or directory $ ./ls bash: ./ls: No such file or directory $ ls -l total 128 -rwxr-xr-x+ 1 Marco Administrators 129550 Feb 2 20:55 ls.exe Works for me on NTFS. $ uname -a CYGWIN_NT-6.0-WOW64 GW2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Conceivably, this could be a bug that might be important, but I have to ask: How good an idea is it to name a directory '...'? It's a supported directory name in that it is allowed. As such, if not working, it a bug. This is regardless if it's a good idea or not. -- Andrew DeFaria http://defaria.com Is it my imagination, or do buffalo wings taste like chicken? -- 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: 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 http://cygwin.com/ml/cygwin/2011-01/msg00410.html Please CC the bug-gnu-libiconv mailing list when discussing possible bugs in GNU libiconv. Ok Thanks for giving it a try. But although you CCed bug-gnu-libiconv, your message did not reach the list (but Charles' one and Eric's one did). I guess this is because the cygwin.com mail server refuses to deliver to corinna-cygwin, therefore the spam detection at gnu.org recognized your sending address as a spammer's one. This makes it hard for me to detect that you replied to me, since I'm not reading the cygwin mailing list on a regular basis. Uh, too bad. Sorry about that. I changed to my Red Hat email address for this discussion. I've put a lot of effort in 2009 and early 2010 to make the wchar_t representation in Cygwin and newlib as much Unicode 5.2 compatible as possible. Even the wcrtomb and mbrtowc functions in newlib are capable of dealing with UTF-16 surrogates. I appreciate your effort on internationalization of Cygwin. You went as far as you could get with the given choice of wchar_t. It's just a fact that the wctype.h functions and wcwidth() cannot work right when wchar_t[] is UTF-16. And these functions are the only reasons why gnulib and coreutils code uses wide characters strings at all. Well, as for the wctype functions you see how easy it is to convert to wint_t and use that as input. As for wcwidth, you're right. However, in Cygwin/newlib there's the wcswidth function which actually converts the input string to wint_t type characters including surrogate handling and then calls an internal __wcwidth function which works on wint_t types. So there is a way to handle this stuff by just using standard functions, and it isn't even overly complicated. I'm not criticizing the Cygwin choice. Even if Cygwin had chosen to define 'wchar_t' to a 32-bit type, the same problem would have remained for mingw programs running in UTF-8 or GB18030 locales. (I understand that such locales exist in Windows 7.) Right. However, GB18030 is not supported by Cygwin. ... I *don't* understand that you do the same for Win32. Old Windows versions are using the basic UCS-2 character plane, but newer versions, at least since Windows XP are using UTF-16. Thank you for this remark. I have corrected this in libiconv, and also added support for Cygwin = 1.7 at the same place. Thanks! the application tests to convert a UTF-8 to WCHAR_T string in four combinations of the current locale, in this order: - iconv_open C, iconv C - iconv_open C, iconv C.UTF-8 - iconv_open C.UTF-8, iconv C - iconv_open C.UTF-8, iconv C.UTF-8 ... My testcase is a result of trying to build a real-life application, gencat from glibc. For some reason gencat thinks it has to set the locale back to C in a hardcoded manner. This works fine for glibc systems, but the invisible and, IMHO, intransparent behaviour of libiconv on other systems makes it pretty hard to understand the behaviour of an application when porting it. I don't see this as a particular intransparent behaviour of libiconv. When taking code that was tested only in a single environment (glibc in this case), you always have to make some effort to make it portable. Oh, I meant my gencat experience just as an example. IMHO this behaviour is intransparent, no matter what you're trying to port, and where from you're taking it. I mean, if you're trying to call iconv for a conversion from some codeset A to a codeset B, which are both explicitely mentioned when calling iconv_open, then it is intransparent behaviour that the conversion fails because you called setlocale with a codeset C. There is no apparent connection between the two actions. The conversion from A to B could be required for a file operation, while C is the CLI or GUI charset. Do you see what I mean? Is cygwin_conv_to_posix_path deprecated? Does it introduce limitations of some kind? Like the underlying Windows functions, Cygwin 1.7 now supports paths of up to 32K chars. The old cygwin_conv_to_posix_path function and it's friends are written with the Windows ANSI API in mind, so they only support paths of up to MAX_PATH == 260 chars. Thanks for explaining. I'll try to avoid this function. There should be no reason to call cygwin_conv_path functions, unless you have a direct interaction with native Win32 functions. So you can most easily avoid using them at all by using the relocation technique from Linux, utilizing /proc/self/maps, which in turn drops the requirement for the DLLMain function. The usage of a fixed table instaed of the charset.alias file in libcharset/lib/localcharset.c, function get_charset_aliases() is not good, not good at
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 'wchar_t' otherwise. - Define functions 'mbrtowwc', 'iswwalpha', 'wwcwidth', and similar. Their definition will be a trivial redirection to 'mbrtowc', 'iswalpha', 'wcwidth' on most platforms, and a use of libunistring modules on Windows platforms. I like the idea of making a new type wrapper. 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 that it is always a 4-byte type (needing lots more memory manipulation on cygwin to convert between 2- and 4-byte representations when using cygwin's functions, or else reimplementing everything from scratch by completely bypassing cygwin)? As to the name: I agree the opinion of others that xchar_t is easier to type and easier to avoid typos of a missing 'w' than wwchar_t. On the other hand, I can see wwprintf that takes wide-wchar_t values, but gnulib already has xprintf as a counterpart to xmalloc (which calls exit() if the printf fails for memory allocation or other non-I/O related reasons), so we can't blindly use 'x' instead of 'ww' when replacing existing 'w' in POSIX APIs. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Windows 2008 64-bit install
On 2/2/2011 3:11 PM, Bryan Slatner wrote: Thorsten Kampe thorsten at 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) Spin up a brand new EC2 Windows 2008 64-bit instance 2) Log in 3) Install Cygwin I literally did nothing else. So, if there is some dodgy software causing an issue, I may not have the luxury of uninstalling it. I haven't tried it myself, but I am told the same does NOT happen on a 32-bit W2K8 instance. Could this be related to this earlier thread? http://cygwin.com/ml/cygwin/2010-09/msg00212.html -Jeremy -- 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: 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 ls.exe I tried on NTFS, Samba and NFS. Difference in Windows version? $ uname -a CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ pwd /tmp/... $ ls ls.exe $ ./ls bash: ./ls: No such file or directory or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)? 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 possible to workaround. Stay tuned. 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: 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 ... $ cd ... $ cp /usr/bin/ls.exe . $ ./ls ls.exe I tried on NTFS, Samba and NFS. Difference in Windows version? $ uname -a CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ pwd /tmp/... $ ls ls.exe $ ./ls bash: ./ls: No such file or directory or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)? 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 possible to workaround. Stay tuned. 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. 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
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 been sent to the package maintainer(s): bug-coreut...@gnu.org If you wish to submit further information on this problem, please send it to 7...@debbugs.gnu.org. Please do not send mail to help-debb...@gnu.org unless you wish to report a problem with the Bug-tracking system. -- 7971: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7971 GNU Bug Tracking System Contact help-debb...@gnu.org with problems -- 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: 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 to uint32_t on Windows platforms and to 'wchar_t' otherwise. - Define functions 'mbrtowwc', 'iswwalpha', 'wwcwidth', and similar. Their definition will be a trivial redirection to 'mbrtowc', 'iswalpha', 'wcwidth' on most platforms, and a use of libunistring modules on Windows platforms. I like the idea of making a new type wrapper. 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 that it is always a 4-byte type (needing lots more memory manipulation on cygwin to convert between 2- and 4-byte representations when using cygwin's functions, or else reimplementing everything from scratch by completely bypassing cygwin)? As to the name: I agree the opinion of others that xchar_t is easier to type and easier to avoid typos of a missing 'w' than wwchar_t. On the other hand, I can see wwprintf that takes wide-wchar_t values, but gnulib already has xprintf as a counterpart to xmalloc (which calls exit() if the printf fails for memory allocation or other non-I/O related reasons), so we can't blindly use 'x' instead of 'ww' when replacing existing 'w' in POSIX APIs. May I suggest a compromise? What about xwchar_t? It avoids the potential typo by accidentally dropping the second w. It still contains wchar which implies that it's a *wide* char type. And the x could be read as extended. 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: 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 ... $ cd ... $ cp /usr/bin/ls.exe . $ ./ls ls.exe I tried on NTFS, Samba and NFS. Difference in Windows version? $ uname -a CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ pwd /tmp/... $ ls ls.exe $ ./ls bash: ./ls: No such file or directory or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)? 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 possible to workaround. Stay tuned. Yes, my workaround works. What happens is that XP's CreateProcess calls an internal function at one point which drops leading spaces and trailing dots and spaces from the path, since these were always invalid in DOS paths. And a path component which consists entirely of dots and/or spaces is just invisible from a DOS path perspective. However, if the path to the executable is prepended by the long-path prefix \\?\, then the CreateProcess function understands the path even on XP since the prefix suppresses the DOS path strangling. However, that's not a generic solution. At one point we deliberately dropped the preceeding \\?\ because this breaks some native Win32 child processes which are not long-path aware. So, right now, we only keep the long-path prefix if the path is actually longer than MAX_PATH. 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 fork even slower than it already is. 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? 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: 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 run from a subdir below ...: $ /bin/pwd /tmp/... $ cmd.exe /c cd C:\cygwin\tmp $ mkdir x $ cd x # /bin/pwd /tmp/.../x # cmd.exe /c cd -bash: /cygdrive/c/WINDOWS/system32/cmd.exe: Not a directory Same for , ., Different path checking in win32api layer and ntdll layer ? I would suggest to either quote or reject ... in Cygwin. Christian -- 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: 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 possible to workaround. Stay tuned. Yes, my workaround works. What happens is that XP's CreateProcess calls an internal function at one point which drops leading spaces and trailing dots and spaces from the path, since these were always invalid in DOS paths. And a path component which consists entirely of dots and/or spaces is just invisible from a DOS path perspective. However, if the path to the executable is prepended by the long-path prefix \\?\, then the CreateProcess function understands the path even on XP since the prefix suppresses the DOS path strangling. However, that's not a generic solution. At one point we deliberately dropped the preceeding \\?\ because this breaks some native Win32 child processes which are not long-path aware. So, right now, we only keep the long-path prefix if the path is actually longer than MAX_PATH. 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 fork even slower than it already is. Well, that would only be if the path is shorter than MAX_PATH (256) bytes, so it's not like we have a quadratic scaling problem over thousands of bytes. Furthermore, using a directory literally named '...' already causes problems for windows programs that ar not long-path aware, so the workaround is no worse than what they currently get from such a path. But you're right, that taking the time to scan for any occurrence of: '.\', './', '/.', ' \', ' /' and checking for five patterns across 256 bytes definitely adds time. 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? Can't we make the scan conditional on the windows version? That is, spend the extra time to keep XP happy, but skip the scan on newer Windows? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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 *and* W7. At least on XP cmd and others could not be run from a subdir below ...: $ /bin/pwd /tmp/... $ cmd.exe /c cd C:\cygwin\tmp $ mkdir x $ cd x # /bin/pwd /tmp/.../x # cmd.exe /c cd -bash: /cygdrive/c/WINDOWS/system32/cmd.exe: Not a directory Same for , ., Different path checking in win32api layer and ntdll layer ? Yes, definitely. I explained that in http://cygwin.com/ml/cygwin/2011-02/msg00078.html On the Win32 level the path is massaged so that it follows DOS filename conventions. This is not done on the native NT level. The long-path prefix when used on the Win32 level (but only in the UNICODE API) disables the DOSifying and just passes the path through to the native NT API. I would suggest to either quote or reject ... in Cygwin. Given that the path works fine except for starting an executable, and given that starting an app works fine in Vista and later, there's no reason to disallow the ... path component entirely. I'm not giving in to the old DOS path conventions, unless there's absolutely no way around it. 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: 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 some point. I have an idea how this might be possible to workaround. Stay tuned. Yes, my workaround works. What happens is that XP's CreateProcess calls an internal function at one point which drops leading spaces and trailing dots and spaces from the path, since these were always invalid in DOS paths. And a path component which consists entirely of dots and/or spaces is just invisible from a DOS path perspective. However, if the path to the executable is prepended by the long-path prefix \\?\, then the CreateProcess function understands the path even on XP since the prefix suppresses the DOS path strangling. However, that's not a generic solution. At one point we deliberately dropped the preceeding \\?\ because this breaks some native Win32 child processes which are not long-path aware. So, right now, we only keep the long-path prefix if the path is actually longer than MAX_PATH. 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 fork even slower than it already is. Well, that would only be if the path is shorter than MAX_PATH (256) bytes, so it's not like we have a quadratic scaling problem over thousands of bytes. Furthermore, using a directory literally named '...' already causes problems for windows programs that ar not long-path aware, so the workaround is no worse than what they currently get from such a path. But you're right, that taking the time to scan for any occurrence of: '.\', './', '/.', ' \', ' /' and checking for five patterns across 256 bytes definitely adds time. 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? Can't we make the scan conditional on the windows version? That is, spend the extra time to keep XP happy, but skip the scan on newer Windows? I'm not opposed to a pre-Vista workaround. The code should be added to the if (runpath) code starting at line 494 in spawn.cc. If you have an idea how to do this test as fast as possible, please send a patch. 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: 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 fork even slower than it already is. Well, that would only be if the path is shorter than MAX_PATH (256) bytes, so it's not like we have a quadratic scaling problem over thousands of bytes. Furthermore, using a directory literally named '...' already causes problems for windows programs that ar not long-path aware, so the workaround is no worse than what they currently get from such a path. But you're right, that taking the time to scan for any occurrence of: '.\', './', '/.', ' \', ' /' and checking for five patterns across 256 bytes definitely adds time. 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? Can't we make the scan conditional on the windows version? That is, spend the extra time to keep XP happy, but skip the scan on newer Windows? I'm not opposed to a pre-Vista workaround. The code should be added to the if (runpath) code starting at line 494 in spawn.cc. If you have an idea how to do this test as fast as possible, please send a patch. Oh, btw., only three patterns. At this point in the code the slashes are already converted to backslashes. 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: 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 be empty by default as well. The supported codesets are documented in http://cygwin.com/cygwin-ug-net/setup-locale.html#setup-locale-charsetlist If some weird alias is required, the user can add it to charset.alias. That's the optimal solution. FWIW, using a fresh git clone of libiconv 3cdff14a3cc549dc4ccfe02dca46e73b1e7a68c6 Sat Jan 29 18:34:14 2011 +0100) bootstrapped using a fresh gnulib a036b7684f9671ee53999773785d1865603c3849 Tue Feb 1 10:04:17 2011 -0800 and no other patches, libiconv + cygwin-1.7.7 [note: NOT 1.7.8pre] works, passes its own self-tests, and passes Corinna's original test case that spawned this thread. Bruno's change in libiconv was: - This is also the case on native Woe32 systems. */ -#if __STDC_ISO_10646__ || ((defined _WIN32 || defined __WIN32__) !defined __CYGWIN__) + This is also the case on native Woe32 systems and Cygwin = 1.7, where + we know that it is UTF-16. */ +#if ((defined _WIN32 || defined __WIN32__) !defined __CYGWIN__) || (defined __CYGWIN__ CYGWIN_VERSION_DLL_MAJOR = 1007) ...some code... +#elif __STDC_ISO_10646__ ...other code... #endif repeated at various places. Obviously the use of CYGWIN_VERSION_DLL_MAJOR means there is a +#ifdef __CYGWIN__ +#include cygwin/version.h +#endif in there, too. Now, this configuration does NOT include: 1) Corinna's suggested change to localcharset.c that modified get_charset_alias() to use charset.alias on cygwin instead of hardcoding the alias list, NOR the change in that file to locale_charset() to deal with copying the value returned by nl_langinfo() and remove some special cygwin workarounds involving GetACP(). 2) the relocation changes to avoid deprecated path conversion functions and to do things on cygwin the linux way. http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00522.html I tested both with and without --enable-relocatable... But such a user will then write a mail to a mailing list, and it will take time for me (or someone else) to investigate and answer it. By writing #if (defined _WIN32 || defined __WIN32__) !defined __CYGWIN__ I avoid this potential problem. Ok. However, the other variation #if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__ should be only used in very rare circumstances. Usually it just means that some unnecessary Windowism is used on Cygwin, and that there's probably a POSIXy equivalent. If not, kick us here on the list and we can discuss it. See above, with the #if ((defined _WIN32 || defined __WIN32__) !defined __CYGWIN__) || (defined __CYGWIN__ CYGWIN_VERSION_DLL_MAJOR = 1007) formulation. It's not an erroneous use of a windowism, it just reflects that cygwin's unicode impl shares characteristics with the underlying win32 unicode support. -- Chuck -- 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: 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 redirection to 'mbrtowc', 'iswalpha', 'wcwidth' on most platforms, and a use of libunistring modules on Windows platforms. ... 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 that it is always a 4-byte type (needing lots more memory manipulation on cygwin to convert between 2- and 4-byte representations when using cygwin's functions, or else reimplementing everything from scratch by completely bypassing cygwin)? I'm not sure I understand your question. The plan is that - On platforms with a 32-bit wchar_t, like glibc, *BSD, and many others, 'wwchar_t' is identical to 'wchar_t', and the function wrappers are simple redirections. - On Cygwin and mingw, wwchar_t is 'uint32_t' (so as to accommodate all Unicode characters and WEOF and so that it plays well with 'wint_t'). mbrtowwc is implemented by 1 or 2 calls to mbrtowc. mbsrtowwcs may be implemented by a call to mbsrtowcs and an additional conversion loop, or it might be implemented on top of mbrtowwc; that's merely a speed vs. memory trade-off. The plan is not to completely bypassing cygwin, but to use as much of Cygwin's built-ins as makes sense. - On platforms with a 16-bit wchar_t but where the wchar_t[] encoding in Unicode locales is merely UCS-2, like AIX, use the no-op thin wrappers as well. If the platform does not support more than the BMP, it makes not much sense for GNU programs to try to work around that. As to the name: I agree the opinion of others that xchar_t is easier to type and easier to avoid typos of a missing 'w' than wwchar_t. If a developer makes a typo here, he's likely to get a gcc warning or a link error. But yes, it's possible to pass a 'wwchar_t' to iswalpha(), which will yield wrong results. I don't think this risk can be much reduced through a different name. gnulib already has xprintf as a counterpart to xmalloc (which calls exit() if the printf fails for memory allocation or other non-I/O related reasons), so we can't blindly use 'x' Good point. The 'x' prefix has already several meanings in gnulib: - checking against memory allocation failure, - checking against errors, - no size limitation, - a more convenient interface, - a wrapper that prints an error message. It doesn't seem wise to add another meaning to it. Thanks for the feedback. -- In memoriam Carl Friedrich Goerdeler http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler -- 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: 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 that it is always a 4-byte type (needing lots more memory manipulation on cygwin to convert between 2- and 4-byte representations when using cygwin's functions, or else reimplementing everything from scratch by completely bypassing cygwin)? I'm not sure I understand your question. The plan is that - On platforms with a 32-bit wchar_t, like glibc, *BSD, and many others, 'wwchar_t' is identical to 'wchar_t', and the function wrappers are simple redirections. - On Cygwin and mingw, wwchar_t is 'uint32_t' (so as to accommodate all Unicode characters and WEOF and so that it plays well with 'wint_t'). mbrtowwc is implemented by 1 or 2 calls to mbrtowc. mbsrtowwcs may be implemented by a call to mbsrtowcs and an additional conversion loop, or it might be implemented on top of mbrtowwc; that's merely a speed vs. memory trade-off. The plan is not to completely bypassing cygwin, but to use as much of Cygwin's built-ins as makes sense. You answered my question in spite of myself. 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 it always be 4-bytes, where conversion from wchar_t to wwchar_t requires some efforts, and where the new type must be used everywhere (which means wrapping a lot of APIs), but where you can once again assume POSIX semantics of 1 character per unit, simplifying life of callers at the expense of converting to the new type And on asking the question in those more detailed words, I agree with your conclusion - on cygwin, wwchar_t should be 4 bytes. - On platforms with a 16-bit wchar_t but where the wchar_t[] encoding in Unicode locales is merely UCS-2, like AIX, use the no-op thin wrappers as well. If the platform does not support more than the BMP, it makes not much sense for GNU programs to try to work around that. Agreed. Next question/thought. Gnulib should definitely tackle this first. But if it works out, should we also add wwchar_t natively into cygwin? It would certainly be easier to add new interfaces incrementally, in preparation for a possible future ABI conversion to make wchar_t become 4 bytes. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
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 Windows itself add paths to the environment using quotes and trailing backslashes. I applied a patch which removes those, but only when Cygwin actually fetches the Win32 environment and initially converts the path lists like %Path%. This is not done when calling the cygwin_conv_path_list function from the application. I'll try whenever possible (1 ou 2 days), thanks. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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: 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 it always be 4-bytes, where conversion from wchar_t to wwchar_t requires some efforts, and where the new type must be used everywhere (which means wrapping a lot of APIs), but where you can once again assume POSIX semantics of 1 character per unit, simplifying life of callers at the expense of converting to the new type In the first case we wouldn't need a new type. The plan is the second alternative. The goal is *not* to have to extend each of quotearg.c, regcomp.c, mbchar.h, wc.c, etc. to handle UTF-16 explicitly with #ifdefs, more variables, and more logic. if it works out, should we also add wwchar_t natively into cygwin? More and more Unix platforms offer only UTF-8 locales. One can predict that in 10 years, all Unix platforms will offer only UTF-8 locales. At this point wchar_t will be UCS-4 on all these platforms (except AIX). The mbrtoc32 function from the C1X API that you pointed to will then be equivalent to mbrtowwc. So, you can view 'wwchar_t' as a temporary measure that will bridge the gap between the ANSI C Amd. 1 API and the C1X API. Bruno -- In memoriam Carl Friedrich Goerdeler http://en.wikipedia.org/wiki/Carl_Friedrich_Goerdeler -- 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
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 check on the mailing list archive and could not locate similar reports but I have to admit that I did not look very deep as the keyword file got tons of irrelevant hits. So I apologize if this has already been reported. The CYGWIN v1.7.7 distribution includes the command file (not part of the default core installation, you have to select it separately) and the version of file in this distribution is 5.04. The binary installation completed without any issue but when I tried to recreate the magic file magic.mgc (I need to add custom strings to it) using command file -C, file came back with an error that it could not find any magic file. I rolled back one version to 5.00 and got the same error. I have three other machines running older distributions of CYGWIN (2004/2005) which have file versions 4.16 and 4.20, both contained the file /usr/share/file/magic in the binary distribution. I copied the magic file from version 4.16 to the 5.04 installation and still got the same error. I even downloaded the source to rebuild the binaries hoping it will regenerate the magic file but it didn't. I finally discovered the root cause after taking a closer look at the source documentation. Apparently, somewhere between version 4.xx and 5.xx, the magic file which used to be /usr/share/file/magic (all my Unix life I knew magic as an ASCII text file), has now become a directory /usr/share/misc/magic/ with many small files for ease of maintenance. It also happens that this directory magic is NOT part of the binary distribution (you only get /usr/bin/file.exe, man page and /usr/share/misc/magic.mgc). After I copied the entire magic directory from the source distribution to /use/share/misc, file -C works fine and recreated magic.mgc no problem. It would be nice if future binaries distribution of CYGWIN will include the directory /usr/share/misc/magic and all the files within it. Andy -- 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: 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 be a good netizen by reporting bugs that I encounter. Thanks, Ralf -- 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
