I'm not totally clear on how using the command line differs from working through the OS' interface using an editor for example. Obviously the UI is different but I want to understand how the command line interacts with the kernel and microprocessor, and how this compares to how kernel interfaces with the OS' GUI. I know I'm missing several layers of abstraction but would be grateful for someone to explain this.

closed as off topic by user7519, Thomas Owens Sep 29 '12 at 10:24

Questions on Software Engineering Stack Exchange are expected to relate to software engineering within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    You may want to clarify what you mean with "the OS" here. I get the feeling that you are confusing the OS with its user interface. Assuming Windows, the command line is one way of interacting with the OS, and the GUI is another. On most Unix-like systems (including Linux), the GUI is just another application that runs on top of the OS, no different from the command line shell. What the GUI allows you to do is little different in principle from what the command line allows you to do (barring tool limitations). Etc. – a CVn Sep 28 '12 at 22:35
  • @MichaelKjörling I've updated the question to hopefully clarify what I mean. The question has been closed now as off topic but I do think this falls broadly under software development (either environment or methodologies) and not sure where else it should go. – br3w5 Sep 30 '12 at 14:00

To understand what the command line is you have to understand that in modern operating system, specifically monolithic-kernel OSes, like Linux, MacOSx and Windows. These type of operating systems can be described at the simplest abstraction as seperated into a core "kernel" that executes system critical programs the OS depends on (memory management, interupt handlers [IE: when you type a key, this is an example of a hardware interrupt the OS needs to be interrupted to address immediately], ect) and a userland "shell" where your windows desktop and all your programs run in. (web browsing, games, ect)

The typical PC user never worries about what goes on in the kernel, because everything they interact with is done through the userland interface software. The OS depends on the kernel's executing software to be stable to function correctly, therefore the user is typically prevented entirely, or very restricted from directly interacting with the kernel.

Thus the command line allows you to execute small userland programs called tools. These tools provide an interface to call into the operating system via (who would have guessed) system calls. If you are writing a program, and you need a block of memory. C's malloc can be thought of as calling the kernel to ask if you can check out some unused memory for awhile. Then when you call Free on that memory, you are basically letting the OS know you are done with it and it can reuse that memory for other system threads that are concurrently executing (other programs that are doing work in the background, ect)

The kernel interacts with the CPU by laying out binary opcode instructions in memory so the CPU can be feed the next instruction it needs to execute every clock cycle. (2.5 ghz = ~2.5 million clock cycles a second. Which in a perfect theoretical world ~= 2.5 million instructions the CPU processes / sec.)

The way binary works, is each chip is designed in a very complex way where different patterns of 1s and 0s cause the chip to route the data to different places on the motherboard.

And thats a computer in a nutshell. (boom-boom tish)


The command line is just another interface to the operating system. It's more easily understood if you call it a command interpreter. What it does is input commands in text form, parse them to determine their meaning, and make calls to the underlying OS based on the meaning.

It's not that different from what a graphical command interpreter does, such as Windows's "Explorer" shell. It inputs commands from the keyboard and mouse, interprets them according to the UI rules to determine their meaning, and makes calls to the underlying OS based on the meaning.

For example, if I'm at the DOS prompt, and I type myProgram.exe, it will search the current directory and the path and, if it finds myProgram.exe, make a call to the OS function that launches a new process, spinning up an instance of the program.

The equivalent operation in the GUI would be to double-click on the icon for myProgram.exe, or a shortcut to it. Since the exact location of the program is already known from the context, it doesn't have to search for the EXE; it just makes a call to the OS function that launches a new process, spinning up an instance of the program.

None of these things have much of anything to do with the microprocessor, except in the sense that everything runs on the CPU. If you meant to ask if commands input by the command line talk directly to the CPU, the answer is no. They're described in a human-readable language, and like any other human-readable command input to a computer, (such as programming languages,) they have to be parsed according to formally-specified grammar rules first.

Not the answer you're looking for? Browse other questions tagged or ask your own question.