command line design

[kr651129]

So I've finally managed to move from stupid to n00b and I've got a C++ kernel printing a simple message after loading with grub. I'm reading every post and looking through the forum and I see all sorts of advanced design & theory topics but I haven't found one for command line. Is this something that is just straight forward or is there a bit of design and theory behind it. My question is if there are more advanced topics to command line how did you set yours up? I'm interested to see if we are all like minded or if see the difference between everyones first steps.

[Solar]

The command line shell is a userspace process. I.e., you need most other pieces of your OS to be already in place, like memory management, interrupt handling, I/O. It is not the next step after "Hello World".

[kr651129]

I understand, and while I'm working on the base of the operating system I still would like to learn how others designed their shell to think ahead.

[Brendan]

Hi,

I understand, and while I'm working on the base of the operating system I still would like to learn how others designed their shell to think ahead.

A basic shell is extremely simple - just something that receives "keypress packets" via. IPC and stores characters into a buffer; and sends changes to its display to some sort of "generic terminal" process (which handles control characters, etc and draws the actual graphics - maybe in a window of your GUI). When it receives a keypress packet that contains "enter key pressed" it parses the buffer of previously pressed keys to determine a command name and some command arguments; then it determines if it's an internal command (e.g. "cd") or an external command. If it's an internal command it does it; and if it's an external command it uses "system()" or "fork()/exec()" or "spawnProcess()" to create the new process that performs the command.

Once you've got a good scheduler capable of creating processes, memory management, IPC, device drivers, file systems, a "generic terminal" layer, etc; it's easy.


Cheers,

Brendan

[OSwhatever]

I've always wondered how you are supposed to split the components in order to make it modularized and easy to reuse. Should you basically have 3 instances of processing?

First we have the serial driver, just a driver that sends and trasmits data.
Then we have some immediate mode, let's call it line dicipline mode. Here we process the text so that it support a myriad of differet useful things. For example control characters detection, arrow up and down history, editing of the existing commandline. Basically what you see is not the command interpreter but a special program that helps you creating and editing commands. Also you can convert between character sets here.
Then we have the command interpreter, which basically just receives a string with the command and executes it.

What do you think about this kind of separation? Should the line dicilpline be a part of the command line interpreter or should it be a separate?

[gerryg400]

I've always wondered how you are supposed to split the components in order to make it modularized and easy to reuse. Should you basically have 3 instances of processing?

First we have the serial driver, just a driver that sends and trasmits data.
Then we have some immediate mode, let's call it line dicipline mode. Here we process the text so that it support a myriad of differet useful things. For example control characters detection, arrow up and down history, editing of the existing commandline. Basically what you see is not the command interpreter but a special program that helps you creating and editing commands. Also you can convert between character sets here.
Then we have the command interpreter, which basically just receives a string with the command and executes it.

What do you think about this kind of separation? Should the line dicilpline be a part of the command line interpreter or should it be a separate?

It sounds about right. I think the 3 things should be separate. I think it's better to keep the line discipline separate if possible so that multiple shell programmes can get the same 'feel' from your OS. The only grey area for me is history. Most shells maintain their own history and I'd like to separate history from line editing but it seems that it's not that simple.

[ACcurrent]

For history there are several ways of doing it. It depends on the way you want your shell to behave, if you have a file system or some form of persistent object, then every time you hit enter, the parser saves it to this object. The other way is to have an array in memory and retrieve info from that array. Think of creating a CLI shell in a higher level language, how would you do it: its the same for OS shells.