Re: [ANNOUNCEMENT] cygwin 3.1.0-0.5 (TEST)
Hi Ken, On Sat, 21 Sep 2019 21:58:07 + Ken Brown wrote: > On 9/20/2019 6:05 PM, Ken Brown wrote:> I'll make a new test release this > weekend, or whenever you think it's time. > > I'm building a new test release right now. I'll upload it in about 24 hours > unless you tell me that you'd like me to wait for further patches. I currently do not have any patch planning. Please go ahead. -- Takashi Yano
Re: Cygwin 3.0.7 on Windows 10: ANSI Escape Sequences not affecting color when run in Windows Terminal
On 9/21/2019 12:06 PM, connor horman wrote: > When using windows terminal, programs using the C Functions provided > by cygwin1.dll to print to stdout (such as printf, puts), do not > render the text color as would be appropriate when using an ANSI > Escape sequence, such as "\033[38;2;255;0;0m". The functionality has > been confirmed on native linux with glibc, as well as when displaying > to mintty.exe. Additionally, the issue does not occur with native > windows executables performing the same task, linked with msvcrt as > the C library implementation, both run through windows command line > programs such as cmd.exe and powershell, and cygwin bash. The issue > seems to be a disparity between the handling of these escape sequences > in cygwin1.dll and in Windows Terminal as is noted in the issue filed > at https://github.com/microsoft/terminal/issues/2837. By "using windows terminal", do you mean the terminal you get by running Cygwin.bat? If so, the issue has been fixed for the upcoming release of cygwin-3.1.0. You can test it by using Cygwin's setup to install the test release cygwin-3.1.0-0.5. Ken -- 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: [ANNOUNCEMENT] cygwin 3.1.0-0.5 (TEST)
Hi Takashi, On 9/20/2019 6:05 PM, Ken Brown wrote:> I'll make a new test release this weekend, or whenever you think it's time. I'm building a new test release right now. I'll upload it in about 24 hours unless you tell me that you'd like me to wait for further patches. Ken
Re: Solved. Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On 9/6/2019 5:53 PM, Houder wrote:
> However an exception can be made for e:/ (or e:\), as follows:
>
> --
>char flag = '\0';
>// strip trailing dirsep's, while remembering the last one
>if (isdirsep (dir[strlen (dir) - 1]))
> {
>flag = dir[strlen (dir) - 1];
>/* This converts // to /, but since both give EEXIST, we're okay.
> */
>char *buf;
>char *p = stpcpy (buf = tp.c_get (), dir) - 1;
>dir = buf;
>while (p > dir && isdirsep (*p))
> {
> flag = *p;
> *p-- = '\0';
> }
> }
>
>// reattach dirsep in case of x: and flag != '\0'
>if ( (strlen (dir) == 2)
> && (dir[1] == ':')
> && isalpha (dir[0]) && flag != '\0' )
> {
>char *buf = tp.c_get ();
>buf[0] = dir[0];
>buf[1] = ':';
>buf[2] = flag;
>buf[3] = '\0';
>dir = buf;
> }
I think you can simplify this by eliminating the second part and changing the
first part to the following:
char sep = dir[strlen (dir) - 1];
if (isdirsep (sep)
{
/* This converts // to /, but since both give EEXIST, we're okay.
*/
char *buf;
char *p = stpcpy (buf = tp.c_get (), dir) - 1;
dir = buf;
while (p > dir && isdirsep (*p))
*p-- = '\0';
/* Reattach dirsep in case of "x:". */
if (p == dir + 1 && *p == ':' && isalpha (dir[0]))
p[1] = sep;
}
Ken
--
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 3.0.7 on Windows 10: ANSI Escape Sequences not affecting color when run in Windows Terminal
On 9/21/2019 12:06 PM, connor horman wrote: When using windows terminal, programs using the C Functions provided by cygwin1.dll to print to stdout (such as printf, puts), do not render the text color as would be appropriate when using an ANSI Escape sequence, such as "\033[38;2;255;0;0m". The functionality has been confirmed on native linux with glibc, as well as when displaying to mintty.exe. Additionally, the issue does not occur with native windows executables performing the same task, linked with msvcrt as the C library implementation, both run through windows command line programs such as cmd.exe and powershell, and cygwin bash. The issue seems to be a disparity between the handling of these escape sequences in cygwin1.dll and in Windows Terminal as is noted in the issue filed at https://github.com/microsoft/terminal/issues/2837. Others are certainly more knowledgeable on this than I am, but since colors and such work fine through cygwin on an xterm, I think it has to do with the terminal, not that cygwin per se (i.e., not the dll). Regards - Eliot Moss -- 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: [PATCH] Cygwin: remove old cruft from path_conv::check
On 9/21/2019 1:34 PM, Ken Brown wrote:
> Prior to commit b0717aae, path_conv::check had the following code:
>
>if (strncmp (path, ".\\", 4))
> {
>/* Windows ignores trailing dots and spaces in the last path
> component, and ignores exactly one trailing dot in inner
> path components. */
>char *tail = NULL;
>[...]
>if (!tail || tail == path)
> /* nothing */;
>else if (tail[-1] != '\\')
> {
>*tail = '\0';
>[...]
> }
>
> Commit b0717aae0 intended to disable this code, but it inadvertently
> disabled only part of it. In particular, the declaration of the local
> tail variable was in the disabled code, but the following remained:
>
>if (!tail || tail == path)
> /* nothing */;
>else if (tail[-1] != '\\')
> {
>*tail = '\0';
>[...]
> }
>
> [A later commit removed the disabled code.]
>
> The tail variable here points into a string different from path,
> causing that string to be truncated under some circumstances. See
>
>https://cygwin.com/ml/cygwin/2019-09/msg1.html
>
> for more details.
>
> This commit fixes the problem by removing the leftover code
> that was intended to be removed in b0717aae.
> ---
> winsup/cygwin/path.cc | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> index c13701aa0..2fbacd881 100644
> --- a/winsup/cygwin/path.cc
> +++ b/winsup/cygwin/path.cc
> @@ -1168,19 +1168,6 @@ path_conv::check (const char *src, unsigned opt,
>
> if (dev.isfs ())
> {
> - if (strncmp (path, ".\\", 4))
> - {
> - if (!tail || tail == path)
> - /* nothing */;
> - else if (tail[-1] != '\\')
> - *tail = '\0';
> - else
> - {
> - error = ENOENT;
> - return;
> - }
> - }
> -
> /* If FS hasn't been checked already in symlink_info::check,
>do so now. */
> if (fs.inited ()|| fs.update (get_nt_native_path (), NULL))
This seems pretty straightforward to me, but I'll wait a few days before
committing it in case I'm missing something.
Ken
[PATCH] Cygwin: remove old cruft from path_conv::check
Prior to commit b0717aae, path_conv::check had the following code:
if (strncmp (path, ".\\", 4))
{
/* Windows ignores trailing dots and spaces in the last path
component, and ignores exactly one trailing dot in inner
path components. */
char *tail = NULL;
[...]
if (!tail || tail == path)
/* nothing */;
else if (tail[-1] != '\\')
{
*tail = '\0';
[...]
}
Commit b0717aae0 intended to disable this code, but it inadvertently
disabled only part of it. In particular, the declaration of the local
tail variable was in the disabled code, but the following remained:
if (!tail || tail == path)
/* nothing */;
else if (tail[-1] != '\\')
{
*tail = '\0';
[...]
}
[A later commit removed the disabled code.]
The tail variable here points into a string different from path,
causing that string to be truncated under some circumstances. See
https://cygwin.com/ml/cygwin/2019-09/msg1.html
for more details.
This commit fixes the problem by removing the leftover code
that was intended to be removed in b0717aae.
---
winsup/cygwin/path.cc | 13 -
1 file changed, 13 deletions(-)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index c13701aa0..2fbacd881 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1168,19 +1168,6 @@ path_conv::check (const char *src, unsigned opt,
if (dev.isfs ())
{
- if (strncmp (path, ".\\", 4))
- {
- if (!tail || tail == path)
- /* nothing */;
- else if (tail[-1] != '\\')
- *tail = '\0';
- else
- {
- error = ENOENT;
- return;
- }
- }
-
/* If FS hasn't been checked already in symlink_info::check,
do so now. */
if (fs.inited ()|| fs.update (get_nt_native_path (), NULL))
--
2.21.0
Cygwin 3.0.7 on Windows 10: ANSI Escape Sequences not affecting color when run in Windows Terminal
When using windows terminal, programs using the C Functions provided by cygwin1.dll to print to stdout (such as printf, puts), do not render the text color as would be appropriate when using an ANSI Escape sequence, such as "\033[38;2;255;0;0m". The functionality has been confirmed on native linux with glibc, as well as when displaying to mintty.exe. Additionally, the issue does not occur with native windows executables performing the same task, linked with msvcrt as the C library implementation, both run through windows command line programs such as cmd.exe and powershell, and cygwin bash. The issue seems to be a disparity between the handling of these escape sequences in cygwin1.dll and in Windows Terminal as is noted in the issue filed at https://github.com/microsoft/terminal/issues/2837. -- 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: Odd, is it not? mkdir 'e:\' cannot be undone by rmdir 'e:\' ...
On 9/20/2019 5:11 AM, Houder wrote:
> As I said already, the snippet should NOT be executed in general. Perhaps
> it is another left-over from old times that should have been deleted.
You're absolutely right. Prior to commit b0717aae0, the code looked like this:
if (strncmp (path, ".\\", 4))
{
/* Windows ignores trailing dots and spaces in the last path
component, and ignores exactly one trailing dot in inner
path components. */
char *tail = NULL;
[...]
if (!tail || tail == path)
/* nothing */;
else if (tail[-1] != '\\')
{
*tail = '\0';
strip_tail = true;
}
else
{
error = ENOENT;
return;
}
}
Note the use of a *local* tail variable. It's a pointer into path, as you can
see by looking at the part I omitted.
In commit b0717aae0, Corinna intended to disable this code, but she
inadvertently disabled only part of it. Here's the relevant part of that
commit:
@@ -1170,6 +1225,7 @@ out:
{
if (strncmp (path, ".\\", 4))
{
+#if 0
/* Windows ignores trailing dots and spaces in the last path
component, and ignores exactly one trailing dot in inner
path components. */
@@ -1190,7 +1246,7 @@ out:
tail = NULL;
}
}
-
+#endif
if (!tail || tail == path)
/* nothing */;
else if (tail[-1] != '\\')
In particular, the declaration of the local tail variable is in the disabled
code, so the cruft at the end is referring to the other tail, which points into
path_copy.
[A later commit removed the disabled code.]
I'll fix this and then look at your patches to mkdir and rmdir. It would be
very helpful if you would write these as a patch series with cover letter,
using
git format-patch, and send them to the cygwin-patches list.
Ken
--
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: Snapshot of cygwin applications installed in a PC
Am 20.09.2019 um 22:55 schrieb Andrey Repin: Greetings, Jose Isaias Cabrera! I am about to change PC from Windows 7 to Windows 10. Is there a way for me to take a snapshot of all the applications that I installed in Window 7, so when I run the installer for Windows 10, I can just point to that file and the installer will install the same applications that I had on the other PC? thanks for your help. /etc/installed.db If you put some effort into researching your question, you could even find a script to deal with it. one example is here https://stackoverflow.com/questions/46829532/cygwin-save-package-selections-for-later-reinstall/ -- 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
