Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD cygwin cat.exe renders tab filename completion useless?

Jul
184
5
Not sure where the bug lies at all, but if I use cat.exe from cygwin to cat a binary file (usually an oops, but sometimes legitimate), tab-completion often no longer works in that instance. Ever again.

It just outputs actual tabs into the command line, instead of completing to a filename.

I have to restart a new instance of TCC to get that functionality back.

Now this isn't the case with the internal type command, so it's definitely something cygwin/GNU's cat.exe is doing, but I still think tCC shouldn't consent to this evil manipulation.

cygwin/GNU's cat.exe is acting like an actual house cat and messing up things it shouldn't! lol

1688920328961.png
 
I know what's happening but I'm not sure why it happens. The flag ENABLE_VIRTUAL_TERMINAL_INPUT is being added to the console's (or pseudoconsole's) input mode. That is not appropriate for an interactive TCC. This should fix it.

Code:
echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],487]

I'd bet that no collection of characters sent to stdout could cause the console input mode to change. So I suspect the culprit is Cygwin's CAT.EXE itself. My Cygwin CAT.EXE is (GNU coreutils) 9.0. My other CAT.EXE is (GNU coreutils) 5.3.0, straight from Gnu, and it doesn't exhibit this behavior.
 
I know what's happening but I'm not sure why it happens. The flag ENABLE_VIRTUAL_TERMINAL_INPUT is being added to the console's (or pseudoconsole's) input mode. That is not appropriate for an interactive TCC. This should fix it.

Code:
echo %@winapi[kernel32.dll,SetConsoleMode,%@fileopen[con:,r],487]

I'd bet that no collection of characters sent to stdout could cause the console input mode to change. So I suspect the culprit is Cygwin's CAT.EXE itself. My Cygwin CAT.EXE is (GNU coreutils) 9.0. My other CAT.EXE is (GNU coreutils) 5.3.0, straight from Gnu, and it doesn't exhibit this behavior.

I wonder how we can get them to fix this. Are they on github?

Anyway! Thanks for the fix. Wow that you knew exactly what this was an exactly how to fix it.

My "cat" is an alias that calls a bat file wrapper anyway, so it's easy for me to insert this fix after every call to cat. And I tested it, and it works, and I'll never experience that problem again.

THANK YOU!!
 
This might be mildly interesting. Dustin's thought seems right-on. Cygwin should leave the console the way it found it!

Cygwin is pretty popular. They must have some sort of a user forum.
 
Wow that you knew exactly what this was an exactly how to fix it.

It was no small chore. I put some investigative kludges in a TCC plugin and consulted a few MS docs. In the end I wrote this. I reckon I'll find another use for it someday.

Code:
v:\> conmode /?

Usage: CONMODE [/I(nput)|/O(utput)]; default both

v:\> conmode

Console input mode flags (0x1E7)

    ENABLE_PROCESSED_INPUT (0x1)
    ENABLE_LINE_INPUT (0x2)
    ENABLE_ECHO_INPUT (0x4)
    ENABLE_INSERT_MODE (0x20)
    ENABLE_QUICK_EDIT_MODE (0x40)
    ENABLE_EXTENDED_FLAGS (0x80)
    ENABLE_AUTO_POSITION (0x100)

Console output mode flags (0x7)

    ENABLE_PROCESSED_OUTPUT (0x1)
    ENABLE_WRAP_AT_EOL_OUTPUT (0x2)
    ENABLE_VIRTUAL_TERMINAL_PROCESSING (0x4)

If you want it, get it like this: copy ftp://vefatica.net/conmode.zip
 
Damn. I'm jealous of those skills.

I grabbed your .EXE! One never knows when it might be useful!

I mean, i just converted some .com executables to .exe recently so I could use them again. They were from the early/mid 1990s.
 
So i looked into it, and Cygwin wants their bug reports to be reported exclusively in the format of.....................<drumroll>..................an email to a listserv/mailing list. omg.
 
So i looked into it, and Cygwin wants their bug reports to be reported exclusively in the format of.....................<drumroll>..................an email to a listserv/mailing list. omg.
They just might think the shell should be ensuring its own sanity by resetting crucial things after running an external program. Agree or not, it's a valid point of view. And I'll bet TCC does that to some extent. I'll make a suggestion that is also reset STD_INPUT_HANDLE.
 
They just might think the shell should be ensuring its own sanity by resetting crucial things after running an external program. Agree or not, it's a valid point of view. And I'll bet TCC does that to some extent. I'll make a suggestion that is also reset STD_INPUT_HANDLE.

They also think TCC should be handling a bug I found with double-height text not word-wrapping properly.

I think it's an...interesting...position for the wrapper to declare that every single CLI that uses it fix something, rather than the wrapper fixing it there for everybody at once.

But of course, they also want TCC to clear the screen differently :D
 

Similar threads

Back
Top