代写一个类似Shell功能的命令行工具，第二部分主要是处理可执行部分，调用Linux现有的命令工具。
Part II: Executables
Now that sfish has builtin support, it’s time to give it the ability to run
any executable like ls, grep, and wc. If you have implemented this part of
your shell correctly, you should be able to run your HW1 and HW2 assignments
within your shell.
Helpful and allowed interfaces
You will have to parse the command line using readline(3) and then use fork(2)
and exec(3) (or flavors of exec , such as exece, execle, etc.) to launch
programs. Programs you run should take input from stdin and output to stdout
and stderr (errors). You will have to study the wait(2) (and flavors of wait
such as waitpid ) system call in order for your shell to return the proper
status codes. You may use any system call (section 2 of the man pages) or
library call (section 3 of the man pages) for this assignment, EXCEPT for
system(3) .
By convention, the name of the binary is the first argument provided to a
program. Check the manual of the exec variant you are using to determine
whether or not you should put the binary name in the argument list.
In general, your selection of libraries is unrestricted, with one important
exception: you should NEVER use the function system or the library termios ,
which are really just wrappers for another shell. Speaking more broadly, it is
not acceptable to simply write a wrapper for another shell-you should
implement your own shell for this assignment. If we find that you used the
system function the termios library, or any similar functioning library, you
will receive a ZERO for the assignment.
Finding programs
Shells provide a nice command-line environment by automatically searching
common locations for commands. For instance, when a user types ls , the shell
will automatically figure out that the binary is actually located at /bin/ls .
On Linux, the paths that a program has to search in order to find
binaries/executables is stored in the environment variable PATH.
In your linux shell, you can inspect your environment variables using the
printenv command:
$ printenv
TERM=xterm
SHELL=/bin/bash
PATH=/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/b
in:/sbin:/bin:/usr/games:/home/cse320/bin
…
When using PATH, check if the command includes a / character. If so, you may
pass this command directly to the exec system call, as the command itself is
specifying a relative or absolute path. If the command does not include a /
character, then the shell should try each of the values in the PATH list,
e.g,: ls should be checked as /usr/lib/lightdm/lightdm/ls , /usr/local/sbin/ls , /usr/sbin/ls , /usr/bin/ls , /sbin/ls , /bin/ls , /usr/games/ls , and /home/cse320/bin/ls .
You MUST use the stat system call to check whether a file exists, rather
than relying on the more expensive exec system call to fail to find out.You may use any exec variant you like for this assignment. Each exec variant
has pros/cons that you should investigate before choosing.
In general, environment variables are passed from the parent through the envp
argument to main. Be sure to parse these variables so that you can use them to
find programs, as well as pass them to child processes.
The following features must be implemented:
- Use the PATH environment variable to search for commands. If the entered command is found then it should be executed.
- Handle the case where a command is not found.
