Future C Shell Work: Code developed in a series of stages:

write and test a parser to read the command lines--this works
get the simple commands to work--this works
get I/O redirection to work--this works
get pipes to work--this works for some cases but not with 2nd command sent to an output file instead of stdout
get "&" to work--not implemented yet
Parsing shell strings: in this project, you only need to implement a simple command line parser, in which we use "space" as the delimiter between command "tokens".--this works
You can use support libraries such as the Gnu readline library for command line parsing.
A multi-process version of the traveling salesman problem, called tsp_p--future work.
A multi-threaded version of the traveling problem, called tsp_t, with an added bonus of implementing it without the SYSV context functions. Solutions that bind user level threads with kernel threads are also a bonus, and using pthreads or any other threads library is not the approach to take, and instead, you create your own threads. It was also recommended NOT to rely on the Linux clone() call in the thread creation solution, if at all. The solution can bind user level threads onto user level threads, but you still need to use a different approach for making the portable user--level threads--future work.
A sorter program, called tspsort, that sorts the paths found in the traveling salesman problem, from shortest path to longest path distance--future--work.

Testing Involved In Future Work:

In myshell, run tsp_p < input_graph | tspsort > tsp_p.out”

tsp_p computes all possible paths through a graph (G) of vertices (V) and edges (E).

A path is defined as an ordered list of nodes from a starting point, S, visiting all other nodes in V exactly once, and then returning back to S.
a path distance is defined as the sum of all edge weights between pairs of nodes in G visited along a specific path each path along the route with its overall distance will be the output to stdout by tsp_p as it is discovered the result is piped by “myshell” to stdin of tspsort, which collects all paths and orders them from shortest to longest distance
In myshell, run tsp_t < input_graph | tspsort > tsp_t.out, with the same goals with the thread version as above with the process version

Traveling Salesman Multi-Process Version--Future Work:

Problem: The problem to be addressed is a parallel implementation of the Travelling Salesman Problem (TSP) on an input graph, G={V,E}, comprising a set of nodes or vertices, V, and a set of edges, E. Your main program (called tsp_p) is to be invoked as follows: $ tsp_p
It then reads an input graph from stdin. You can assume the input graph, G has |V|=n vertices representing different cities.
The graph itself can be represented as an n*n distance matrix, D,such that D[i,j] is the distance between city i and city j.
The diagonal of the matrix has distance 0 for each D[i,i] . You can assume all distances are in integers over some predefined range [0..MAX_DISTANCE] and the number of cities, n, is limited to a maximum value MAX_NODES.
Code in future work will be tested on values of n not much above single digits but code will be designed to be as efficient as possible, so that it can scale to large input graphs.
Not all cities need to have a direct path between them. In this case you can assume there is no edge connecting them. In the input graph you can assume a value for D[i,j] = 1 if there is no edge directly connecting cities/nodes i and j.
For all pairs of cities with direct paths, or edges between them, then your distance matrix must contain a valid value. You can assume MAX_DISTANCE is set to 255.
For each node in G, you should consider it the starting point of all possible paths to all other nodes. You should create a separate process (n in total) for each starting node and compute all paths from that starting point to all other nodes and back again to the starting point.
The output of tsp_p is a list of paths along with overall distance
A path is defined as an ordered sequence of nodes, from a starting point S visiting all other nodes exactly once and then returning back to S.
The paths should be output along with their distances to stdout.

The Big Picture of the Multi-process, Traveling Salesman Problem:

The first step is for the parent process to the input graph from stdin, and perform appropriate error checks, to verify its correctness.
The parent process then creates a shared memory segment which is big enough for communications between parent and child processes. Using the "fork" syscall, the parent creates n child processes.
A child process uses one of the exec functions to map a program file called "find_paths" into its address space.
The "find_paths" program will take a starting node, S, in the input graph and calculate the distances of all possible paths from that node to all other nodes and back again to S. Aside from S, all other nodes along a valid path should only be visited once.
The parent process waits until all of the child processes have finished, and then outputs the resultant set of paths and their distances stdout.
Each child will send back its paths to the parent via shared memory. You need to establish sufficiently large shared memory between each child and the parent. This memory region does not need to be big enough to store all paths but could instead form a communication channel to exchange paths as they are produced.
Note that each process has a unique starting point. Since there are n possible nodes (or cities in the input graph) then each of the n child processes has a different one of these nodes as its starting point.

Traveling Salesman, Multi-threaded Version:

Problem: The problem to be addressed is the same as in "tsp_p", except you will use multiple threads to calculate paths through a graph instead of separate child processes. Your multithreaded program should be called "tsp_t".

The Big Picture of the Multi-threaded traveling salesman version: