From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74300 invoked by alias); 12 Oct 2016 12:00:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 73453 invoked by uid 89); 12 Oct 2016 12:00:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=World, hierarchy, H*f:sk:14aba7e, esc X-HELO: mail-lf0-f41.google.com Received: from mail-lf0-f41.google.com (HELO mail-lf0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 12:00:02 +0000 Received: by mail-lf0-f41.google.com with SMTP id x79so74199782lff.0 for ; Wed, 12 Oct 2016 05:00:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:to:references:from:organization :cc:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1+I+oT3a89xGpJKYcvUeJ5svC0ospF/2xBnuo8Nc2Tc=; b=YoYEjrgk8n9QboqWv6xcBye4hCO2OZ6RxxdLm7Li5Qb+S4zv1bzt/xKxS3s/QbgBK8 B09yjMi0g0TCKbUQxH9HQByS5kx3NSNj886rKCGZSoqx/8/t9YdyjCKvFMbEThPhwCPn j+5eup0jKUrTuUjEPE9auxHwCStKiqf1QzGmrgKORRbK/D70m5QPaNsJgRc+b/TYCBtd IFfp6EZRaaNk6KiZ7IeVWz1BYZHcM5S5Bl3RUukoTp99ZLQmTOtKZ+oZgL4wDPriibpW 1yadss9tStaMt7rPaJkc3D9Q9JR91GQH2PQH4fC3Hk20H2xohTO25jCUszH4nL69xDt6 eawg== X-Gm-Message-State: AA6/9Rnr/sKQBR3uBij5C1BIKa0BpQkQJrtDtVUEkVZ3a03XHdkDS1jDKUAmxgenwYKyXQ== X-Received: by 10.25.75.216 with SMTP id y207mr804284lfa.100.1476273600198; Wed, 12 Oct 2016 05:00:00 -0700 (PDT) Received: from [172.23.202.33] (109-73-33-210.in-addr.mastertelecom.ru. [109.73.33.210]) by smtp.gmail.com with ESMTPSA id s83sm2072149lja.35.2016.10.12.04.59.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Oct 2016 04:59:59 -0700 (PDT) Reply-To: andrewbass@gmail.com Subject: Re: Escape sequences unprocessed under the "cygwin" terminal To: cygwin@cygwin.com References: <57FDF60B.4000206@gmail.com> <14aba7e2-a859-5476-f460-5721e3b9e61d@gmail.com> From: Andrey ``Bass'' Shcheglov Cc: Marco Atzeri Message-ID: <57FE25BE.80207@gmail.com> Date: Wed, 12 Oct 2016 18:41:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <14aba7e2-a859-5476-f460-5721e3b9e61d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00166.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marco, Thank you for your response. On 12.10.2016 13:32, Marco Atzeri wrote: > On 12/10/2016 10:36, Andrey ``Bass'' Shcheglov wrote: >> >> It works fine under regular Unices, and also under xterm and mintty >> (in Cygwin), but I'm having trouble running it under the "cygwin" >> terminal (i. e. bash launched from cmd.exe). > > cmd is not a Cygwin terminal, it is a limited Windows one. > What is the problem to use mintty ? There's no problem. I'm just trying to understand the limitations of cmd.exe (TERM=cygwin). FWIK, bash.exe *can* properly translate ANSI escape sequences into WinAPI calls. Strangely, the same C program: > #include > > int main() { > const char esc = 0x1b; > printf("%c[31;91;1mHello, World!%c[0m\n", esc, esc); > return 0; > } behaves correctly with TERM=cygwin when compiled with Cygwin GCC and linked against cygwin1.dll: > $ ldd test-ansi-escape.exe > ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffeeb450000) > KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL (0x7ffee92c 0000) > KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7ffe e8700000) > cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000) and displays garbage like > ←[31;91;1mHello, World!←[0m when compiled with MSVC as a native Windows application: > $ ldd test-ansi-escape.exe > ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7ffeeb450000) > ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x770a0000) > wow64.dll => /cygdrive/c/Windows/SYSTEM32/wow64.dll (0x76fd0000) > wow64win.dll => /cygdrive/c/Windows/system32/wow64win.dll (0x77020000 ) > wow64cpu.dll => /cygdrive/c/Windows/system32/wow64cpu.dll (0x77090000 ) > ??? => ??? (0x1040000) > KERNEL32.DLL => /cygdrive/c/Windows/SYSTEM32/KERNEL32.DLL (0x76480000 ) > ??? => ??? (0x1040000) > ??? => ??? (0x1040000) > KERNEL32.DLL => /cygdrive/c/Windows/SYSTEM32/KERNEL32.DLL (0x76480000 ) > KERNELBASE.dll => /cygdrive/c/Windows/SYSTEM32/KERNELBASE.dll (0x74b4 0000) > MSVCR120D.dll => /cygdrive/c/Windows/SYSTEM32/MSVCR120D.dll (0x62b900 00) >> Also, if I log in to my Windows box using SSH (i. e. replace the loca l >> connection with the remote one, but retain the same |"cygwin|" >> terminal), again, escape sequences are processed just fine. > > from Unix ? The terminal on that side is able to properly manage > escape sequence No, from Windows. I mean, I'm doing "ssh.exe localhost" (the process hierarchy being cmd.exe -> bash.exe -> ssh.exe -> bash.exe) -- and everything is working again! > use mintty. > It is the recommended one for cygwin I understand mintty is superior feature-wise compared to cmd.exe, and xterm is superior to both mintty and cmd.exe -- just like I said, I'm trying to understand the limitations of cmd.exe (TERM=cygwin). Regards, Andrey. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlf+Jb4ACgkQFX2weoTrDGcDjQCeLfk7Nxeg/SGHZEEa2sPuhWli MrsAn3rGf/9tcTPD1iAFjFMJYHGjR2fC =cCH2 -----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