Implementing a Shell
Project 1: Implementing a Shell
1 Overview
In this
individual
project you
will have to
design and
implement a
simple shell command interpreter,
called
mysh
. The basic function of a shell is to accept lines of text as input and execute programs in
response.
The
shell must be able to execute
built
-
in commands
in a process differen
t from the one
executing
mysh
.
2 Requirements
When
first
started, your shell should initialize
any necessary
data structures
and then enter a loop of
printing a prompt, e.g. “mysh# ”, reading
any commands
entered by the user and executing them.
2.1 Simp
le execution of commands
mysh
execute
s
a program in the foreground, wait
s
for it to terminate, and then resume
s
control, e.g.
mysh# vi
would launch the
vi
editor, the user can then perform text processing and after the user quits
vi
, control
is returned back to the shell. The user
shouldn’t have
to type in the full path to executables as long as
they
are within the search path specif
ied
in the environment by the
PATH
variable.
In your initial
implementation
mysh
should spawn a child
process and block wait for the child to terminate. The
relevant system calls here are
fork()
, the
wait()
and
exec()
families of calls,
and
exit
()
.
2.2
Parsing the
command line
When parsing the
command line
,
mysh
should ignore all whitespace.
You might
fi
nd the
isspace
and
strtok
man pages useful.
Please
keep in mind that your command
line parser should work, but we do not
expect it to be particularly fancy
.
For example, ” and ’ should not be treated specially by the parser.
We’d much
rather see you spend
a
lot of effort on the job
control
features of your
shell.
2.3
Built
-
in commands
Mysh
should support the
following built
-
in commands.
jobs
: Print a list of commands that are currently running or suspended. This list should include an
integer, the
command line
that started the respective program and the status (Running or
Suspended) of the program, e.g.
mysh# jobs
[1] Running
xemacs project1.tex
[2] Running
xdvi project1
[3] Suspended
vi
[4] Suspended
firefox
kill %job
: Sends
a SIGTERM
signa
l to the speci
fi
ed job, e.g.
mysh# kill %2
would terminate the
xdvi
program from the previous example.
fg %job
: Continue executing the speci
fi
ed command in the foreground, e.g.
mysh# fg %3
would bring
the
vi
program to the foreground. The shell would then wait for the user to either
terminate the
vi
program or to suspend it using Control
-
Z.
bg %job
: Put the speci
fi
ed job in the background, continuing it if it was suspended, e.g. if a user
had started the
fi
re
fox
web browser, and suspended it using Control
-
Z, then
mysh# bg %4
should let the browser continue running in the background.
pwd
: Print the current working directory.
cd path
: Change the current working directory to speci
fi
ed path.
3
Hints and T
ips
The man pages are your friends! Manpages of particular interest would be:
–
fork(
)
–
exit(
)
–
exe
c(), execl(), execv(), execle(), execve(
), execlp(), execvp(
)
–
wait(), waitpid(
)
–
kill(
)
–
iss
pace(), strtok(
)
This
project
should
be
developed
on
a
UNIX
OS.
You
are
free
to
use
any
fl
avor
of
UNIX
you
want for development
.
Start
early
! If you wait until the last minute you will not be able to
finish
.
4
Deadline and Turnin
This project is due at 6:00pm,
November
29.
Since this is a
long
-
term
project no late submissions will
be accepted.
Place all your
fi
les in a directory called
project1
. The directory should contain a text
README
fi
le
explaining any particular design decisions or features of your implementation.
It should contain at
least
three
parts:
1)
an
introduction to the basic structure
of
your
shell;
2)
a list of which features are fully
implemented, partially implemented, and not implemented;
and
3)
a discussion of how you tested your
shell for correctness.
To submit the project, use the Blackboard submission system to upload
it
.
do anyone know how to solve it ?? or have the solution?
1 Overview
In this
individual
project you
will have to
design and
implement a
simple shell command interpreter,
called
mysh
. The basic function of a shell is to accept lines of text as input and execute programs in
response.
The
shell must be able to execute
built
-
in commands
in a process differen
t from the one
executing
mysh
.
2 Requirements
When
first
started, your shell should initialize
any necessary
data structures
and then enter a loop of
printing a prompt, e.g. “mysh# ”, reading
any commands
entered by the user and executing them.
2.1 Simp
le execution of commands
mysh
execute
s
a program in the foreground, wait
s
for it to terminate, and then resume
s
control, e.g.
mysh# vi
would launch the
vi
editor, the user can then perform text processing and after the user quits
vi
, control
is returned back to the shell. The user
shouldn’t have
to type in the full path to executables as long as
they
are within the search path specif
ied
in the environment by the
PATH
variable.
In your initial
implementation
mysh
should spawn a child
process and block wait for the child to terminate. The
relevant system calls here are
fork()
, the
wait()
and
exec()
families of calls,
and
exit
()
.
2.2
Parsing the
command line
When parsing the
command line
,
mysh
should ignore all whitespace.
You might
fi
nd the
isspace
and
strtok
man pages useful.
Please
keep in mind that your command
line parser should work, but we do not
expect it to be particularly fancy
.
For example, ” and ’ should not be treated specially by the parser.
We’d much
rather see you spend
a
lot of effort on the job
control
features of your
shell.
2.3
Built
-
in commands
Mysh
should support the
following built
-
in commands.
jobs
: Print a list of commands that are currently running or suspended. This list should include an
integer, the
command line
that started the respective program and the status (Running or
Suspended) of the program, e.g.
mysh# jobs
[1] Running
xemacs project1.tex
[2] Running
xdvi project1
[3] Suspended
vi
[4] Suspended
firefox
kill %job
: Sends
a SIGTERM
signa
l to the speci
fi
ed job, e.g.
mysh# kill %2
would terminate the
xdvi
program from the previous example.
fg %job
: Continue executing the speci
fi
ed command in the foreground, e.g.
mysh# fg %3
would bring
the
vi
program to the foreground. The shell would then wait for the user to either
terminate the
vi
program or to suspend it using Control
-
Z.
bg %job
: Put the speci
fi
ed job in the background, continuing it if it was suspended, e.g. if a user
had started the
fi
re
fox
web browser, and suspended it using Control
-
Z, then
mysh# bg %4
should let the browser continue running in the background.
pwd
: Print the current working directory.
cd path
: Change the current working directory to speci
fi
ed path.
3
Hints and T
ips
The man pages are your friends! Manpages of particular interest would be:
–
fork(
)
–
exit(
)
–
exe
c(), execl(), execv(), execle(), execve(
), execlp(), execvp(
)
–
wait(), waitpid(
)
–
kill(
)
–
iss
pace(), strtok(
)
This
project
should
be
developed
on
a
UNIX
OS.
You
are
free
to
use
any
fl
avor
of
UNIX
you
want for development
.
Start
early
! If you wait until the last minute you will not be able to
finish
.
4
Deadline and Turnin
This project is due at 6:00pm,
November
29.
Since this is a
long
-
term
project no late submissions will
be accepted.
Place all your
fi
les in a directory called
project1
. The directory should contain a text
README
fi
le
explaining any particular design decisions or features of your implementation.
It should contain at
least
three
parts:
1)
an
introduction to the basic structure
of
your
shell;
2)
a list of which features are fully
implemented, partially implemented, and not implemented;
and
3)
a discussion of how you tested your
shell for correctness.
To submit the project, use the Blackboard submission system to upload
it
.
do anyone know how to solve it ?? or have the solution?
Topic archived. No new replies allowed.