EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: peter-h on February 18, 2023, 09:28:29 pm
-
I am fairly familiar with basic HTML. The client sends a URL to the server and the server serves the page.
The page served has to be a properly formed HTML page (there are some variations between browsers in what variations they accept).
Q1: if the server just keeps sending data with a
at the end of each line, will the text scroll up, like on a dumb terminal? And if so is this documented behaviour?
Q2: can a "dumb terminal" be created inside a rectangular area? Obviously anything is possible with JS.
-
Voila:
https://www.tecmint.com/shellinabox-web-based-ssh-linux-terminal/ (https://www.tecmint.com/shellinabox-web-based-ssh-linux-terminal/)
Fancier stuff:
https://hackaday.com/2018/12/21/linux-fu-share-terminal-in-browser/ (https://hackaday.com/2018/12/21/linux-fu-share-terminal-in-browser/)
-
Sorry - should have made this more clear. This is not unix; it is an embedded system (arm32) that runs a primitive HTTP server, written entirely in C. In one particular context I would like to display scrolling data on the page.
Is there some HTML construct which would allow this e.g. a frame?
It is also not really a "terminal" since no client keystrokes are involved.
-
Sorry - should have made this more clear. This is not unix; it is an embedded system (arm32) that runs a primitive HTTP server, written entirely in C. In one particular context I would like to display scrolling data on the page.
Is there some HTML construct which would allow this e.g. a frame?
It is also not really a "terminal" since no client keystrokes are involved.
Well then, that's not a terminal and this "infinite scrolling console/log window in a browser" is quite a feature to implement in a "primitive HTTP server", that is the static CSS and JS to serve are of course no problem, but data refreshing is an issue, not to mention that browsers have disabled auto-scrolling left and right for security reasons.
All in all this is ridiculously difficult to implement iproperly in a deep embedded environment, so I'm really curious about your chosen solution.
Cheers,
DC1Mc
-
Might be doable with websocket - haven't done this but it's on my list of things to have a go at.
A simpler thing might be XMLHttpRequest(). The idea is the browser polls the server regularly, and the server sends back whatever has been buffered up since the last poll in response. There will be lag (the polling period) but it's simple. The web page will need javascript to deal with the incoming data (send it to a text box or similar), and if you want to type stuff it needs to do that as well.
Crude, but maybe it would suffice for your purposes.
-
I have used this library: https://terminal.jcubic.pl (https://terminal.jcubic.pl).
-
Yes you can do this. I do this in one of my CGI scripts that slowly outputs text over the course of a few minutes.
- (Not relevant if you're writing your own) I had to change the config of my webserver to "stream the response body", otherwise it waited for the whole page to be ready before sending it to the client
- Firefox doesn't draw until X bytes in, so send a bunch of useless characters to bypass this. After that it will redraw after every part recieved.
- I stream mimetype txt rather than html, because I'm lazy
- Sadly this means I have no way of auto-scrolling to the bottom of output! You need JS (or maybe just some CSS? That's be nicer) to do this.
- Not sure of the timeout, I've not hit it.
-
Sorry - should have made this more clear. This is not unix; it is an embedded system (arm32) that runs a primitive HTTP server, written entirely in C. In one particular context I would like to display scrolling data on the page.
Is there some HTML construct which would allow this e.g. a frame?
It is also not really a "terminal" since no client keystrokes are involved.
Well then, that's not a terminal and this "infinite scrolling console/log window in a browser" is quite a feature to implement in a "primitive HTTP server", that is the static CSS and JS to serve are of course no problem, but data refreshing is an issue, not to mention that browsers have disabled auto-scrolling left and right for security reasons.
All in all this is ridiculously difficult to implement iproperly in a deep embedded environment, so I'm really curious about your chosen solution.
Cheers,
DC1Mc
http text area element, using js to refresh with responses from server?
-
Yes I did wonder. I already have an Edit Area in there (to enable remote editing of a config file) and that uses JS to send the stuff up and down. JS is also used for file transfers.
The periodic updating is done from the client, by sending the HTML 1Hz refresh construct (supposedly a crude way; most people seem to prefer JS for refreshing a page). The whole page is updated.
So one could implement a crude version using the client-side refresh, but nothing that updates faster. So basically we are back to JS setting up some protocol, and setting up a window on the client where it implements scrolling. Just like we used to do in 1980 on Z80 systems :)
Isn't there a thing called AJAX, where the server is continuously sending out page updates?
That cubic.pl terminal looks amazing! The description is a bit above my pay grade though; not at all sure I can implement it as I have no server side JS. Just plain C.
-
websocket + javascript
-
OK; this isn't anything simple e.g.
https://github.com/Theldus/wsServer/blob/master/src/ws.c
and then you need to write some client JS to implement the scrolling window.
So, no simple way.
-
Q1: If the server keeps sending data with a newline character (\n) at the end of each line, the text will be displayed on the browser as plain text, and the browser will not automatically scroll the text up. The behavior of scrolling up or down is determined by the browser based on its default settings and the user's preferences.
If you want to have a scrolling behavior, you can use JavaScript to create a <div> element with a fixed height and set its overflow property to auto. Then, you can use JavaScript to append new text to the <div> element, which will automatically cause the element to scroll down as new text is added.
Q2: Yes, it is possible to create a "dumb terminal" inside a rectangular area using JavaScript. You can create a <textarea> element with fixed dimensions and set its readonly property to true. Then, you can use JavaScript to append new text to the <textarea> element, which will cause the text to appear as if it is being typed in real time. However, this approach may not be ideal for large amounts of text or frequent updates, as it can be slow and may cause performance issues. A better approach might be to use a <div> element with scrolling behavior, as described in the answer to Q1.
-
Then, you can use JavaScript to append new text to the <div> element, which will automatically cause the element to scroll down as new text is added
Won't that cause the div to eventually run out of memory? Or does the auto property delete the stuff scrolling off?
-
Actually, this makes a good interview question.
As eluded to above, a preferred contemporary method is to use a web socket to push the text stream onto the browser. However, this assumes that the web server, web client and network rules, support web sockets.
Remember, it was always the way with http that clients request and servers respond. Not the other way around. Web sockets do go a long way to solving this conundrum.
Other options might include; old fashioned http page refreshing. Another, which rebuilds the whole or part of the page. Using a client side timer event to call an Ajax request pointing to an http handler (cgi script) on the server. Data is then returned to the client in text/plain or text/json.
Text is displayed inside a DIV tag structure styled to look like a dumb VT terminal or ticker - or maybe even an IFRAME for the http refresh. A way to handle 'too much' data is to first buffer text into some kind of circular array.
@peter-h Truth; there is no ONE answer. But with the exception of the http refresh, every method requires javascripting.