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 Jarrod Roberson, Thomas Owens♦ Sep 29 '12 at 10:24
Questions on Programmers Stack Exchange are expected to relate to software development 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.
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
The equivalent operation in the GUI would be to double-click on the icon for
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.