0% found this document useful (0 votes)
5 views3 pages

A1 Aarya Toshniwal

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views3 pages

A1 Aarya Toshniwal

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Assignment 1: Project Specification and Analysis

Project 1: Command Line Shell


Aarya Toshniwal

1. User Goals
The purpose of the shell is to give the user a simple but powerful interface to interact
with the operating system. The user should be able to:

• Run common Unix commands and manage files easily.

• Control background and foreground jobs without needing another tool.

• Use redirection and pipes to combine programs together.

• Enjoy convenience features like history, tab completion, and a prompt that helps
them know where they are.

2. Functionalities
Built-in Commands
Commands like cd, pwd, exit, echo, history, clear, set/unset, jobs, fg, bg, and
kill will be directly implemented inside the shell. This is necessary because they modify
the state of the shell itself (e.g., changing directories or managing its own environment
variables).

External Commands
External programs (e.g., ls, cat, grep, ping, date) will be executed using fork() and
exec(). Arguments and flags should be passed properly, and the shell should search for
executables using the $PATH variable.

Advanced Features
• Redirection: Support for >, >>, and <.

• Pipes: Support for multiple stages such as cat file | grep text | wc -l.

• Background jobs: Allow & at the end to run processes in background.

• Error handling: Clear messages when commands fail or are invalid.

1
3. Error Conditions and Handling
• Invalid command: Print “command not found” instead of crashing.
• Permission denied: Explain clearly why the command failed.
• Syntax errors: For example, unclosed quotes should show “syntax error”.
• Job not found: If the user tries fg on a non-existing job.
• History file issues: If the history file cannot be written, fallback to in-memory
history.

4. Specification and Design Choices


The shell will be broken into modules to keep the design simple:
1. Parser: Splits user input into tokens, recognizes special characters (|, >, &).
2. Executor: Runs commands. For built-ins, executes directly; for others, uses
fork() + exec().
3. Job Manager: Keeps track of background jobs and allows them to be controlled.
4. History Manager: Stores commands in memory and writes them to a history file.
5. Prompt and Completion: Provides a helpful prompt and supports tab-based
completion.
Design Analysis: We could use a very simple parser that just splits by spaces,
but this would fail when arguments have spaces (e.g., file names like "My Documents").
Therefore, the parser must support quotes and escapes.
Similarly, job control is optional in many simple shells, but implementing it shows
how process groups and signals work in the OS. It also makes the shell more realistic.
Tab completion can either be done manually by scanning directories, or by using a
library like readline. Using a library saves time but reduces learning. For this project,
a simple manual approach is better.

5. Theory
The shell uses several operating system concepts:
• Processes: Created by fork() and replaced using exec().
• Signals: Used for job control (SIGINT for Ctrl+C, SIGTSTP for Ctrl+Z).
• Pipes: Provide inter-process communication by connecting output of one process
to input of another.
• Redirection: Implemented using dup2() to replace stdin/stdout with files.
• Scheduling: Foreground vs. background jobs depend on how the shell waits for
child processes.

2
6. Data Structures
• Commands: Represented as a struct with fields for command name, arguments,
input/output redirections.

• Jobs: Stored in a list, with each job containing job ID, process ID, status (run-
ning/stopped).

• History: Stored in a vector/list, written to a history file at exit.

• Environment: Stored as a key-value map for quick variable lookup.

7. Analysis of Complexity
• Parsing is linear in the length of the input.

• Path search is proportional to the number of directories in $PATH.

• Pipelines scale linearly with the number of commands.

This means performance should be acceptable for normal shell usage.

8. Plan and Timeline


1. Basic REPL (read, parse, run).

2. Implement built-ins (cd, pwd, exit).

3. Add redirection and pipes.

4. Add job control and signals.

5. Add history and persistence.

6. Add tab completion and finalize error handling.

9. Deliverables
• Source code with comments and modular structure.

• Documentation (README + usage examples).

• Test cases and example commands.

• This analysis and specification document in LATEX.

You might also like