Win32::Console::ANSI enables by default a ANSI(Win) to OEM(Dos) mapping. When I use Win32::Console::ANSI in a CPAN module should I keep this mapping or should I disable this mapping with \e(U?
The documentation outlines the reason this is the default:
It is useful because one types the script with a Windows-based editor
(using a Windows codepage) and the script prints its messages on the
console using another codepage: without translation, the characters
with a code greatest than 127 are different and the printed messages
may be not readable.
That seems to be a sensible default for an ANSI console emulation, as it aims to avoid unreadable messages. If, when people are using your CPAN module, they can reasonably expect an ANSI console, maybe it's wise to leave the defaults as they are. What you might want to do is allow people to choose the behaviour as an option when they load/configure your module. But in any case, make it really clear in the documentation what you're doing and why.
Related
GitLab and GitHub both support coloring their output with escape sequences.
But GitLab (I didn't test the default TERM value in GitHub) sets TERM=dumb which is a good default, but techincally incorrect, I guess, as it is misleading about the capabilities.
Is there any predefined terminfo entry which describes the GitLab terminal emulation capabilities correctly, or just better than dumb?
If not, is there any way to systematically test the capabilities and write a custom definition?
I understand that a lot of software doesn't use termcaps, and maybe only understands a hardcoded list of xterm, dumb and linux. My goal isn't making it actually working with pre-existing software, there are adhoc options for that often (such as --color=always)
You could define a simple termcap that at least defines the known ANSI color capabilities, but it would probably need to define all other caps as unsupported, at least until more light can be shone on the other underlying capabilities of GitLab runner terminals.
Example of the supported ANSI color sequences in GitLab CI Runner "terminals": https://gitlab.com/dgoo2308/readability_colors/-/blob/master/.gitlab-ci.yml
Hi according to this post, unbuffer connects to a command via a pseudo-terminal (pty), which makes the system treat it as an interactive process, therefore not using any stdout buffering.
I would like to use this function on Windows. May I know what is the equivalent of unbuffer program on Windows? Thanks.
I spent some time on this and succeeded. I found this blog during research, and decided to return and provide my solution to save the next guy some time. I'm responding as a guest with a false email so I won't be interacting, but no further information should be required.
On Jul 18 '12 at 19:41 Harry Johnston wrote:
"In principle, if you know how much data to expect, you could use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you."
Thing is, there is already a utility that does this. It's written for a slightly different use, but it can be coxed into providing the desired result. Its intended purpose is to enable a windows console app to interact with a Linux style tty terminal. It does this by running a hidden console and accesses the console buffer directly. If you tried to use it – you'd fail. I got lucky and discovered that there are undocumented switches for this utility which will allow it to provide simple unbuffered output. Without the switches it fails with the error – the output is not a tty – when trying to pipe output.
The utility is called winpty. You can get it here:
https://github.com/rprichard/winpty/releases
The undocumented switches are mentioned here:
https://github.com/rprichard/winpty/issues/103
I’m using the MSYS2 version. You’ll need the msys-2.0.dll to use it.
Simply run:
winpty.exe -Xallow-non-tty -Xplain your_program.exe | receive_unbuffered_output.exe
-Xallow-non-tty , will allow piped output
-Xplain , will remove the added Linux terminal escape codes (or whatever they’re called)
Required files are:
winpty.exe
winpty-agent.exe
winpty.dll
msys-2.0.dll
winpty-debugserver.exe – Not needed
The behaviour you're describing is typical of applications using run-time libraries for I/O. By default, most runtime libraries check to see whether the handle is a character mode device such as a console, and if so, they don't do any buffering. (Ideally the run-time library would treat a pipe in the same way as a console, but it seems that most don't.)
I'm not aware of any sensible way to trick such an application into thinking it is writing to a console when it is actually writing to a pipe.
Addendum: seven years later, Windows finally supports pseudoconsoles. If you are running on Windows 10 v1809 or later, this new API should solve your problem.
On older versions of Windows, if you know how much data to expect, you could in principle use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you.
Similarly, in principle it should presumably be possible to write a device driver equivalent to a Unix pseudo-terminal, one that acts like a pipe but reports itself to be a character-mode device. But writing device drivers requires specific expertise, and they have to be digitally signed, so unless there is an existing product out there this approach isn't likely to be feasible.
Disclaimer: My answer only deals with executables compiled using MSVC.
The buffering policy is coded inside Microsoft C Runtime (CRT) Library. You can learn the details here. This article suggests using console handles and manipulate console buffers to receive unbuffered output.
However, there's an undocumented feature inside Microsoft C Runtime to inherit file handles with some internal flags directly from its parent process using lpReserved2 and cbReserved2 fields of STARTUPINFO structure. You can find the details in the crt source code provided by Microsoft Visual Studio. Or search for something like posfhnd on GitHub.
We can exploit this undocumented feature to provide a pipe handle and specify FOPEN | FDEV flags to the child process, to fool the child process treat that pipe handle the same way as a FILE_TYPE_CHAR handle.
I have a working Python3 script to demonstrate this method.
In Windows, command line options are preceded by /, sometimes by -. Is there a way to query Windows for this character? In MS-DOS, there was a SWITCHAR setting in config.sys. Is there a similar setting or system resource which can be obtained from Windows? Or should my command-line app simply use / or - without looking anywhere?
I don't think there was ever a way that this was exposed externally. Perhaps some DOS 2.0 commands checked it, but nothing else did.
"SWITCHAR was never really supported, even by DOS commands (let alone third-party programs)." [source]
I assume third-party programs were expected to parse config.sys themselves. I don't think there was any Windows support to get this particular value. (A Larry Osterman blog post talks about the history of SWITCHAR and hints that there might have been OS support for it once upon a time.)
Best practice is to allow either.
I read about standard streams. My understanding is old fashioned programs that don't have GUI need some kind of user interface, too. So Operating System provide each of them with a console window, and the console window's out/input/err stream was mapped to the program's standard input/output/error stream. And thus these programs are called console application. And this mappings couldn't be modified by the programmer.
I am wondering, if my understanding above is correct, does GUI program have these standard streams also? I don't think it's necessary since GUI itself is a good user interface.
I'm quoting the bottom of the article you linked to:
Graphical user interfaces (GUIs)
rarely make use of the standard
streams.
Some GUI programs, primarily on Unix,
still write debug information to
standard error.
Others may take files to operate from
standard in, for example many Unix
media players do so.
Therefore from the above quotes, you can see that yes they do, although they're rarely used.
"And this mappings couldn't be
modified by the programmer."
This is incorrect - certainly on UNIX they can be - not sure about Windows. For example, you can close the standard output stream and redirect it to a file stream to get the output written to a file.
This varies a lot based on your OS. Some will create a console if you run a "command line" app, some will connect the standard streams to the same streams as the process that started the program had.
You typically can change the stdout/in/err streams, it's very common to connect them to something else than the console in which they were run, like a pipe or file.
GUI programs typically have the stdout/err/in streams as well.
GUI programs rarly use those streams, perhaps except for debugging printfs during development.
GUI programs might redirect those streams to /dev/null or something similar that just discards data written to it.
I'm now learning Tcl/Tk, but as I'm running Windows, I want to create a fully featured(professional) development environment for this language, but I need to know:
Which tools I need to install(first of all)?
What are the IDEs that support Tcl/Tk development?
What is the best text editor to develop in?
Where I can find some librarys for it(if exists)?
It's possible to do some web applications with it?
It uses CGI?
Start off by installing ActiveTCL. It is free and includes TCL and TK bindings. If you have a favorite text editor you can use that. Make sure you have syntax highlighting. If you want something more advanced, I'd recommend Komodo. It is by active state and has a free version. It semantically understands TCL, so it is more intelligent than a standard text editor. For example it highlights syntax errors while you code.
Now write some code and spread the TCL love!
For an interactive Tcl shell, use TkCon
For an editor, I use Komodo or Vim
For web apps, there are FrameWorks, servers: TclHTTP, Aol Server, Apache modules, and of course CGI
For a text editor I would recommend trying jEdit; it has TCL syntax highlighting. When installed I would also recommend installing the following plugins (which can be done via the built-in plugin manager):
Project Viewer: Allows you to organise your files into projects, which gives it more of an IDE feel.
Editor Scheme: Gives you a set of pre-defined syntax highlighting colour schemes to choose from. My preference is for "zenburn".
As Byron mentioned, ActiveTCL is the place to start when using TCL on Windows. As for a text editor, I personally like SciTE, but any text editor that will do syntax highlighting will do (code folding helps as well).
The TCL wiki has the following page regarding IDEs: http://wiki.tcl.tk/998
If you are in need of a library providing specific functionality, I would first check the TCl wiki. There is no central repository of TCL extensions, but the wiki seems to be the central repository of TCL knowledge.
Yes, you can use TCL for web-based projects. You can find a bit of info here regarding CGI and TCL. Some webservers (AOLServer for instance) have a built-in TCL interpreter.
Others have already mentioned TkCon but most people don't utilise the full power of TkCon. It is much more than a REPL loop (for that you could have just used tclsh or wish). My favourite feature is TkCon's edit command.
Basically:
edit some_file.txt
lets you view and edit files.
set my_variable "some value"
edit my_variable
lets you view and edit the content of a variable, even arrays
proc my_function {} {}
edit my_function
lets you view and edit the body of a proc. In fact, this is how I usually write non-trivial procs in TkCon.
If you're going to write code that needs Windows-specific functionality, you will definitely want to get TWAPI the Tcl Windows API library.
With regards to the mentions of ActiveTcl - ActiveState (the creators of ActiveTcl) have been developing an extension repository. Certainly there are extensions which do not (yet) appear there, but there are over 3000 entities in their repository at this time, so many extensions are present there. ActiveTcl comes with a program called "teacup" which provides a command line interface to the repository, allowing you to install specific extensions (or, if you are like me, allowing you to install all the extensions relevant to your platform).
The Tcler's wiki has a number of references to additional tools and extensions. However, your favorite web search engines are likely to turn up utilities, tools, extensions, and applications not yet documented on the wiki or added to the ActiveState repository.
MyTcl is a fairly nice IDE with a Tcl environment included, autocomplete, syntax highlighting, debugging, etc. It has a similar look and feel to Visual Studio. The homepage is in Korean, but it's not too hard to find the download.