# Combinations

<< Previous Article

Continuing with our journey into recursive procedures, different ways of selecting “k” items from “n” distinct items is an another fascinating procedure. In mathematical terms, it is denoted by nCk (read as n C k), combinations of “k” items from “n” (distinct) items.

If it is to just compute the total number of such different combinations or selections possible, mathematics as usual readily provides the recursive relation and also the terminating condition:
nCk = n-1Ck + n-1Ck-1, n > k > 0 (recursive relation)
nCk = 1, for k = n, or k = 0 (the two extremes – terminating condition)
Note that, the implicit condition on which nCk is defined is n >= k >= 0.

A straight away functional recursive implementation would look like this:

```combinations(n, k)
{
if ((k == 0) || (k == n))
return 1;
else
return combinations(n - 1, k) + combinations(n - 1, k - 1);
}```

What about printing all the different possible selections of “k” items from “n” (distinct) items? Should be similar, as the recursive logic should still hold. Though, in the two terminating conditions, the interpretation would be slightly different. So as to say, for k = 0, i.e. selecting 0 items from “n” (distinct) items, the only way is selecting no items, and hence print nothing. However, for k = n, i.e. selecting “n” items from “n” (distinct) items, the only way is selecting all the items, and hence print everything. Additionally, the basket of “n” (distinct) items also need to be provided as an input to the procedure, say something like selections(n, k, basket[]). So, the procedure statement can be specified as follows: Implement a procedure selections(n, k, basket[]), which takes two numbers “n” & “k”, and a basket of “n” items and prints the nCk possible selections of “k” items from the “n” (distinct) items in the basket, one selection per line.

Now, with all the background set to implement selections(n, k, basket[]), let’s apply the usual trick of assuming the procedure selections() to be already existing for a lower order. What could be the lower order here? Two possibilities, as per the earlier mathematical recursive relation:

1. selections(n – 1, k, basket[] (with n – 1 items)), which prints the n – 1Ck possible selections of “k” items from the “n – 1” (distinct) items in the basket, one selection per line.
2. selections(n – 1, k – 1, basket[] (with n – 1 items)), which prints the n – 1Ck – 1 possible selections of “k – 1” items from the “n – 1” (distinct) items in the basket, one selection per line.

Now, how to make “n” items to “n – 1” items in selections(n, k, basket[]), so as to apply these two assumed procedures to implement the logic for “n” items? For that also, there are two possible ways, corresponding to the above two assumed procedures:

1. Assume that the first item in the basket is not part of the selection, and hence print n – 1Ck possible selections of “k” items from the remaining “n – 1” (distinct) items in the basket, one selection per line.
2. Assume that the first item in the basket is indeed part of the selection, and hence print n – 1Ck – 1 possible selections of “k – 1” items from the remaining “n – 1” (distinct) items in the basket, one selection per line, each prefixed by the first item in the basket.

Thus the recursive logic sounds straight forward, and it should be just a matter of invoking the two assumed procedures. However, before proceeding forward to implement, a little closer look, reveals that the second possible way of selections(n – 1, k – 1, basket[]), expects an additional requirement than what was assumed: “…, each prefixed by the first item in the basket”. And clearly the assumed procedure cannot do it (in the current state). One may think, that before the invocation of the second assumed selections(n – 1, k – 1, basket[]), the first item may be printed, so as to create the prefix of the output from the selections(n – 1, k – 1, basket[]). But think again, and the realisation will dawn that the output from selections(n – 1, k – 1, basket[]) outputs n – 1Ck – 1 lines (not just one), each of which need to be prefixed by the first item.

That sounds tricky. How to achieve the prefixing? What if the prefixing is to be assumed to be done by the selections() procedure itself. Yes. Why not? But then it calls for a change to the selections() procedure logic itself, and it would also need the prefix to be passed to it as an input. Okay then. Let’s redefine our procedure statement. Implement a procedure selections(n, k, basket[], plen, prefix[]), which takes two numbers “n” & “k”, a basket of “n” items, a prefix of “plen” items and prints the nCk possible selections of “k” items from the “n” (distinct) items in the basket, one selection per line, each prefixed by “plen” items in prefix.

And that calls for the reworking of the assumption of the procedure selections() to be already existing for a lower order, which would now be as follows:

1. selections(n – 1, k, basket[] (with n – 1 items), plen, prefix), which prints the n – 1Ck possible selections of “k” items from the “n – 1” (distinct) items in the basket, one selection per line, each prefixed by “plen” items in prefix.
2. selections(n – 1, k – 1, basket[] (with n – 1 items), plen, prefix), which prints the n – 1Ck – 1 possible selections of “k – 1” items from the “n – 1” (distinct) items in the basket, one selection per line, each prefixed by “plen” items in prefix.

Note that the lower ordering need not be applied to “plen” & prefix, as they are just the supporting parameters. In fact, they could be anything.

Now, these two assumed procedures can be accordingly applied as follows to implement the logic for selections(n, k, basket[], plen, prefix[]):

1. Assume that the first item in the basket is not part of the selection, and hence print n – 1Ck possible selections of “k” items from the remaining “n – 1” (distinct) items in the basket, one selection per line, each prefixed by “plen” items in prefix.
2. Assume that the first item in the basket is indeed part of the selection, and hence print n – 1Ck – 1 possible selections of “k – 1” items from the remaining “n – 1” (distinct) items in the basket, one selection per line, each prefixed by “plen” items in prefix and the first item in the basket. Doesn’t this first item still look to be an odd one out. Not really. Note that the first item in the basket can be made last item of the prefix, making it of length “plen + 1”, as those two parameters could be anything.

Cool. Also, both the terminating conditions, now need to print the prefix as well.

Hence, the final logic may be summarized as follows:

```selections(n, k, basket[], plen, prefix[])
{
if (k == 0)
{
print(plen, prefix);
print_nl(); // print new line
}
else if (k == n)
{
print(plen, prefix);
print_nl(); // print new line
}
else
{
selections(n - 1, k, basket + 1, plen, prefix);
selections(n - 1, k - 1, basket + 1, plen + 1, prefix);
}
}```

Okay. Recursive logic done. But now, what to pass for plen and prefix, when calling the selections(), at the topmost level? That is simple. At the topmost level, in printing of the nCk possible selections of “k” items from the “n” (distinct) items in the basket, one selection per line, there is no prefix required to be printed. So, pass “plen” as 0, and an empty prefix, capable of holding at max “k” items, as that would be the max prefix possible while selecting “k” items. And to make the toplevel call look beautiful, devoid of these seemingly redundant plen and prefix, a wrapper print_selections() could be provided as follows, which may also check for the invalid values of “n” & “k”, not satisfying n >= k >= 0 (if desired):

```print_selections(n, k, basket[])
{
plen = 0;
prefix[] = {}; // prefix being capable of supporting max "k" items

}
```

Note: The logic above would print the selections from right to left. What would you need to print it from left to right? Post your thoughts in the comments.

Next Article >>

# Tower of Brahma

<< Previous Article

After reverse printing a string recursively in our previous article, it is time to dive into more fascinating procedural recursion problems. And when talking about procedural recursion, how can one not talk about the famous “Tower of Brahma”, also referred as “Tower of Hanoi”. The puzzle comes from a story.

In the Kashi Vishwanath temple in India, there is a large room. It has three diamond poles, surrounded by 64 golden disks of decreasing radius from bottom to top. As the legend goes, when the Universe was created by Brahma, he created these disks and placed them all on one of the three poles in decreasing size from bottom to top. He then assigned the temple priests with the task of moving these disks from one pole to another, in accordance with the immutable rules of Brahma, since that time. The last move of the task which would move all the 64 disks to one of the other three poles would herald the end of the Universe. The rules to be followed are:

1. Only one disk should be moved at a time.
2. No bigger disk can be placed on a smaller disk.

In computation and logic, this puzzle is generalised to have n disks, and is referred to as “Tower of Hanoi”. For more technical information on the same, visit its Wiki Page.

Here is how to derive the recursive logic for the same. As discussed in the previous article, the first step is to have a very clear and precise statement of the procedure to be recursed. Puzzle Statement: Implement a procedure to move n disks from pole A to pole B, using an intermediate pole C, following the above two rules.

Now, the trick to derive the recursive relation logic is to assume the procedure to be already existing for a lower order, and then use it to achieve implementing the original higher order procedure. So here, assume the existence of the following: A procedure to move (n – 1) disks from pole X to pole Y, using an intermediate pole Z, following the above two rules. Again, note the similarity between this statement and the actual puzzle statement. And now use this to implement the original procedure. In original procedure, there are n disks, but a procedure is available only for (n – 1) disks. So, it can be visualised to be solved by breaking into the following steps:

• (First) Move the (top) (n – 1) disks from pole A to (the intermediate) pole C, using pole B as an intermediate pole, following the above two rules. (using the assumed available procedure)
• (Second) Move the largest single disk left on pole A to pole B.
• (Last) Move the (n – 1) disks from (the intermediate) pole C to pole B, using pole A as an intermediate pole, following the above two rules. (using the assumed available procedure)

Good. Now the terminating condition. That is again simple. If there is only one disk. Or, even simpler, when there is no disk, do nothing.

Here’s the summary of the above discussion:

```tob(n, A, B, C)
{
if (n == 0)
{
do_nothing;
}
else
{
tob(n - 1, A, C, B);
move(A, B); // move 1 disk from A to B
tob(n - 1, C, B, A);
}
}```

That’s all? Such an involved puzzle. Such a simple solution. Unbelievable, right? But that’s the beauty of recursion. Seemingly complex problems, and why seemingly? Real complex problems can be solved with elegant simplicity using recursion. That’s why it is the king of all kinds of logic – closest to the way our brain operates.

For implementing & checking the above logic, one may implement the move(X, Y) procedure with the corresponding programming language constructs / functions, and try it out. A simplest implementation of the same could be just printing the step, as follows:

```move(A, B)
{
print("Move 1 disk from ", A, " to ", B, ".\n");
}```

One may implement it in more hi-fi ways using graphics and what not, but the gist is the same – that the overall recursion logic remains the same.

Getting hooked into the world of elegant recursion? Keep reading as more secrets are unfolded.

Next Article >>

# Introduction to Procedural Recursion

<< Previous Article

Like the Mathematical or more specifically the Functional Recursion as discussed in the previous two articles, one can even have procedural recursion. A procedure doesn’t refer to any function as in mathematics, but rather a set of steps or actions. Procedural Recursion is when a procedure is defined recursively. i.e. in terms of itself. Even for a procedure to be defined recursively, the need is just the recursive relation (of lower order) and the terminating condition. But unlike in functional recursion, the luxury of mathematics to get the recursive relation is not there. Rather, some logic has to be applied to get it. However, here the terminating condition(s) are comparatively easier to figure out.

Let’s take an example of printing the numbers in reverse of the order in which they are being read from the input. Now, one can always implement it using an array (static allocation) and a loop, or may be a linked list (dynamic allocation) and a loop. However, it can be more elegantly implemented using recursion. In case of recursion, the stack is implicitly available for storage. So, there is neither a need for an array nor a linked list to implement it, but just a local variable, which could be recursively stored on the stack.

It is time to derive the recursive relation for the integer reversal. And for that, the first step is to have a very clear and precise statement of the problem / procedure to be recursed. Problem Statement: Implement a procedure to reverse print n integers being read from the input. Why n? To achieve the lower order.

Now, the trick to derive the recursive relation logic is to assume the procedure to be already existing for a lower order, and then use it to achieve implementing the original higher order procedure. So here, assume the existence of the following: A procedure to reverse print (n – 1) integers being read from the input. Note the similarity between this statement and the actual problem statement. And now use this to implement the original procedure. In original procedure, there are n integers available in the input and here there is a procedure available to reverse print (n – 1) integers being read from the input. Then, how can the n integers in the input be made to (n – 1) to be able to apply this available procedure. Simple, read one integer. And obviously, store it in a variable. And then apply the available procedure, which would print the remaining (n – 1) integers in reverse and then print the (first) stored integer – thus printing all the n integers in reverse.

Good. What about the terminating condition? That is simple. If there is only one character. Or, even simpler, when there is no input, do nothing.

Here’s the summary of the above discussion:

```reverse() // n
{
if (no_more_input)
{
do_nothing;
}
else
{
int i;

reverse(); // n - 1
print(i);
}
}```

Looks too trivial, right? And it is, once you get hang of it. Say for implementing & checking it, one may replace the read, print, … with the corresponding programming language constructs / functions and try it out.

Hold on your breath to dive deeper into the concept of procedural recursion and to be able to apply the assumption trick more confidently in deriving a procedural recursive logic.

Next Article >>

# Recursion with Trigonometry

<< Previous Article

Trigonometric functions like sine, cosine, … can all be computed recursively as well. As exponential in our previous article, the need is just the recursive relation and the terminating condition.

Recursive relation for sine(x) could be sine(x) = 2 * sine(x / 2) * cosine(x / 2) = 2 * sine(x / 2) * sqrt(1 – sine2(x / 2)). And accordingly, the terminating condition has to be derived for the limiting case when x is approaching zero, but not necessarily zero. And from world of limits, we have sine(x) = x for small x’s in radians. Also, on careful observation, the recursive relation has just one lower order x / 2, so the computation could be simplified as:

```v = sine(x / 2);
sine(x) = 2 * v * sqrt(1 - v2);```

Putting in the complete logic (say in C) would be as follows:

```#define DELTA 0.001 // Depends on the desired accuracy

double sine(double x)
{
if (fabs(x) < DELTA) // Terminating Condition
return x;
else
{
double v = sine(x / 2);
return 2 * v * sqrt(1 - v * v);
}
}```

Similarly, cosine(x) could be recursively defined as 2 * cosine2(x / 2) – 1 with terminating condition of 1 – x2 / 2. And similarly all others.

Moreover, why only trigonometric functions, but all kind of mathematical functions having some recursive relation (with a terminating condition) can be computed using recursion.

And why only mathematical functions, but even procedural logic could be computed using recursion. Watch out for the same …

Next Article >>

# Deriving the Functional Recursion

Recursion is the method of recurring aka repeating. In computer science, recursion refers to logic that invokes or uses itself. Its implementation is typically done using a function or procedure calling itself, called the recursive function or recursive procedure.

From an outlook, in a recursive logic, it looks as if this calling chain would then never end. However, in the actual logic, it is typically accompanied by one or more terminating condition(s). So in general, a recursive logic is defined as a combination of recursive relation and terminating condition(s).

A recursive relation is a relation (definition, equation, …) for some thing (logic) in terms of itself, but typically of lower order. Let’s take a common mathematical example of factorial. n! = n * (n – 1)!. In this, factorial of n is defined as a product of n and again factorial of (n – 1). Note the lowering of n to (n – 1).

According to this lowering, one can observe, as where will it end, and accordingly setup the terminating condition. In the factorial case above, n being a whole number, and it being decremented by 1, will end at 0. So, a terminating condition can be put for factorial of 0, namely 0! = 1.

For mathematical functions, it is fairly easy to obtain a recursive relation, as complete mathematics is there to help. Though deriving termination condition(s) may be at times tricky. Let’s take another example of Fibonacci numbers. n‘th Fibonacci number is defined as F(n) = F(n – 1) + F(n – 2). Both (n – 1) and (n – 2) being of lower order. However, now there are two different lower orders, and that calls for two terminating conditions, namely F(1) = 1, F(0) = 0.

Both the above examples were for whole numbers. So, the terminating condition was still easily understandable. However, it can get further tricky, while working with say real numbers. Let’s take an example of exponential e^x. Now, if it is defined recursively as ex = e * e(x – 1), its terminating condition would no way become a single point – do not forget x is a real number. For non-negative x, it may terminate somewhere in the range [0, 1) of infinite numbers. However for negative x, there is no visible termination condition itself. That calls for a better recursive relation of some other lower ordering.

Till now, lower ordering was being thought of as subtraction, which worked well for whole numbers, but seemingly not for real numbers. So, why not lowering the order using repeated subtraction, or so called division? Interestingly, it turns out that for real numbers that is a better bet. So, let’s define exponential recursively as ex = e(x / 2) * e(x / 2) – the lower orders being (x / 2) and (x / 2). And both being same, they may be merged as follows: (e(x / 2))2. Now, the terminating condition doesn’t diverge for whatever value of x. However, one may not still confuse it to be ending at a single point 0. Observe carefully that it heads towards 0, closer and closer but may never end up at 0, except for the initial value of 0. In fact, it has a terminating condition over a range (- delta, delta), where delta could be chosen as an arbitrarily small positive value based on the desired precision of the final result. But then, how to define the terminating value of ex over a range. That’s not very difficult – world of limiting approximations could provide a rescue for it, as whatever the value obtained for ex be, it will be an approximation only. ex is known to have a series expansion of 1 + x + x2 / 2 + … If delta is taken small enough, higher powers of x can be ignored. Thus, ex = 1 + x, would be the terminating condition for x within (- delta, delta). Note that ex could not be just 1, as that would then not represent the range, rather just the point 0.

Yes. With this, a recursive logic for exponential ex has been derived. Unbelievable. Go ahead & write a program using the derived recursive relation and terminating condition to verify it. And it is not just a fluke lone case – it is a norm – can be tried with any function with a recursive relation. Trigonometric functions like sine, cosine, … can be tried next.

Next Article >>

# Task on a particular CPU

In today’s world of multi-CPUs, a fundamental question arises as on which of the multiple CPUs does the various tasks (processes and threads) in Linux run / execute? Is it all on one, or distributed over all? If distributed over all, how is the distribution decided? Can the tasks dynamically change the CPU? and so on.

As understood above, by default, all tasks are free to run on all enabled CPUs, and that is specified by a CPU bitmask corresponding to all CPUs. Say, there are 4 CPUs on a system. Then, the all CPU bitmask would be hexadecimal “f”.

Number of CPUs on a system can be checked as follows:

`\$ grep "^processor" /proc/cpuinfo | wc -l`

Current CPU affinity bitmask of a specific process, say the init / systemd (pid 1) can be obtained as follows:

`\$ taskset -p 1`

Current CPU affinity bitmask for the current shell can be checked as follows:

`\$ taskset -p \$\$`

But out of the list of CPUs, specified by the bitmask, how do one know, on which CPU is the specific task currently running on? For that, one may run “top” with the corresponding pid and add the “Last used CPU” column to “top” after pressing “f” key. For the current shell, it may be run as:

`\$ top -p \$\$`

And then, press “f”. Go to “Last used CPU” by pressing down arrow. Select it by pressing “Space” bar. Come back by pressing “Esc”. Now, the last column in “top” labelled by “P”, tells the processor number, the corresponding task is running on. Without the “-p” option to “top”, it would show for all the top actively running processes. And one may observe the switching of the various tasks between various CPUs.

Now let’s fix one of the tasks to a particular CPU, say for the web browser task. Note down its pid using “ps ax”. Say it is <pid>. And then, run the “top” for this <pid> and with its CPU details as mentioned above. Observe its current CPU change frequently, or even if it is fixed on say 0th CPU. To fix / change its CPU to say 1st, give the following command on an another shell:

`\$ taskset -p 0x2 <pid>`

Observe the CPU in the “top” getting fixed to 1. That’s all.

In fact, if fixing of the CPU is desired for a command to be run from a shell, it can be done while starting the command itself. As an example:

`\$ taskset 0x3 ls -l`

would run the “ls” command between CPUs 0 & 1. For more details, checkout:

`\$ man taskset`

*NB that CPU 0 is always enabled. And for others, they are enabled if /sys/bus/cpu/devices/cpu<cpu_no>/online is set to 1.

# Self-extracting Shell Script

Self-extracting executables are a commonplace in Windows. Can it be or something like it be created in Linux, as well? If the question is CAN it be done for Linux, the answer to most “can” questions in open source world is a “yes”. But one does not need to be a copycat of Windows, when better things can be done in Linux – a self-extracting Shell Script.

For that, we just need to write a shell script, say generate_self_extracting_shell_script.sh. This script will take the directory to be self-extracted and output the self-extracting shell script. But how does this self-extracting shell script work? Basically, there are two parts in this script: 1) the bottom one containing the compressed tar of the directory to be self-extracted, and 2) the top one containing the shell script to extract the bottom part. So, when one runs this shell script, it would run the top part extracting the bottom part. These two parts are demarcated by a unique marker for the top part to identify its bottom. Here is how a typical self-extracting shell script will look like with TGZ_CONTENT as the unique marker:

```#!/bin/bash

echo -n "Extracting script contents ... "
start_line_of_tar=\$((`grep -an "^TGZ_CONTENT\$" \$0 | cut -d: -f1` + 1))
tail -n+\${start_line_of_tar} \$0 | tar zxf -
echo "done"
exit 0
TGZ_CONTENT
<compressed_tar_of_the_directory_goes_here>
```

The grep-cut pair extracts the line number of this script having TGZ_CONTENT, and then 1 is added to it to get the start_line_of_tar. Then, tail-tar pair extracts the tar, starting from start_line_of_tar till the end of the shell script file. The “exit 0” is important to stop the script execution after its top part is executed, as the bottom part is not really a script.

Now, here’s the script generate_self_extracting_shell_script.sh to generate the above self-extracting shell script:

```#!/bin/bash

if [ \$# -ne 2 ]
then
echo "Usage: \$0 <directory_to_package> <self_extracting_script_file>"
exit 1
fi

directory=\$1
script=\$2

cat > \${script} <<SCRIPT_TOP
#!/bin/bash

echo -n "Extracting script contents ... "
start_line_of_tar=\\$((\`grep -an "^TGZ_CONTENT\$" \\$0 | cut -d: -f1\` + 1))
tail -n+\\${start_line_of_tar} \\$0 | tar zxf -
echo "done"
exit 0
TGZ_CONTENT
SCRIPT_TOP
tar zcf - \${directory} >> \${script}

chmod +x \${script}
```

The two SCRIPT_TOP above are the delimiters for here-document (content from here) to be put into the generated shell script file. The tar line after that is to add the bottom content of the script. Notice the \ before the \$ in the here-document, so as to not evaluate those in this script, but output verbatim into the self-extracting shell script.

Assuming an existing directory XYZ to be packaged into the self-extracting shell script xyz.sh, this script could be run as follows:

`\$ ./generate_self_extracting_shell_script.sh XYZ xyz.sh`

And running the xyz.sh shell script would extract back the XYZ directory, thus xyz.sh becoming a self-extracting shell script.

# Controlling Shell Commands through C

With the ever growing presence of embedded systems, it has become a very common requirement to do some tasks through shell commands while doing others through C in an embedded system. Very often people achieve this by using system() C library function, which is known for its inefficiencies and limitations. So, is there a better way to achieve it? Yes. The main C (commander) program may spawn a master shell script process, which would then keep on accepting & executing shell commands from the commander program. Here are the two components (a main C program and a master script) of the framework, put out:

/* File: commander.c */

```#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>

int main(char argc, char *argv[])
{
int pfds; // 0 is read end, 1 is write end
int wfd;
pid_t pid;
char cmd;
int cmdlen;
int stop, status;

if (pipe(pfds) == -1)
{
perror(argv);
return 1;
}

pid = fork();
if (pid == -1)
{
perror(argv);
return 2;
}
else if (pid != 0) // Parent
{
close(pfds); // Close the read end of the pipe
wfd = pfds;
// Continue doing other stuff, e.g.
// take commands from user and pass onto the master script
stop = 0;
do
{
printf("Cmd (type \"done\" to exit): ");
if ((status = scanf("%[^\n]", cmd)) <= 0)
{
getchar(); // Remove the \n
continue;
}
getchar(); // Remove the \n
if (strcmp(cmd, "done") == 0)
{
stop = 1;
}
else
{
cmdlen = strlen(cmd);
cmd[cmdlen++] = '\n';
//cmd[cmdlen] = '\0';
// Pass on the command to master script
write(wfd, cmd, cmdlen);
}
}
while (!stop);
close(wfd);
}
else
{
close(pfds); // Close the write end of the pipe
dup2(pfds, 0); // Make stdin the read end of the pipe
if (execl("./master_script.sh", "master_script.sh", (char *)(NULL))
== -1)
{
perror("Master script process spawn failed");
}
}

return 0;
}
```

# File: master_script.sh

```#!/bin/bash

do
#echo "Running \${cmd} ..."
\${cmd}
done
```

One may compile the commander.c and try it as follows:

```\$ gcc commander.c -o commander
\$ ./commander
```

This approach becomes even more powerful, when the shell command execution is pretty often. Also note that the main thread need not block for the command execution to complete. Though, it can be customized to block as well, if required. And many more customizations can be achieved as desired, e.g. getting the command output back into the C program instead of stdout, redirecting the command error into some log file instead of stderr, getting the command status – to list a few. Post your comments below to discuss any customizations of your interest.

# Types of Shell Commands

Everyone, who has been a Linux user, must have typed various commands on shell, or the so-called shell commands, knowingly or unknowingly – at least the ubiquitous command “ls”. However, have one wondered, how one gets these commands?

A command which one types on shell is broadly available from one of the following three places:

• An executable from some standard path in the file system
• A built-in of the shell, available from the shell’s binary itself
• An alias or function created by the shell

“ls” – every Linux users’ typical first command, basically comes from the “ls” executable located under /bin. And so are many more commands. All such commands come from one of the directories like /bin, /usr/bin, /sbin, etc. The complete list of such directories can be obtained from the PATH environment variable by typing:

`\$ echo \${PATH}`

Typing this as a normal user would show the list of directories for commands available to a normal user. And typing it as a root user would show the list of directories for commands available to root user. Moreover, one could add directories to the corresponding PATH variable as well, using “export” command.

Given a command available from executable, e.g. “ls”, one may find its directory using the “which” command as follows:

`\$ which ls`

What about the “which” command itself? Try:

`\$ which which`

What about the “cd” command? Try:

`\$ which cd`

And you’ll get a message saying no cd in the path. But then, cd still works, right? Just type:

`\$ type cd`

And it would show that it is a shell built-in – the second type of the command types. And, it makes sense to be a built-in as well, as meaning of current working directory (the concept around “cd”) is relevant only with respect to a shell. What about the “type” command, itself? Any guess? Try:

`\$ type type`

Yes, as expected, this is also a shell built-in. What about the “which” command? Try:

`\$ type which`

And it shows, as expected, that it is an executable being picked up from a corresponding hashed directory. What about the “ls” command? Try:

`\$ type ls`

Ouch! This is not as expected. It doesn’t show “ls” as an executable from a corresponding directory, but rather that “ls” is aliased to some string like “ls -F –color=auto” or so. Why is it so? Because the “ls” command we type, is actually an alias to the “ls” executable (with the specific colour options) – the third type of command types. And, that’s why we see coloured listing by default when we type “ls”. One can create aliases using the “alias” command, which itself is a shell built-in, as expected. And aliases override commands from the actual executables.

What if one wants to bypass the alias and directly call the executable? The command with the complete executable path, e.g. “/bin/ls”, may be invoked, or it may be backslashed, as follows:

`\$ \ls`

Observe the non-coloured output of the original “ls” executable.

So to conclude, “type” command gives the actual type (out of the three types) for any command we type on shell. “which” command is to figure out the directory of its corresponding executable, if any. And “alias” command would list out all the aliases currently defined under the corresponding shell.

On a side note, “man” command typically provides help on the shell’s executable commands only. For a built-in command, it may just open up the man page of the shell itself. So, for specific help on built-in commands, you may use the “help” command, e.g.:

`\$ help cd`

Parting question: Which type of command is “help”? Try out the various commands on it and have fun exploring the types of shell commands.

# Running DOS programs on Linux

Lot of people from DOS days must have played & enjoyed those DOS games. And today those don’t always play or not play straight away on Windows. And so, the newer generation might have heard about them, but never got a first hand experience. Moreover, today there are more Linux users than ever. Ya ya, on Linux, people have been using wine for Windows emulation of the executables, but not always straight forward for the graphics part. So, for the DOS game lovers, or for that matter for executing any DOS program to get that antique feeling, there is a simpler elegant way. It is using dosbox, which is available in various Linux distros. Just install it as a package. And run with the command dosbox.

And DOS would so-called boot and give the DOS prompt with Z:\ drive as system drive. Then, it is all DOS in that dosbox window. Now, how to run external DOS executables? Assuming they are available in some folder under Linux, say ~/DOS. That could be mounted in the dosbox, by the following command:

`Z:\>mount c ~/DOS`

With this, the ~/DOS folder from Linux is mounted as C:\ drive in dosbox. And now the various DOS things are applicable to it. One may switch to it by typing the drive, as follows:

`Z:\>C:`

If it has game executables, compiler executables, … from DOS days, those can be run by just typing them as the executable with complete path, as was to be done in those DOS days. Just remember that the directory separator slash used in DOS is backslash (\) like in Windows and unlike in Linux. And front slash (/) is used for command options.

To get a list and help on the default available (DOS) commands, type:

`C:\>help /all`

And finally to exit from the dosbox:

`C:\>exit`