<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 13, 2016, 11:57 PM Liam Proven <<a href="mailto:lproven@gmail.com">lproven@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why would Oberon not be able to support protocols such as Telnet or<br class="gmail_msg">
SSH? Over that, a TUI could be shown and interacted with without<br class="gmail_msg">
particular difficulty -- but mouse support would be a problem. If some<br class="gmail_msg">
kind of keyboard-based control of a mouse pointer were enabled, such<br class="gmail_msg">
as is used by many disabled people to interact with GUIs, then it<br class="gmail_msg">
would not be a problem at all.<br class="gmail_msg"></blockquote></div><div><br></div><div>It seems like there's at least three different concepts in this thread:</div><div><br></div><div>1) Chaining together simple commands to perform complex tasks, as exemplified by UNIX pipes.</div><div>2) Performing interactive or iterative tasks in Oberon without coding a formal solution.</div><div>3) Interacting with Oberon via some sort of shell.</div><div><br></div><div>If you research #1, you'll find a book called Software Tools where the UNIX concept of "do one thing and do it well" was born, and they code in RATFOR in a handful of lines many of the tools we use today, before the concept of pipes. Pipes only augmented those tools, as discussed earlier.</div><div><br></div><div>But, if you've ever done any Visual Basic scripting, you'll see some parallels with Oberon in that there's an initial pain point. My CV whine was always, "I don't want to have to create and destroy a dozen objects just to append text to a file." So I ended up writing functions to do the things I wanted that could be called in a sane fashion that hid all the mess. No different than what really happens when someone implements grep, and something I believe is still in the spirit of Oberon, seen in every Tool file.</div><div><br></div><div>Thinking about #2, some people use Python as their interactive shell. When you look at the way they approach traditional UNIX workflows and problems, it's very different than the bash mindset. I think someone could write an interactive Oberon shell, but I don't think it would be as efficient as the TUI for the structure of the resulting code.</div><div><br></div><div>Better would be to port or write a new shell. UNIX isn't born with a shell, it's just another program, often interchanged. A good place to start would be Inferno's rc shell, as Limbo and Oberon have some very strong similarities. But, like Inferno, a shell is just a shell, and familiar tools need to be reimplemented using the native language. You'll find their code for grep, cat, etc., but not sed, it was likely not worth the payoff to the implementation.</div><div><br></div><div>Last, connectivity out is much different than connectivity in. Out is old hat, telnet was there in V2, I wrote a VT100 emulator back in the day, and can't imagine trying to tackle SSH in Oberon but it could be done. Connectivity in, for the whole experience it would be easier to construct by doing VNC via A2 or UNIX, but for an alternate experience I like the idea of exposing content or services via HTTP. I'm surprised no one has implemented a wiki in Oberon yet.</div><div><br></div><div>-Jack</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>