lostecho/ostep-projects
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Polishing shell spec

Browse Source
This commit is contained in:
Remzi Arpaci-Dusseau
2018-02-05 10:54:59 -06:00
parent 271c1346eb
commit 944f2c6252
1 changed files with 26 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
processes-shell/README.md
View File

@@ -35,7 +35,10 @@ basically an interactive loop: it repeatedly prints a prompt `wish> ` (note
the space after the greater-than sign), parses the input, executes the command the space after the greater-than sign), parses the input, executes the command
specified on that line of input, and waits for the command to finish. This is specified on that line of input, and waits for the command to finish. This is
repeated until the user types `exit`. The name of your final executable repeated until the user types `exit`. The name of your final executable
should be `wish`: should be `wish`.
The shell can be invoked with either no arguments or a single argument;
anything else is an error. Here is the no-argument way:
``` ```
prompt> ./wish prompt> ./wish
@@ -53,13 +56,13 @@ run the shell with a batch file named `batch.txt`:
prompt> ./wish batch.txt prompt> ./wish batch.txt
``` ```
You should structure your shell such that it creates a new process for each You should structure your shell such that it creates a process for each new
new command (the exception are *built-in commands*, discussed below). Your command (the exception are *built-in commands*, discussed below). Your basic
basic shell should be able to parse a command and run the program shell should be able to parse a command and run the program corresponding to
corresponding to the command. For example, if the user types `ls -la /tmp`, the command. For example, if the user types `ls -la /tmp`, your shell should
your shell should run the program `/bin/ls` with the given arguments `-la` and run the program `/bin/ls` with the given arguments `-la` and `/tmp` (how does
`/tmp` (how does the shell know to run `/bin/ls`? It's something called the the shell know to run `/bin/ls`? It's something called the shell **path**;
shell **path**; more on this below). more on this below).
## Structure ## Structure
@@ -195,10 +198,11 @@ above.
There is a difference between errors that your shell catches and those that There is a difference between errors that your shell catches and those that
the program catches. Your shell should catch all the syntax errors specified the program catches. Your shell should catch all the syntax errors specified
in this project page. If the syntax of the command looks perfect, you simply in this project page. If the syntax of the command looks perfect, you simply
run the specified program. If there is any program-related errors (e.g., run the specified program. If there are any program-related errors (e.g.,
invalid arguments to `ls` when you run it, for example), let the program invalid arguments to `ls` when you run it, for example), the shell does not
prints its specific error messages in any manner it desires (e.g., could be have to worry about that (rather, the program will print its own error
stdout or stderr). messages and exit).
### Miscellaneous Hints ### Miscellaneous Hints
@@ -222,15 +226,15 @@ work. This will often catch errors in how you are invoking these new system
calls. It's also just good programming sense. calls. It's also just good programming sense.
Beat up your own code! You are the best (and in this case, the only) tester of Beat up your own code! You are the best (and in this case, the only) tester of
this code. Throw lots of junk at it and make sure the shell behaves well. Good this code. Throw lots of different inputs at it and make sure the shell
code comes through testing -- you must run all sorts of different tests to behaves well. Good code comes through testing; you must run many different
make sure things work as desired. Don't be gentle -- other users certainly tests to make sure things work as desired. Don't be gentle -- other users
won't be. Break it now so we don't have to break it later. certainly won't be.
Keep versions of your code. More advanced programmers will use a source Finally, keep versions of your code. More advanced programmers will use a
control system such as git. Minimally, when you get a piece of functionality source control system such as git. Minimally, when you get a piece of
working, make a copy of your .c file (perhaps a subdirectory with a version functionality working, make a copy of your .c file (perhaps a subdirectory
number, such as v1, v2, etc.). By keeping older, working versions around, you with a version number, such as v1, v2, etc.). By keeping older, working
can comfortably work on adding new functionality, safe in the knowledge you versions around, you can comfortably work on adding new functionality, safe in
can always go back to an older, working version if need be. the knowledge you can always go back to an older, working version if need be.