rsshell integration - pseudocommands

[lramati]

Issue #62 added an irc bot, and the discussion proposed another. Not that I don't love irc bots, but in a project like this, how many people are actually going to be able to run their own? So I want to write a program that would allow them to connect locally in the background, and you would communicate via command line. In order to not have to spawn a second window, I want to be able to do this over the main rsshell. However, it doesn't make sense for the commands to exist if the "server" isn't running or no bots are connected, so I propose that programs should be able to register and unregister commands with the shell when they start up or turn off.

In my specific usecase, starting up another bot and connecting it to the "server" would cause the server to register a command allowing you to communicate with the bot (or bots) from the command line.

[jgonggrijp]

Isn't that just a rather complicated alternative to running an irc server on localhost?

[lramati]

Yes, and yet, an irc server is a lot of overhead for basically a single user environment, and also, integrating with rsshell might allow for some cool stuff. Not to mention it would mean developing a bunch of interesting features along the way which could get used elsewhere

[jgonggrijp]

Well, you have my interest.

[WesleyAC]

I like it. This would make an idea I had much easier: making a sort of rsshell "screensaver" that would display an asciimation of some red spiders crawling over the screen if there was no input for x seconds ("x" being defined in #31). However, this would require a hook to run the command only during idle time (when nothing else is happening).

[lramati]

I don't know how feasible this is, but what if rsshell ran all the programs in the background but hooked up the input and output to internal buffers? That way it could simulate interaction with the programs you run, while you're actually interacting with rsshell, which would allow rsshell to output things that aren't from the currently foregrounded program to the screen. This could also spawn other interesting features such as multitasking within the same shell, or sending commands to things that aren't the currently running program (e.g. getting the prompt input a number: and replying with something like __rsescape(rsshell: screensaver stop)) since rsshell could intercept them and never forward them to the currently running program. Also makes the whole sending signals thing easier since the program could just output escapes to stdout and rsshell would intercept them and not print them to the screen. However, if we do use stdout to have the program talk to rsshell, I suggest setting some sort of environment variable so the program can know if it was run from inside or outside rsshell to avoid printing "garbage" to the screen

[jgonggrijp]

You can do the background thing with I/O redirection using sockets. You can also just continue writing commands with the assumption that they're being directly invoked (i.e. writing to stdout without them needing to be aware of the socket stuff) if you just write a single wrapper command which simply takes any command and executes it as-is while redirecting its stdin and stdout to the socket.

So I think it can certainly be done, even without changing existing commands. Nonetheless, it might still be hard to actually make it work.

[WesleyAC]

Here's what I'm imagining you're saying:

Every command is ran in a separate thread. Each running command has an output buffer. If a command does print("Hello world") then it's buffer would contain Hello world\n. The shell would have an input buffer. By default it would send input to the command currently being displayed. However, if the shell received certain special key combos, it would switch the current command, or send input to another command.

That way, we wouldn't need to change any of the commands, and it would probably solve the problem in the original issue.

[lramati]

Pretty much. Doesn't necessarily have to be special keystrokes, could just be special input, but yes. Have the shell monitor everything the user inputs to the program and the program says to the user, and be able to recognize sequences that instead of being intended as output are intended as some sort of instruction to the shell.

Other than that, the original thing I opened the issue about was allowing daemons or other background processes declare commands that can be typed into the shell which the shell would then forward to them so they do something. (Returning to the fake irc server idea, a command that only exists while the server is running, and is equivalent to foregrounding the server, typing in a message, and then backgrounding it again)

[mrhmouse]

@firerogue: What's the difference between "special input" and a command that passes messages to daemons? What is the expected behavior of such a command if the daemon isn't running?

@WesleyAC: That sounds a lot like a terminal multiplexer. Also, how would you deal with non-ASCII data, like ncurses interfaces?

[WesleyAC]

@mrhmouse: It is, just built into the shell. As for non ascii data, I don't think it would be a problem. If someone writes to stdout, they should make sure the terminal can handle it. (Pardon me if I misunderstood, I'm not sure if I understand exactly what you are asking.)

[mrhmouse]

What I'm getting at is that there are interfaces besides the exchange of text between user and program. For example, check out the terminal file manager ranger, written in Python. I could see an RSP application making use of ncurses (as an example), particularly if someone ends up writing a game.

Maybe I'm missing what you mean by "buffer", though, and this isn't even an issue.

[lramati]

@mrhmouse: what if the buffer can keep track of exactly what's supposed to be on screen? A full 25x80 buffer. (Or have it implement ncurses or another graphic library itself to be aware of a changing size and color and whatnot) because even ncurses (as I understand it) does it all in text mode, so if we can track what the screen(s) look like, we can just flip between them by erasing one and overwriting it with the other

The difference between the two things I'm describing is that one is a command that functions at the shell prompt. If the daemon isn't running the command doesn't exist, and the shell outputs an error to that effect. The second functions while running a program from the shell, and is just a way to pass anything to the shell. Access the shell prompt from inside the program as it were. Or the input of another program also run from the shell.