BLODA extension: console interoperability

BLODA extension: console interoperability

[Warren Young]

I don't see any console programs on the BLODA.  Shouldn't it include 
programs that break under Cygwin due to things like the change from 
Windows console to mintty, or the pty (?) work that improves Linux/POSIX 
semantics?

Then there are the even older class of programs that didn't work right 
even in the cygwin.bat days.  I seem to recall that programs in this 
class failed because they knew too much about how the Windows console 
worked, and Cygwin couldn't intercept certain direct console accesses 
for some reason.

I ask only because I don't run into this sort of thing very often, so I 
didn't have any examples at hand when the issue came up in a question 
raised in another forum.  Ideally, I'd have been able to reference a 
program that comes with Windows.

The only program I currently use that I know has such problems is rather 
obscure, so it wasn't a suitable example.  I don't even know that it's 
popular enough to be listed in this proposed BLODA extension.  (It's 
fsharpi.exe from the F# command line toolchain. http://goo.gl/1GOK86 
I'm not even entirely sure what the problem was, since I switched to a 
Windows console for it over a month ago.  Something about it being 
un-Ctrl-C-able when it is in certain states.)

--
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: BLODA extension: console interoperability

[Larry Hall (Cygwin)]

On 7/25/2013 6:36 PM, Warren Young wrote:
> I don't see any console programs on the BLODA.  Shouldn't it include
> programs that break under Cygwin due to things like the change from Windows
> console to mintty, or the pty (?) work that improves Linux/POSIX semantics?

Generally speaking, BLODA is a term used here to apply to apps that, when
run, interfere with the proper operation of Cygwin apps (things like virus
scanners are the typical problem area, as you know).  To me, what you're
asking about is the opposite of that - non-Cygwin programs that have
problems when run from Cygwin terminals or shells.  I suppose we could
expand the notion of BLODA to cover these programs as well, though I might
personally prefer to describe and list them differently.  Obviously, no
matter what, a list of programs like the ones you're describing wouldn't be
exhaustive, just like the BLODA list isn't today.  I know that's not news.
I'm just pointing out the obvious. ;-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: BLODA extension: console interoperability

[Warren Young]

On 7/25/2013 17:06, Larry Hall (Cygwin) wrote:
> I might personally prefer to describe and list them differently.

DONOPWOL:

DOes
NOt
Play
Well with
Others
List

--
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: BLODA extension: console interoperability

[Larry Hall (Cygwin)]

On 7/26/2013 12:14 AM, Warren Young wrote:
> On 7/25/2013 17:06, Larry Hall (Cygwin) wrote:
>> I might personally prefer to describe and list them differently.
>
> DONOPWOL:
>
> DOes
> NOt
> Play
> Well with
> Others
> List

Now doesn't that just roll off the tongue? ;-)

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: BLODA extension: console interoperability

[Andy Koppe]

On 26 July 2013 05:14, Warren Young wrote:
> On 7/25/2013 17:06, Larry Hall (Cygwin) wrote:
>>
>> I might personally prefer to describe and list them differently.
>
>
> DONOPWOL:
>
> DOes
> NOt
> Play
> Well with
> Others
> List

I don't think that's fair, since such apps were designed for the
Windows console, without being aware of Cygwin's pipe-based ptys. And
unfortunately that list would be very long anyway: basically anything
interactive that hasn't been explicitly adapted to Cygwin ptys, for
example by disabling buffering and not relying on the console's
history facility.

Speaking of which: somebody on the mintty mailing list would like to
make a Windows program Cygwin-aware by detecting whether it's running
in a Cygwin terminal (as opposed to having its input or output
redirected to plain pipes). Does anyone know a way to do this?

https://groups.google.com/forum/#!topic/mintty-discuss/NKXaYjF8jqk

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: BLODA extension: console interoperability

[Warren Young]

On 7/25/2013 22:44, Andy Koppe wrote:
> unfortunately that list would be very long anyway: basically anything
> interactive that hasn't been explicitly adapted to Cygwin ptys,

Well, that gives me my example, anyway: c:\windows\system32\ftp.exe.

--
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: BLODA extension: console interoperability

[Christopher Faylor]

On Fri, Jul 26, 2013 at 05:44:02AM +0100, Andy Koppe wrote:
>On 26 July 2013 05:14, Warren Young wrote:
>> On 7/25/2013 17:06, Larry Hall (Cygwin) wrote:
>>>
>>> I might personally prefer to describe and list them differently.
>>
>>
>> DONOPWOL:
>>
>> DOes
>> NOt
>> Play
>> Well with
>> Others
>> List
>
>I don't think that's fair, since such apps were designed for the
>Windows console, without being aware of Cygwin's pipe-based ptys. And
>unfortunately that list would be very long anyway: basically anything
>interactive that hasn't been explicitly adapted to Cygwin ptys, for
>example by disabling buffering and not relying on the console's
>history facility.
>
>Speaking of which: somebody on the mintty mailing list would like to
>make a Windows program Cygwin-aware by detecting whether it's running
>in a Cygwin terminal (as opposed to having its input or output
>redirected to plain pipes). Does anyone know a way to do this?

Why not just always flush stdout if it's opened on a pipe?

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: BLODA extension: console interoperability

[Pavel Fedin]

 Hello!

> I don't think that's fair, since such apps were designed for the
> Windows console, without being aware of Cygwin's pipe-based ptys. And
> unfortunately that list would be very long anyway: basically anything
> interactive that hasn't been explicitly adapted to Cygwin ptys

 Let me also drop my 5 cents into this...
 We should be very careful about this. At least there is one case where difference between Cygwin console and real Windows console plays a key role: ncurses. Normal Windows console is very basic and does not understand 90% of control sequences. As a result, ncurses has been extended with 'terminal drivers', which redirect certain control functions to OS (Windows in our case) API calls. Which, of course, work only with real Windows console.
 So, it's crucial to be able to detect whether we are running on Windows console or not. Here i have patched version of ncurses which uses GetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), &mode) operation in order to detect this. This function returns error on non-console handles. This makes ncurses working from within MSYS console. Previously an attempt to run ncurses app simply trashed my console window with ESC sequences. Original ncurses relies on $TERM variable being empty, which works well with 'naked' cmd.exe,  but fails miserably with MSYS environment because MSYS sets $TERM to 'cygwin', while still operating inside Windows console which does not really understand most of ESC sequences.
 With this fix applications can correctly determine whether they are running in Cygwin's shell and even over ssh connection, and correctly render in all these cases.

 P.S. There is still a problem with input in these applications if run from non-native console, but i think it's another story. I didn't look at it because of lack of time and motivation. The goal was to cross-compile an ncurses app for Windows here at work, and the goal was reached.

 P.P.S. The patch is lying around and waiting to be submitted. I know, not here, but likely to ncurses ML directly. However looks like FSF guys are not very keen on people committing to them, and they perhaps worry about legal-mumbo-jumbo much more than about programming and real openess. My two patches sent to different lists (make and gnulib) were simply ignored.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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: BLODA extension: console interoperability

[Christopher Faylor]

On Fri, Jul 26, 2013 at 04:07:55PM +0400, Pavel Fedin wrote:
> Hello!
>
>> I don't think that's fair, since such apps were designed for the
>> Windows console, without being aware of Cygwin's pipe-based ptys. And
>> unfortunately that list would be very long anyway: basically anything
>> interactive that hasn't been explicitly adapted to Cygwin ptys
>
> Let me also drop my 5 cents into this...
>We should be very careful about this.  At least there is one case where
>difference between Cygwin console and real Windows console plays a key
>role: ncurses.  Normal Windows console is very basic and does not
>understand 90% of control sequences.  As a result, ncurses has been
>extended with 'terminal drivers', which redirect certain control
>functions to OS (Windows in our case) API calls.  Which, of course,
>work only with real Windows console.

The "console" that a Cygwin program sees is not just the raw Windows
console.  Hopefully the Cygwin version of ncurses understands that
Cygwin extends the functionality of the console so that a big subset of
standard control sequences will just work.

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: BLODA extension: console interoperability

[Charles Wilson]

On 7/26/2013 11:29 AM, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 04:07:55PM +0400, Pavel Fedin wrote:
>> Let me also drop my 5 cents into this...
>> We should be very careful about this.  At least there is one case where
>> difference between Cygwin console and real Windows console plays a key
>> role: ncurses.  Normal Windows console is very basic and does not
>> understand 90% of control sequences.  As a result, ncurses has been
>> extended with 'terminal drivers', which redirect certain control
>> functions to OS (Windows in our case) API calls.  Which, of course,
>> work only with real Windows console.
>
> The "console" that a Cygwin program sees is not just the raw Windows
> console.  Hopefully the Cygwin version of ncurses understands that
> Cygwin extends the functionality of the console so that a big subset of
> standard control sequences will just work.

cygwin-ncurses does not do any of the stuff that Pavel described. It 
treats the cygwin terminal just as described by $TERM (which, if 
TERM=cygwin, uses the terminfo definition we've painstakingly created 
over the years) -- and so takes advantage of the "gloss" that cygwin 
places over the plain console.

OTOH, if TERM=xterm, for instance, then it just uses the xterm terminfo.

--
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: BLODA extension: console interoperability

[Pavel Fedin]

 Hello!

> The "console" that a Cygwin program sees is not just the raw Windows
> console.  Hopefully the Cygwin version of ncurses understands that
> Cygwin extends the functionality of the console so that a big subset of
> standard control sequences will just work.

 I know this. But i was talking about running MinGW (i. e. Windows native)
software with MinGW nCurses under such a console.
 I believe, for case Cygwin software cygwin.dll fixes this up and interprets
missing ESC sequences. But if we run MinGW program from within this console,
it won't have this functionality and will talk to the console directly.
 In other case, we might run this program from within MinTTY. As far as i
can understand, MinTTY is a complete terminal emulator which understands all
ESC sequences by itself. In this case MinGW program will need to use ESC
sequences too. But if MinGW program will think that it's running on a real
Windows console, it will try to use Windows API, which obviously will not
work.
 I agree that this is kind of corner case, but it's still there, if we talk
about interoperability.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia



--
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