Jump to content




Multishell - 10 shells at once without gui


27 replies to this topic

#1 GopherAtl

  • Members
  • 888 posts

Posted 07 February 2013 - 08:45 AM

Multishell lets you run up to 10 shell sessions at once, switching between them by pressing ctrl+1 through ctrl+0. By default it runs instances of the standard CraftOS shell, but you can specify any program as a parameter when running multishell and switch between 10 instances of that instead.

There are many multitasking "OS" options out there, but all seem to be at least to some extent gui-based, whether the gui is an elaborate windowing system or a simple task bar. These are great, but using them tends to limit available screen area for the current program, block certain keystrokes, or both, and I found myself wanting a way to just switch easily between multiple full-screen programs.

The source can be seen on pastebin here http://pastebin.com/e4Uf8M3p

This uses my goroutine API to handle each session as coroutines, my redirect api to create and switch between buffered redirects for each session, and my ctrlkeys api to generate the ctrl+# input events it uses to switch sessions. To save you the headache of grabbing all of those if you don't already have all of those installed, I've written a simple install program which will grab all three apis and the multishell program itself from pastebin for you. You can get more info on these APIs in my api thread, here.

The installer can be downloaded and run from pastebin:
http://pastebin.com/Pn9wbtJv

just enter the following at a craftOS shell to download and install it:
>pastebin get Pn9wbtJv setupmsh
>setupmsh 

You can then delete setupmsh if you want. Just type "multishell" to launch multishell; you'll be presented with a new shell session, bound to ctrl-1. Ctrl-2 will start and switch to a new session; same with ctrl-3 through ctrl-0. exit from any session and you will be returned to another session; close the last session and multishell will start a new shell 1.

I'll be adding more features in the future, possibly making it more screen-like.

#2 Cranium

    Ninja Scripter

  • Moderators
  • 4,031 posts
  • LocationLincoln, Nebraska

Posted 07 February 2013 - 09:12 AM

Wow, sounds really cool!

#3 rhyleymaster

  • Members
  • 186 posts
  • LocationCanada

Posted 07 February 2013 - 05:20 PM

Screenshots please?

#4 GopherAtl

  • Members
  • 888 posts

Posted 07 February 2013 - 06:15 PM

uhm. As I said, there's no gui. You switch by pressing ctrl+#. What kind of screenshots do you want exactly? O_o

I suppose I could do a video, but there's no possible way to show this with screenshots, it would just look like screenshots of a normal CraftOS shell.

#5 Grim Reaper

  • Members
  • 503 posts
  • LocationSeattle, WA

Posted 07 February 2013 - 07:34 PM

This is pretty cool!

I actually made something similar to this after seeing it in hopes that I could simplify it without the use of an external API.
Here's my attempt:

Spoiler
Pastebin.

I managed to crunch it down from 159 lines to 130, even though a lot of my code is filled with comments :P. I also managed to do this without an API that wasn't already built into Lua or ComputerCraft.

However, I think your version probably has a lot more ability to control itself. In fact, my program doesn't check if the program is already running, haha.

#6 tesla1889

  • Members
  • 351 posts
  • LocationSt. Petersburg

Posted 07 February 2013 - 08:21 PM

fantastic job to both of you!

#7 AnthonyD98™

  • Members
  • 193 posts
  • LocationAuckland, New Zealand

Posted 07 February 2013 - 09:51 PM

This looks really cool :)

#8 GopherAtl

  • Members
  • 888 posts

Posted 08 February 2013 - 03:50 AM

Grim: That is quite a bit more compact, but it does have quite a few issues and limitations. The way you handle ctrl-key events can eat events, and only the active shell is updated, the rest are paused until resumed. The approach of queueing all terminal commands and rerunning them to switch terminals also breaks down if a program goes very long without clearing the screen; you'd start to get some pretty serious flickering after a while when you switch between them. And yours does not handle programs that call term.redirect themselves. Also "exit" exits the parent shell, closing them all and shutting down, and ctrl+t terminates the whole thing and drops back to calling shell. All that adds up to making it a lot less usable. But still, for all that, it's impressive what you accomplished in relatively few lines of code!

My goal was to make something I could actually live with all the time. I know it would be more sharable if it didn't have api dependencies, but I always have my apis on every new computer/turtle I set up, so for me at least, the dependencies are a non-issue.

#9 Grim Reaper

  • Members
  • 503 posts
  • LocationSeattle, WA

Posted 08 February 2013 - 12:27 PM

View PostGopherAtl, on 08 February 2013 - 03:50 AM, said:

Grim: That is quite a bit more compact, but it does have quite a few issues and limitations. The way you handle ctrl-key events can eat events, and only the active shell is updated, the rest are paused until resumed. The approach of queueing all terminal commands and rerunning them to switch terminals also breaks down if a program goes very long without clearing the screen; you'd start to get some pretty serious flickering after a while when you switch between them. And yours does not handle programs that call term.redirect themselves. Also "exit" exits the parent shell, closing them all and shutting down, and ctrl+t terminates the whole thing and drops back to calling shell. All that adds up to making it a lot less usable. But still, for all that, it's impressive what you accomplished in relatively few lines of code!

My goal was to make something I could actually live with all the time. I know it would be more sharable if it didn't have api dependencies, but I always have my apis on every new computer/turtle I set up, so for me at least, the dependencies are a non-issue.

I completely understand what you mean. My design was intended to just "work". Plus, 45 minutes of work at 22:00 isn't the best time to write something innovative :P. I would definitely prefer your program over mine if I were to use something like this. Most of the programs I write are just to prove to myself that I could do it, at least.

The control switching is very slow and the stacking of terminal calls in a buffer does become very resource intensive when it comes to using programs that have a lot of terminal calls. However, I'm pretty sure I've presented a possible to solution to this problem by clearing the buffer every time that a program calls term.clear(). You're right in saying that it doesn't handle programs which call term.redirect(), but this could probably be implemented without too much trouble. As for only updating the current shell, I thought that was the intention when I designed my program :P. Also, 'exit' and termination weren't really considered when I wrote this, so you're right there too.

Again, I agree with you on saying that your program is much better in terms of design. Program size, when it comes to ComputerCraft Lua scripts, doesn't really matter unless we're talking thousands upon thousands of lines in difference.

Good job. +1

#10 GopherAtl

  • Members
  • 888 posts

Posted 08 February 2013 - 12:36 PM

clearing the buffer when you clear the screen was an excellent idea, but it doesn't help with programs like edit, which never call term.clear() and redraw the entire screen repeately. In practice, this is one of the most frequent use cases for me - switching between edit and a shell or lua prompt while fiddling with a file.

All the issues I mentioned could be fixed in your version. The result would probably be less lines in total than mine (meaning my program plus apis combined), but using my apis gives other features not directly related to the multishell concept as well. And as I said, I use the required APIs anyway, so if they're going to be loaded, multishell might as well use them rather than duplicate a subset of their functionality!

#11 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 05 July 2013 - 11:17 PM

The install script for this downloads redirect under the name "buffer", and the installation fails to load APIs if it's downloaded into a subfolder. Additionally, os.loadAPI seems to not like loading without leading slashes, or at least full paths. And then, it just hangs. I was trying to help someone get it up and running tonight, and these were the issues we ran into. FYI. :)

#12 GopherAtl

  • Members
  • 888 posts

Posted 06 July 2013 - 07:55 AM

...seriously? And it took how long for anyone to notice, or at least, to speak up about it?

Will fix as soon as I have a chance, on a phone on the back of a boat in the Bahamas atm, may try to fix from my iPad a bit later...

#13 Zudo

  • Members
  • 800 posts
  • LocationUK

Posted 06 July 2013 - 11:33 AM

Looks good!

#14 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 06 July 2013 - 06:41 PM

Heh, I was trying to get it running myself last night. I had thought you were using it on the previous server. I ended up having to set the guy up with LyqydOS, but he was really looking for something like multishell.

#15 GopherAtl

  • Members
  • 888 posts

Posted 06 July 2013 - 08:15 PM

I didn't get around to fixing this today, but maybe tomorrow, or worst case I'll flying back home early next week - tho porting biolock. T 1.6 might take priority at that point....

#16 Brodur

  • Members
  • 21 posts
  • LocationCanada, eh?

Posted 07 July 2013 - 07:21 AM

Yes, a fix for this would be much appreciated, I am trying to run a "server" computer that hosts a printer and an IRC, currently it can only do one or the other.

#17 GopherAtl

  • Members
  • 888 posts

Posted 16 July 2013 - 11:58 PM

View PostBrodur, on 07 July 2013 - 07:21 AM, said:

Yes, a fix for this would be much appreciated, I am trying to run a "server" computer that hosts a printer and an IRC, currently it can only do one or the other.


got back from bahamas and completely forgot about this until lyqyd reminded me on irc.

All is fixed now!

#18 Brodur

  • Members
  • 21 posts
  • LocationCanada, eh?

Posted 17 July 2013 - 11:19 AM

Much appreciated man.

#19 GopherAtl

  • Members
  • 888 posts

Posted 17 July 2013 - 11:10 PM

no problem! I'm a bit embarassed it was posted bugged for so long... lemme know if you have any issues!

#20 computercraftprogrammer

  • Members
  • 122 posts
  • Location$house->Earth->MilkyWay->Universe;

Posted 18 July 2013 - 03:14 PM

Great work, I could so use this.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users