Uzenet Shell

[D3thAdd3r]

I'm on a warpath to find instant real uses for both Uzenet and the expansion ram, especially if they require little work. I started playing with pipes and console redirection(never was a linux poweruser so this type of stuff seems new and amazing to me). It ties in nicely with my side hobby(Uzebox has slowly become my main hobby over the years) where distributed computing is a big factor for some primitive AI network. Long story short, pipes are very easy and they allow a string to be executed on the Uzenet server and the results spit back to Uzebox. Right now all I have allowed access to is the lynx web browser to dump text versions of webpages so the Uzebox can, in theory, already browse the web once the appropriate program has been made. Even text versions of webpages can quickly exhaust the internal 644 ram, let alone the UART buffer, so all of this shell access stuff depends on SPI ram working cleanly. Lynx itself makes the majority of pages I tested surprisingly usable, including these forums, and I think it should be a standard service on some low cpu priority "Uzenet frills" server. I'm just fishing for a brainstorm here, I think the uses are only limited by interest in doing so.

I'm just talking about the idea in general and am no where ready to start working on it. I attempted to write a telnet program for Uzebox a while back but didn't get too far before I realized making a fully usable one is not trivial. The pipe idea, I am pretty sure, will allow Uzebox to have access to essentially any program, like telnet or ftp for rom download, that Linux or Windows can run from the command prompt. So if we had a local 644 program that allowed you to do a just few Uzebox specific things like setting up ESP8266, BAUD rates, keyboard support, sending data on the UART, copy+paste, and store+scroll through SPI ram as text we basically have an instant Uzebox shell with gigahertz of power available...squished through a 57600 baud link The nature of the command prompt is usually blocking, so it would need to be a separate server program that ran say maybe 4 threads to allow 4 max users at a time. For security names and passwords stored in the eeprom to login would be necessary, but past that I see no reason a trusted member should be too restricted from using some of the server's horsepower for his enjoyment. It will be quite some work to do this and I'm probably not the best person for the Uzebox side of this, but the beauty is it really makes a powerful use case for all of the recent upgrades: keyboard, ESP8266, SPI ram; at the same time...my final sales pitch, this can probably be rigged up to allow Uzebox CP/M, and I bet the output will come faster through the network than the Uzebox could calculate locally.

[uze6666]

That sounds like a pretty neat idea. Do you have some pointers to read on pipes, I'm not too familiar with them. Btw, why doesn't telnet works, the client is harder than expected?

[D3thAdd3r]

I was struggling to make a UART system that was generic and easy to use. I attempted to develop Telnet on top of that, while I was changing it... I had a lot of twisted complex code that I thought was good, problem was it didn't work right. Telnet has all these DO/DONT/WILL/WONT sub messages and it was turning into more time than I wanted to invest when we didn't have basic Uzenet stuff up. It is hard to tackle 1 thing, because it feels like they are always inter-related with other stuff that needs to be done first.

Pipes, I got something up late last night that uses _popen(), it's working right now if you want to modify Uzenet demo quick to download web pages to Uzebox. Well, I apparently was reading about some non-standard implementation or else I was just that tired. _popen can be used for read OR write, but not both at the same time(seems some implementations have bidirectional pipes, maybe BSD, though for sure not Linux/Windows). Anyways I thought I was really clever and threw together a server which is a stripped down version of the other servers, added the writing part, nope. You would have to call _popen again to send more, but it would be a fresh shell so it only works for one-off commands like dumping a webpage for now.

After some research it seems like every unix guy has an implementation using fork(), but I really don't think fork() is a good method for something that is scalable. Of course the current server can't use fork() being Win32, and it's not the only way probably not even good. I am confident there are better crossplatform methods using _pipe(), but I don't have working code to demonstrate at the moment. Read about _pipe() on MSDN and check out this link, lots of other scrambled info on google but those are the best nuggets I found.

That link uses windows specific code, but good demonstration that it wont be a lot of code in the end. We should be able to spawn a shell in a crossplatform way either using/abusing exec()/spawn()/etc. Basically we want to end up with 2 FILE pointers, 1 can write to input of the shell(from sockets recv(),from the Uzebox), and the other one can read from the shell(and sockets send() to the Uzebox). When there is no data to read or write flip over to the next user, or just thread it. I see there could be other ways by STDIO redirection but I never used it before. I can get a grip on it at some point, but I expected instant victory..now I should finish the more fundamental/less exciting high scores as 2 games are waiting on it. I have more confidence in you figuring this out than myself to be honest, most stuff in general heh. If it's interesting to you by all means claim this baby and run, you already made the keyboard and the 80 columns mode, this almost seems a next logical step to a full CP/M terminal.

[D3thAdd3r]

Another link I will investigate this direction a little more. Pipes really are just sockets I guess.