Ability to capture signals in PowerShell

[kiedtl]

In bash, you have the feature of trapping signals (such as EXIT and SIGWINCH) and executing a series of statements when those signals are received. E.G.

trap 'do_this; draw_that; blah_blah_blah;' SIGWINCH

I am aware other ways a ctrl-c event could be handled, but I'm trying to handle a SIGWINCH and to the best of my knowledge there is currently no way to do this in PowerShell.

Such functionality could easily be provided by a .NET event handler, or by a cmdlet, using the Windows API (I'm not familiar with win32, so I'm in the dark on how exactly this could be accomplished).

[iSazonov]

Perhaps @PaulHigin could weight this. It could be useful on Unix. Not clear about Windows. Not clear about portability.

/cc @mklement0 @SteveL-MSFT

[kiedtl]

It would be really useful when implementing a script that needs to redraw text hen the windows is resized. E.g. I am working on a port of pxltrm to PowerShell (see this repo), and here such a feature would come in very handy.

[kiedtl]

Question: does Windows have some sort of API that could handle this?

[iSazonov]

Currently PowerShell Core to work with console uses Windows API on Windows and .Net Core API on Unix. So it is not easy to address your question.

[lzybkr]

Signal handling might warrant an RFC because there are interesting design choices - map to exceptions or an event handler.

Windows does have an api to report when the console is resized, but it is somewhat painful to use, see this example.

If you go this route, you need to handle keyboard events that are handled by apis like Console.ReadKey, e.g. you would see both key up and key down event for a single key press.

[kiedtl]

H'm... Well, the venerable Windows API is, by definition, painful to use.
I mean, just think of all their custom data types, to start with: LPSTR, LPTSTR, UCHAR, TCHAR, LPCTSTR, LPCSTR, LPCWSTR, LRESULT, DWORD32, HWND, PCHAR, PCSTR, PCTSTR, etc.

Hundreds of different type of strings. Its almost as if win32 was designed to be painful to use.

[iSazonov]

The console application in Windows usually does not need to worry about resizing the window. Another thing is WinForms...
Everything is simple - you need to use right things in right places. Usually, difficulties arise when you choose the wrong means. Do not blindly mirror Unix experience to Windows. You will be surprised how much easier it is to do some things on Windows than on Unix if you know how to.

[kiedtl]

Do not blindly mirror Unix experience to Windows.
You will be surprised how much easier it is to do some things on Windows than on Unix if you know how to.

I would appreciate it then, if you could tell me what to do in this case. I can't really think of any other way around this.

I am drawing lines of text three lines before the bottom of the screen. I need a way to clear those lines and re-draw them at the bottom of the console when the console is resized. I cannot implement this until I have a way to know when the console is resized.

I suppose I'll just have to write a C program that'll call the appropriate API's and do it for me. But then I'll have to mess around with - God help me - DWORDs and HANDLEs and WINDOW_BUFFER_SIZE_EVENT and ResizeEventProc and who knows what else. I'm going to have to worry about Unicode and (*shudder*) pointers and malloc, and the rest of the crazy stuff.

So I guess I'll just put this off until I find a better way. *sigh*

[iSazonov]

@kiedtl It is PowerShell Core repo. I can only say that PowerShell Core is probably not right tool for your task. But if you need PowerShell Core perhaps you have to re-design your application.
Also the main PowerShell Core principle is portability - it works on all platforms (Windows, Macos, Linux-s) where .Net Core works. So you shouldn't use low level Windows APIs - you should use C# and .Net Core APIs.

[kiedtl]

I just remembered - wouldn't it be easy to use a DLLImport of some sort in C#? You could (I think) somewhat painlessly call the appropriate APIs comfortably from .NET.

If PowerShell is running on Unix, You could just throw a PNSE. .NET Core does something similar here.

I suppose that this issue is for the dotnet/corefx repo.

[iSazonov]

It is implementation details. As I said above we should be full portable and should avoid PNSE.

I suppose that this issue is for the dotnet/corefx repo.

Feel free to discuss there if you have usecase.

[lzybkr]

@iSazonov - a console application with a TUI has a definite need to handle window resize events - it's a problem that I never fully addressed in PSReadLIne because of the difficulty (initially) and the lack of portability (later).

Now should people write console applications in PowerShell? .Net? I'd say yes, it seems reasonable.

[vexx32]

@lzybkr isn't this kind of already done by WriteProgress()? or at least the underlying console API it calls, however it does that.

[powercode]

I don't know if WriteProgress is such a good example. Works kinda shaky.

[vexx32]

It's true, it's not perfect. But it does do this, to some extent. 😄

[iSazonov]

@lzybkr Perhaps I was not clear. I said about regular cases - most of console applications (and scripts too) is very simple. (For PowerShell all needed output features should be addresed by conhost/formatting system) PSReadline is heavy application and edge case. If it were a frequent case, I believe MSFT team would have addressed this a long time ago. I see that MSFT is actively developing a new console on Windows 10. We could ask them for the necessary enhancements. But I can’t imagine how it could be ported. But why not (if MSFT go to convergence)?

[kiedtl]

It is implementation details. As I said above we should be full portable and should avoid PNSE.

Isn't there a way to do that on Unix too? I mean, how does bash do it??

[iSazonov]

@kiedtl I think it is question for MSFT console team - perhaps they could find way to port the API.

[kiedtl]

Alright.

[lzybkr]

I'd like to keep the issue open - it does make sense to support signals in a general way.

I agree console resize events are not in scope for PowerShell.

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.