What happens when you type ls -l in the shell?

Sebastian Obando Perez — Hector Orozco

What is the ls command?

The ls command is a command-line utility for listing the contents of a directory or directories given to it via standard input. It writes results to standard output. The ls command supports showing a variety of information about files, sorting on a range of options and recursive listing.

How to show the contents of a directory?

To show the contents of a directory pass the directory name to the ls command. This will list the contents of the directory in alphabetical order. If your terminal supports colours you may see that file and directory listings are a different colour.

How to show a long listing?

To show a long listing pass the -l option to the ls command. This will output detailed information on the directory listing.

https://shapeshed.com/unix-ls/#how-to-append-file-types-to-listings

What happens when you execute ‘’ls-l’’ in Bash?

1. Bash as command interpreter checks whether there such special words in it’s own language: shell keywords or shell built-ins.
2. ls isn’t among shell keywords, then it checks aliases and replace alias with it’s value, most likely there should be something like that: ls=’ls — color=auto’
3. it looks for ls executable in paths specified by PATH env variable. Usually it’s /bin/ls
4. It forks (fork()) new process and execs it’s code (exec()). Process env is inherited from parent process to new “ls” process.
5. New process becomes session leader and starts working on foreground (bash is moved to background)
6. ls process loads shared libraries from LD_PATHs (ldd /bin/ls)
7. it executes lots of system calls, you can check by strace, and the main part I believe are openat() and getdents() first opens directory and second reads entries inside there.
8. prints output and exits, sends wait() signal and parent process bash terminates it completely.

What happens when you execute "ls" in Bash

Notice that the standard output of the ls activation is fed into grep’s standard input. grep and ls actually execute concurrently — — ls will execute for a while and produce a “chunk” of output, which will be fed to grep, which will process that “chunk” and then wait for ls to feed it more. Eventually, ls will stop running; grep will stop after finishing the last chunk that ls sends to it.

Activations of ls and grep in pipeline, with shell and terminal processes shown for completeness.

https://courses.cs.washington.edu/courses/cse341/04wi/lectures/24-ruby-scripting.html

Command-Line Options

Unix tradition encourages the use of command-line switches to control programs, so that options can be specified from scripts. This is especially important for programs that function as pipes or filters. Three conventions for how to distinguish command-line options from ordinary arguments exist; the original Unix style, the GNU style, and the X toolkit style.

In the original Unix tradition, command-line options are single letters preceded by a single hyphen. Mode-flag options that do not take following arguments can be ganged together; thus, if -a and -b are mode options, -ab or -ba is also correct and enables both. The argument to an option, if any, follows it (optionally separated by whitespace). In this style, lowercase options are preferred to uppercase. When you use uppercase options, it’s good form for them to be special variants of the lowercase option.

The original Unix style evolved on slow ASR-33 teletypes that made terseness a virtue; thus the single-letter options. Holding down the shift key required actual effort; thus the preference for lower case, and the use of “-” (rather than the perhaps more logical “+”) to enable options.

The GNU style uses option keywords (rather than keyword letters) preceded by two hyphens. It evolved years later when some of the rather elaborate GNU utilities began to run out of single-letter option keys (this constituted a patch for the symptom, not a cure for the underlying disease). It remains popular because GNU options are easier to read than the alphabet soup of older styles. GNU-style options cannot be ganged together without separating whitespace. An option argument (if any) can be separated by either whitespace or a single “=” (equal sign) character.

http://www.catb.org/~esr/writings/taoup/html/ch10s05.html

Steps to Command Execution

After a command is typed at the command line and the enter key is pressed, the shell goes through the following steps to execute the command.

• The string of text that makes up the command, including options and arguments, is broken up into words based on where spaces are in the command text. The first word of the command text is considered the command name and the remaining words will be used as options and arguments.
• If the command contains one or more slashes, the shell executes the command based on the path described in the command providing the options and arguments described in the remaining words. Steps 3, 4 and 5 will be skipped.
• If the command does not contain slashes, the shell checks to see if an alias is defined that matches the command name. If a matching alias is found, the value of the alias is substituted for the command line.
• The shell checks through its library of shell built-in commands. These are commands that are part of the functionality of the shell itself, as opposed to part of the operating system or software that has been added on. As an example, the history command covered in the last chapter is a command built into the shell, whereas the ls command is not. If a built-in is found, it is executed with the options and arguments given in the remaining words and Step 5 is skipped.
• The shell searches through the directories described in the PATH environment variable for a program matching the command name given. If one is found, it is executed with the options and arguments given in the remaining words.

This is a lot to digest, but it can be very useful in understanding how things are executed at the command line.

http://www.dba-oracle.com/t_linux_command_execution_steps.htm

The pipe is an in-memory buffer that connects two processes together. file descriptors point to the pipe object, which buffers data sent to it (via a write) to be drained (via a read).

The Shell

The shell is the gateway to interacting with the operating system. Be it bash, zsh, csh or any of the many other shells, they all fundamentally have only one major task — to allow you to execute programs (you will begin to understand how the shell actually does this when we talk about some of the internals of the operating system later).

But shells do much more than allow you to simply execute a program. They have powerful abilities to redirect files, allow you to execute multiple programs simultaneously and script complete programs. These all come back to the everything is a file idiom.

Redirection

For example, you may wish to capture all the output of a program into a file on disk or, alternatively, have it read its commands from a file you prepared earlier. Another useful task might like to pass the output of one program to the input of another. With the operating system, the shell facilitates all this and more.

Implementing pipe

The implementation of ls | more is just another example of the power of abstraction. What fundamentally happens here is that instead of associating the file descriptor for the standard-output with some sort of underlying device (such as the console, for output to the terminal), the descriptor is pointed to an in-memory buffer provided by the kernel commonly termed a pipe. The trick here is that another process can associate its standard input with the other side of this same buffer and effectively consume the output of the other process.

https://www.bottomupcs.com/file_descriptors.xhtml

https://stackoverflow.com/questions/12920976/which-linux-system-call-is-used-by-ls-command-in-linux-to-display-the-folder-fil

Blog tasks for Holberton School

created by:

Sebastian Obando Perez 1869@holbertonschool.com

Hector Orozco 2066@holbertonschool.com

August 15 2020