OSDev.org

Hello everyone !
Recently i was porting basic utils software to my kernel, and i compiled 'clear' without errors. I didn't read the code, i was just trying to compile some coreutils i found on the web and then look at compilations errors to see what i needed to implement. As i did not implement any system call to access the 'clear' methods that i have in my kernel, i was sure it would be impossible. Then i found out that 'clear' is actually only printing a sequence of special characters to the standard output.
Now i need to handle these in my kernel, but i was wondering what was the proper way to do it... I could just copy/paste that sequence and check for it but it seems really bad to me.
I have read some articles on the web like the linux manual, but they are not really helping me.
So, how did you do it ? How did you port 'clear' and adapt your kernel to it ? Is there a convention (some parts of POSIX?) that we should follow ?

Most of those escape sequences are documented. In particular, if you ask Google, you'll find lists of escape sequences that xterm implements (e.g. here). Most other modern terminals just imitate xterm.

For example, the \033[2J sequence mentioned by the Linux man page corresponds to CSI P s J ("Erase in Display (ED)") from the xterm list. Here, CSI denotes the start of the control sequence and consists of the characters ESC [.

The solution is going to depend on a few things regarding how your UI works. Porting the Linux code directly isn't going to work unless you have a lower-level implementation which the ported code can use.

Do you have an offsite repo on, say, GitHub, GitLab, or Sourceforge, which would allow us to view your existing code? That would simplify things for us a great deal, because then we'd be able to address what's actually running.

EDIT: I found this repo on GitHub, which I assume is the one in question based your earlier posts.

Speaking in broad terms, a 'clear screen' utility is going to require you to do two things: a) clear all the character cells in the screen buffer, and b) reset the cursor to the first text cell of the first line of text.

For a 'raw' text mode screen, this would usually mean a memset filling the current screen page with a blank space for the character byte and the current background value for the attribute byte. The details of this, and of writing to the text-mode screen in general, is covered in the wiki page Printing To Screen. How large the fill would have to be would depend on the text mode being used; obviously, a 132x60 text mode buffer will be larger than an 80x30 one.

This would be followed by resetting the hardware cursor as described in the wiki pages on Text UI and the Text Mode Cursor.

However, that is a specific set of special cases; you generally want to abstract this in order to make it easier to write code which also works in, say, a text window in a GUI. This is what the Unix Curses and Termcap/Terminfo libraries are meant to do (as are some newer ones which are specific to Linux, which I don't know as much about; and in the case of a desktop environment, still others specific to the GUI being used).

The clear utility which you were trying to port relies on these - it is sending a series of escape codes which those libraries would then interpret (in this case, ones used by the xterm terminal emulator and compatible terminal emulators, as Korona stated earlier). It is probably getting terminal capabilities information from terminfo or something similar before deciding the specific sort of escape codes (or other facilities) to use for the specific text screen type.

In order to port that utility as-is, you would first need to implement the operation for the specific type of screen, and then implement an equivalent set of abstract libraries (either by porting the Unix/Linux libraries, or writing similar ones yourself) which the utility can call upon.

It sounds as if you already have a screen-clearing routine; if so, then what you need is to get the clear utility to talk to it.

Getting back to the actual topic, terminal control sequences are pretty horrid, so I'd suggest creating a halfway usable framebuffer implementation (i.e. methods to read input from keyboard and write output to screen) and then porting an existing terminal emulator to it (like, say, st or uuterm).

nullplan wrote:Getting back to the actual topic, terminal control sequences are pretty horrid, so I'd suggest creating a halfway usable framebuffer implementation (i.e. methods to read input from keyboard and write output to screen) and then porting an existing terminal emulator to it (like, say, st or uuterm).

I disagree. I think implementing a subset of the modern xterm control set - enough to support applications like vim, and to generally run Curses apps - is a valuable and enriching experience, and not nearly as convoluted as it seems.

One way of doing things would be to look at the source-code for the 'clear' program that comes with (any) Linux distro, and then write a copycat program using your system's libraries, headers, etc, etc. That's what I would do, anyway.

saltlamp wrote:One way of doing things would be to look at the source-code for the 'clear' program that comes with (any) Linux distro, and then write a copycat program using your system's libraries, headers, etc, etc. That's what I would do, anyway.

Apparently you haven't read the thread. The OP compiled the actual "clear" program for his OS. Only to discover that it only prints a control string. And the rest of the thread was about the other side, how to implement control strings in your terminal.

nullplan wrote:

saltlamp wrote:One way of doing things would be to look at the source-code for the 'clear' program that comes with (any) Linux distro, and then write a copycat program using your system's libraries, headers, etc, etc. That's what I would do, anyway.

Apparently you haven't read the thread. The OP compiled the actual "clear" program for his OS. Only to discover that it only prints a control string. And the rest of the thread was about the other side, how to implement control strings in your terminal.

Actually, you failed to either understand or interpret my answer. My answer had nothing to do with him compiling the program, because I already read that he successfully compiled the code. My answer was about him viewing the source code for the native 'clear' program on Linux, and then see how they are doing what he is having trouble doing, and make a copycat of what they are doing, relative to his problem, or problems.

...Now i need to handle these in my kernel, but i was wondering what was the proper way to do it... I could just copy/paste that sequence and check for it but it seems really bad to me.

My answer was pretty darn accurate to his problems. Read the above quote. I said look at the source code and make a copycat specific to his system. Which translates to the following: Find what you are sure about implementing, and then do something similar to what they are doing, therefore solving your problem. (At least somewhat, in the long run.)

And to the OP: since the clear program is (most-definitely) 'free' software, as they say, you can make a sort of 'clone' of it, and then once you have a working program, you can change things, or swap out things, add features, or remove things, to make it not similar any more, if you are worried about copy-pasting being a bad practice or whatever. Ther's nothing wrong with seeing how something is done, so that you can do it, too, in your own way.

Okay, thanks everyone, i think i'm gonna try to implement xterm control set in my kernel virtual terminal...