Good news! Today we figured out how to implement Ctrl+C interrupts in WebTerminal. Thanks to Mark for pointing on this.

Now WebTerminal will prompt you to update to version 4.1.2, which includes Ctrl+C interrupts implementation. See the related docs: when there is any selection, Ctrl+C will work as a normal text copying. But when there is no text selected, Ctrl+C will work as an interrupt.

Mark, I need a bit more time to implement non-freezing long output behavior, but it is in my list now and will be implemented soon. Thanks for your comments!

Mark,

Good point on the output issue. I was thinking to make non-freezing output during the development but postponed this idea in favor of synchronous output (which is freezing browser until all the content renders). I will take this into account in future versions of WebTerminal.

CTRL-C for now works as a default combination for copying text. Unfortunately, after reading documentation a lot, I am still having no idea how to implement interrupt in WebTerminal. Technically speaking, I need to send the interrupt signal to a jobbed process somehow, but continue to execute it from, for example, some label in the COS code. Any help here is appreciated!

To track the interrupt enhancement, I have created this issue.

Hello Mark, thank you!

I did a little fast research and found that it is possible to make the behavior of printing long output similar to the standard Caché terminal (just to make terminal scroll and scroll through the text until the output stops). But how do you think, does it makes sense to replace this "freezing" behavior with always-scrolling output? In both cases, the output is not readable (normally readable). Maybe it makes more sense to display a floating message like "Output in progress..." when WebTerminal freezes for more than 1 second?

Would be glad to hear your opinion, thanks!

Hello Sebastian!

I am glad to hear you like WebTerminal. I do as much as possible to make it even better.

For now, WebTerminal may still have some escape sequences not implemented, and there is one issue that may also cause old "dinosaur" application to work in a little bit different way. If you find the reason causing the terminal application not to work as expected, please, feel free to describe this in the GitHub's issues section.

Hello Kevin!

It's all about setting up the /terminal web application. Go to the Management Portal -> System Administration -> Security -> Applications -> Web Applications, then choose /terminal web application.

There you can specify the required resource for this web application:

For example, you can specify %Development resource, which means that any users that do not have the access to this resource will not be able to log in to WebTerminal.

As _SYSTEM user has this access, you can create a custom resource, for example, WebTerminal, and create a role WebTerminal which provides the access to this resource, and then set up this role to the web application and assign this role only to those users you want to have access to WebTerminal.

Please, feel free to ask if you need more details about setting up roles and resources.

Thanks for the good question!

And a question to community: I think creating WebTerminal role/resource programmatically during the WebTerminal installation makes sense, does it? As well as adding some documentation on setup/use/roles/etc.

Thanks to Bernd, I finally found that this is not a Caché sessions unexpected behavior, the reason is in the browser's basic authentication cache.

To clear the browser's cache, here is one "dirty" solution for this: stackoverflow (and probably the only solution). The JavaScript function sends the wrong login/password authentication request to the server, and it results as 401 Unauthorized error. And this forces browser to clear its cache.

Thank you,  Stuart!

I think this is a complete solution. I wrapped it to a class method and it works just as expected:

ClassMethod VarList() As %String
{
    IF $DATA(%) ; This places the existence of variable % into $TEST.
    NEW SET %=$SELECT($TEST:$LISTBUILD("%"),1:"")
    SET:$DATA(%0) %=%_$LISTBUILD("%0")
    NEW %0 SET %0="%0"
    FOR {
        SET %0=$ORDER(@%0)
        QUIT:%0=""
        SET %=%_$LISTBUILD(%0)
    }
    QUIT %
}

Results with

USER > write
%=11
a=<OBJECT REFERENCE>[1@DevProject.Robot]
i=5
USER > zw ##class(DevProject.Robot).VarList()
$lb("%","a","i")
USER > kill %
USER > zw ##class(DevProject.Robot).VarList()
$lb("a","i")