in an OS why is the command interpreter usually separate from the kernel?

Question

in an OS why is the command interpreter usually separate from the kernel?

Answer 1

The command line interpreter is interested in looking at directories and executing commands. If the interpreter were written into the kernel it would not only complicate the Kernel in most cases but the code would be more difficult to write. Much better to use the API that the kernel provides so it can make use of all the facilities the kernel provides. A kernel might provide:

- Transport level network communication (the ability to make network connections)

- Process creation for multiple-users arranging for each process to believe that it has the whole machine (when it just has a piece of it)

- Multitasking, allow multiple programs to run on one CPU

- Memory Management: make it look like there is more main memory than there is by using hard-disk.

- Protection: protect commands from each other and malicious software by controlling how they can access each other. The kernel runs in a separate "mode" often giving protection at a hardware level.

- Disk: provide abstractions so that different media can be treated as disks.

- Hardware Drivers: to provide easy to use interfaces with new hardware installed. Some hardware may need some specific requirements for it to work correctly.

- Multi User: the system might give the impression to each user that they have a machine to themselves.



There are different types of kernel and the services that a kernel provides can vary from system to system. Rarely is the CLI built in: there are better candidates which often don't make it. Having the CLI outside the kernel also has many advantages, on many systems it is much the same as any other software and can be upgraded and tweaked as need be. Upgrading kernel software is far riskier and normally has more profound effect on the machine's operation.





Background commands refer to commands are commands that the interpreter should not wait for before asking/executing another command. A command that runs in the foreground will stop the CLI from accepting/executing new commands while it is running. This has a little to do with the kernel, first the kernel needs to support multitasking so many tasks can be run. It would also normally indicate that multi-tasking was available in a form where CPU-time is shared out well. I don't think it helps too much with your question.

Answer 2

Other than what has already been stated, I also want to point out that by keeping parts of an OS separate, things are easier to fix. By making different parts independent of each other, you can heavily modify/update the kernel, and as long as it uses the same interfaces to connect/communicate with separate modules/pieces as the old kernel, the command interpreters will still work. The inverse is also true. And by keeping things modularized, if a problem occurs in something separate from the kernel, the system is less likely to crash or create a kernel panic. Also, bug-fixes are easier because one can locate the problem much easier if pieces are separate.



If you are talking about the same things, putting commands and processes in the back ground is as it sounds. You have a process running or on hold in the background while the focus is on something else. Above, a user gave an explanation saying it roots from batch and queue processing (it sounds right, but I cannot verify or deny it). In command lines in linux, you can run process in the background on modern systems. Either type an ampersand after a command or run a command and type ctrl+z (which pauses it) and then type bg to make it continue running in the back ground (and fg to put it back in the foreground). This method of 'backgrounding' process would be something like the command line equivilent to minimizing windows to work with another program/process.

Answer 3

Command Interpreter System

Answer 4

Backgrounding is the concept of putting tasks into a lower interrupt state so they do not interfere with more 'real-time' task requirements.



Back in the days before 'real-time' computing, most jobs were simply submitted as batches and queued for work. Today since a lot of tasks are performed in real time (moving the mouse, updating the screen) the idea of moving tasks back to the background so that when the system had free resources it would move these tasks to a higher level and lower them when the system required more real time processing.

Answer 5

The ci is part of the kernel - it's separate from the other parts, because each part is a separate part.

Answer 6

otherwise you can't background commands and all lockups are deadly.