Using the command line (or “shell”) has the following advantages over GUI environments:
The shell is essential for programming repetitive tasks, which can only be performed laboriously through a GUI—for example, searching a file system for all document files that have changed each day, and making a copy of all these files (with the extension .doc) to a backup directory (with the extension .bak).
The shell can be used to search for, modify, edit, and replace Solaris configuration files, which are typically stored in text format. This is much like the approach taken with Windows .ini configuration files, which were text-based. However, versions of Windows after Windows 95 used the Registry to store configuration information in a binary format, making it impossible to manually edit. All Solaris configuration files are text-based.
The shell has a number of built-in commands that typically mirror those provided in the C programming language. This means it is possible to write small programs as shell statements that are executed as sequential steps, without having to use a compiler (just like MS-DOS batch files are interpreted without requiring a compiler).
The shell can be used to launch applications that use a character user interface (CUI), which is especially useful for logging in to a remote system and being able to use all the commands that the administrator can use on the console. In the era of global information systems, this is very useful. While Windows applications like Symantec’s pcAnywhere can be used for remote access to the Windows desktop, they don’t easily support multiuser access (or multiuser access where one user requires a CUI and another a graphical user interface, GUI).
The shell can be used to execute commands for which there is no equivalent GUI application. Although many operations could conceivably be performed using a GUI, it is usually easier to write a shell script than create a completely new GUI application.
Every time a user logs into a system, a shell is spawned. The type of shell spawned is determined by the default shell entry in /etc/passwd for the user concerned:
In this case, the apache user has the Bourne shell (/bin/sh) set as default. To be a valid login shell, /bin/sh must also be included in the shells database (stored in the file /etc/shells). The default system shell is the Bourne shell (/bin/sh). When a login shell is spawned, an initialization script is executed by the shell, which contains a series of commands that are executed sequentially—in addition to a number of environment variables being set. Each shell has its own initialization script; in the case of the Bourne shell, the initialization script is called .profile.
The .profile is typically located in the user’s home directory, although a system-wide /etc/profile script is also executed.