README.html: Added assignment details as README

1 files changed, 65 insertions, 0 deletions

diff --git a/README.html b/README.html
new file mode 100644
index 0000000..0d52134
--- /dev/null
+++ b/README.html
@@ -0,0 +1,65 @@
+<p>For this assignment, you will be writing a program called&nbsp;<strong>hush</strong>, the HU Shell. This program will read commands from stdin and execute them, much like the <strong>bash </strong>shell that you've been using on the server so far. Of course, your shell will be a lot simpler than bash and we'll make several assumptions to ease your implementation.</p>
+<h2>Required Features</h2>
+<p>The required features of your shell are as follows,</p>
+<ol style="list-style-type: decimal;">
+    <li>Your shell should be interactive. When launched, present the user with a prompt of the form,<br />$&nbsp;<br />and all them to type a command immediately following the sigil,<br />$ ls</li>
+    <li>When the user hits enter, parse the command they entered and execute it. Fork a process to do so.</li>
+    <li>Your shell should support redirecting stdout and stdin. If the user doesn't specify an input or output file, the forked process should inherit them from the shell itself. However, the user can specify an output file like,<br />$ ls &gt; output.txt<br />or an input file like<br />$ cat &lt; input.txt<br />and your shell should create/open these files and set up stdin/stdout for the new process accordingly.</li>
+    <li>Your shell should support basic variables.&nbsp;
+        <ol style="list-style-type: decimal;">
+            <li>Allow the user to create a variable using the following syntax<br />$ myvar=test<br />Note the lack of spaces.</li>
+            <li>In a command string, a $ preceding a name should cause the shell to replace that name with the value associated with that name, or with an empty string if it isn't been defined. For example,<br />$ myvar=test.txt<br />$ cat $myvar<br />should execute the command<br />$ cat test.txt</li>
+        </ol>
+    </li>
+    <li>Your shell should have the following built-in commands
+        <ol style="list-style-type: decimal;">
+            <li>export&nbsp;<em>varname</em>
+                <ol style="list-style-type: decimal;">
+                    <li>If&nbsp;<em>varname </em>is a variable, remove it from the local variable store and create an environment variable with the same name and value</li>
+                </ol>
+            </li>
+            <li>cd&nbsp;<em>dirname</em>
+                <ol style="list-style-type: decimal;">
+                    <li>Update the shell's working directory to&nbsp;<em>dirname</em></li>
+                </ol>
+            </li>
+            <li>pwd
+                <ol style="list-style-type: decimal;">
+                    <li>Write the current working directory of the shell to stdout</li>
+                </ol>
+            </li>
+            <li>exit
+                <ol style="list-style-type: decimal;">
+                    <li>Calls exit(EXIT_SUCCESS) to close the shell session</li>
+                </ol>
+            </li>
+        </ol>
+    </li>
+    <li>Pipes
+        <ol style="list-style-type: decimal;">
+            <li>Your shell should have support for command pipelines, using the character |<br />$ command1 | command2 | command 3<br />should execute all three commands, with pipes created between them.</li>
+        </ol>
+    </li>
+</ol>
+<h2>Simplifying Assumptions</h2>
+<p>You may make the following simplifications to standard POSIX shell semantics</p>
+<ol style="list-style-type: decimal;">
+    <li>Assume that&nbsp;all tokens are whitespace delimited. You do not need to handle quoting or escaping spaces. This means that it will be impossible to interact with files or commands that have spaces in their names, and variable values cannot contain spaces either.</li>
+    <li>A space is required before and after a pipe or I/O redirection operator. In other words, it will always look like,<br />$ ls &gt; test.txt<br />and never<br />$ ls &gt;test.txt<br />etc.</li>
+    <li>You do not need to implement or handling globbing/wildcard expansion.</li>
+    <li>Your shell shouldn't crash when an invalid command is provided, but you do not need to provide detailed error messages about what went wrong.</li>
+    <li>All commands a newline terminated--you do not need to handle multiple commands on a single line, or spreading a single command over multiple lines</li>
+    <li>You do not need to support redirection of stderr.</li>
+    <li>A variable cannot be used as a command. In other words, the following is invalid<br />$ cmd=ls<br />$ $cmd</li>
+    <li>You do not need to implement multi-tasking. There are no background jobs--all processes run in the foreground.&nbsp;</li>
+    <li>You may assume that a command will have no more than 8 arguments.</li>
+    <li>You do not need to support executing commands that are not on the PATH. In other words, you don't need to support running a command like,<br />$ ./a.out<br />where a.out is in the working directory, but not on the path.</li>
+    <li>You may assume that commands, arguments, filenames, etc., are purely alphanumeric. Thus, if you see an = it will&nbsp;<em>always</em> mean variable assignment, and &lt;, &gt;, | will always be I/O redirections, etc.</li>
+    <li>You may assume that commands are no longer than 1023 characters.</li>
+</ol>
+<h2>Hints</h2>
+<ul>
+    <li>Consider using the strsep(3) function for parsing command strings.&nbsp;</li>
+    <li>When reading the man page for strsep, look for a "SEE ALSO" section. This may contain other functions you may find useful for this project.</li>
+    <li>The hash table you wrote in Project 1 might be useful here</li>
+</ul>