Office Hours:
    Periods 6,7,8  in room 301
    Note: 6th is my lunch and I tend to be out getting food the 1st 10 minutes of the period

2019-01-10 Final Project

posted Jan 10, 2019, 5:46 AM by Konstantinovich Samuel

Documentation Specifications
In addition to your code files, you will have to include the following documents:
  • The design document (You should have handed it in already)
  • makefile 
    • This should build the project when I type make, you can provide instructions on how to run the project if "make run" is not sufficient
  • README.md 
    • This should be the main README.md for your repository
    • It should have the following information in the following order:
      • Project Name
      • Team Members
      • Broad description of project
      • List of any required libraries
        • Include apt-get instructions on how to install the libraries
      • Instructions on how to use your project ( e.g. make server then make client args="IP_OF_SERVER" )
    • DEVLOG - Both Partners: Write a sentence or two every day that you work on the project about what you personally accomplished.

The final project is to be a significant piece of work that illustrates many of the ideas and techniques studied in the class. Highlights include:
  • Allocating memory.
  • Working with files.
  • Finding information about files (stat and such).
  • Processes (fork, exec etc.).
  • Signals
  • Pipes (named and unnamed).
  • Shared memory, 
  • Semaphores.
  • Networking.

  • Make sure to mention any libraries in the README where you describe compiling instructions.
  • Check with me to make sure we can install them.
  • Make sure your program will run in the cs lab computers.
  • Make sure they don't trivialize a systems programming aspect of the project.
  • If you are doing networking, make sure to specify the IP address and port via the command line. You should test with That's the "loopback" address, it connects to itself. You can use that to test even if your machine isn't connected to the internet.
Final Commit (Jan 15th 8am)
Project Presentations (Jan 15th - Jan 18th)
Remaining Time: voluntary shell presentations


posted Dec 21, 2018, 11:03 AM by Konstantinovich Samuel

Create a forking server system. Part 3 of the 3 part server series.
  • start with the persistent server system from the previous assignment.
  • add/modify pipe_networking.c/h so that the server side handshake is broken up appropriately.
  • modify the server program to work as a forking server
  • leave the client alone
  • you should submit pipe_networking.c/h as well as both your server and client .c files (and a makefile, as always!)

2018-12-19 Server

posted Dec 19, 2018, 9:20 AM by Konstantinovich Samuel

  • Modify the working server and client programs as follows:
    • Client
      1. Handshake
      2. Prompt user for input
      3. Send input to server.
      4. Get response from server and display it to user
      5. Repeat steps 2-4 until interrupted (ctrl-c).
    • Server
      1. Handshake
      2. Get data from client
      3. "Process" data - do something interesting to it
      4. Send processed data back to client
      5. Repeat 2-4 until the client exits
        1. When the client exits, the pipes will close automatically
      6. Reset for a new handshake
      7. Include a signal handler for SIGINT that will remove the WKP


posted Dec 18, 2018, 11:54 AM by Konstantinovich Samuel   [ updated Dec 18, 2018, 12:19 PM ]

  • Check out the files on https://github.com/mks65/networking
    • Copy them all.
  • Fill in the function definitions for server_handshake and client_handshake in pipe_networking.c.
    • These should do everything needed to establish a 3-way handshake between the client and server.
    • make sure you include diagnostic print messages in your functions.
  • make and test
  • You should not modify any other files for this assignment.
Github Repo:

2018-12-12 Semaphore Assignment

posted Dec 12, 2018, 10:14 AM by Konstantinovich Samuel   [ updated Dec 13, 2018, 12:02 PM ]

including This will be due Friday, 12/14

With your table buddy, write a telephone style game! It will use a semaphore to control access to a file and shared memory. 

The main program should work as follows:
  1. Print a message this it will check if resources are available.
  2. When they are, display the last line added to the story (or none, if it is new).
  3. Prompt the user to enter the next line
  4. Update the story
  5. quit

This game will require 2 files 
  1. A control program
    • Take a command line argument to determine if it is creating or removing the resources or viewing the story.
    • If creating (command line argument: -c):
      • Should make the shared memory, semaphore and file (open the file with the truncate flag). 
      • Set any values that are needed.
    • If removing (command line argument: -r)
      • Remove the shared memory, the semaphore and the story.
      • Display the full contents of the story.
      • This should wait until the semaphore is available.
    • If viewing (command line argument: -v)
      • Output the contents of the story file. 
      • This mode does not need to interact with the semaphore
  2. A main writing program
    • Will attempt to access the resources using the semaphore
      1. Once in, it should display the last line added to the file (use shared memory to contain the size of the last line).
      2. Prompt the use for the next line.
      3. Once a new line is read, write that to the file, update the shared memory and then release the semaphore
  3. Your run target in your makefile should be the main program
  4.  You can also have a setup target that is the control program (including the args)
#compile everything

#execute setup (including an argument)
make setup args="-c"

#execute main program:
make run


Sample Control Program:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <sys/types.h>
#include <errno.h>

#define KEY 0xDEADBEEF

 union semun {
   int              val;    /* Value for SETVAL */
   struct semid_ds *buf;    /* Buffer for IPC_STAT, IPC_SET */
   unsigned short  *array;  /* Array for GETALL, SETALL */
   struct seminfo  *__buf;  /* Buffer for IPC_INFO */

int main() {

  int semd;
  int r;
  int v;
  semd = semget(KEY, 1, IPC_CREAT | IPC_EXCL | 0644);
  if (semd == -1) {
    printf("error %d: %s\n", errno, strerror(errno));
    semd = semget(KEY, 1, 0);
    v = semctl(semd, 0, GETVAL, 0);
    printf("semctl returned: %d\n", v);
  else {
    union semun us;
    us.val = 3;
    r = semctl(semd, 0, SETVAL, us);
    printf("semctl returned: %d\n", r);

  return 0;

Sample Semaphore Use:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <sys/types.h>
#include <errno.h>

#define KEY 0xDEADBEEF

int main() {
  int semd;
  semd = semget(KEY, 1, 0);

  struct sembuf sb;
  sb.sem_num = 0;

  sb.sem_flg = SEM_UNDO;
  sb.sem_op = -1;
  semop(semd, &sb, 1);

  printf("got the semaphore!\n");

  sb.sem_op = 1;
  semop(semd, &sb, 1);

  return 0;

2018-12-09 RetConning your shell

posted Dec 9, 2018, 11:27 AM by Konstantinovich Samuel

Script to test your shells. 
As a way to keep my sanity and keep your grades high I propose the following:
a - I will give you all full/close to full credit on the shell assignment.
b - You will test and fix your shell -> So I won't have to grade so many broken shells
c - I will grade them again later, and hopefully not need to deduct points (But I will retroactively lower unfixed shells)

Here is a simple test script.
It runs some tests on bash
Then it runs those tests on your shell

P.S. - Extra output is not appreciated! Some people had multiple lines of whitespace/debug info after EVERY command
Your output should be VERY close to what bash looks like. 

This shell test file only requires make / make run, and no directory called ktests already created.
1. put it into a file called test.sh
2. Set permissions:
chmod +x test.sh
3. then execute the file

mkdir ktests
mkdir ktests/dir1
touch ktests/file1
touch ktests/file2
touch ktests/out
touch ktests/dir1/file3
cat > ./ktests/tests <<EOL
cd ktests
echo 1_DIRECT_LS
ls -l
echo _
ls | wc
echo _
ls > out
cat out
echo _
wc < out
echo _
cd dir1
cd ..
echo _
echo _
echo _____________________
echo ___BASH_OUTPUT:___
echo _____________________
bash < ktests/tests
echo _____________________________
echo _____________________________
make run < ktests/tests
rm -rf ktests


posted Dec 7, 2018, 12:05 PM by Konstantinovich Samuel

Shared memory is a thing, and it's exactly what it sounds like. You can learn more about it here:

Once you've learned a thing or two, write a program that does the following:
  1. Connects or creates a shared memory segment large enough to hold a 200 character string.
  2. Displays the contents of the shared memory.
    • If the segment was just created, instead show a message saying as much.
  3. Ask the user if they want to change the data in the segment.
    • If yes, prompt the user to enter a new string and write that to the segment.
  4. Ask the user if they want to delete the segment, if yes, then delete it.
Github submission link

2018-12-03 Advent of Code

posted Dec 4, 2018, 10:31 AM by Konstantinovich Samuel

Sometimes we forget to code for fun, because of deadlines and grades.

My AP classes are joining a private leaderboard (using the code below)
Maybe you can show them how it is done? ;)

code: 381635-8d1b10ee

2018-11-19 Don't be a shell out...

posted Nov 19, 2018, 11:54 AM by Konstantinovich Samuel

Goal: Write your own shell.

You (and a partner if desired - highly suggested) are to write a shell. The shell should implement as many of these features as possible. The first being the most basic up to the last which is the most complex.
  1. Read a line at a time, parse the line to separate the command from its arguments. It should then fork and exec the command. The parent process should wait until the exec'd program exits and then it should read the next command.
    • Note: exit and cd cannot be run through a forked child process, you will have to implement these commands on your own.
      • check out the chdir() function
  2. Read and separate multiple commands on one line with ;. That is, the line ls -l ; echo hello should first run the command ls -l and then echo hello.  
  3. Implement simple redirection using > (redirecting stdout) and < (redirecting stdin). - This will be explained in class after Thanksgiving. 
  4. Implement simple pipes, that is: ls | wc would run ls and use the output from ls as the input for wc. - This will be explained in class after Thanksgiving.
    • Check out popen() for this. 
All of these commands work in bash, so use it to check out the functionality of each feature if you are unclear about anything.

Specific requirements
  1. Every function you write must have a function header describing the arguments, return value and what the function does.
    • Use modular design liberally. This is a large program.
  2. You should have a readme file with the following:
    1. A description of what features your shell implements
    2. A description of what features you attempted to implement but were unsuccessful
    3. Any bugs or things you want me to know about your program
      1. I am much more forgiving of reported bugs than bugs I discover while testing
    4. A copy of every function header
    5. An example of the readme file can be found in the github repository for this assignment
  3. This project should use separate C files as necessary.
  4. The project should be built using make and a makefile, I will only compile by using make. 
Try starting with these restrictions on input:
  1. To make your life easier, you could require that all items on the command line are to be separated by a single space.
  2. When parsing the line, it might help to count the number of tokens (individual pieces), before parsing.
  3. You can restrict the locations and ordering of > and <. 
  4. You can limit piping (|) to a single pipe. 
If you would like to implement other features after getting these ones down, please do. Look at what bash does and see what else you can do!

2018-11-16 Fork Responsibly

posted Nov 16, 2018, 10:57 AM by Konstantinovich Samuel

Write a c program that does the following:
  • Forks off 2 child processes
  • Child process instructions:
    • At the start print its pid
    • Sleep for a random number of seconds in the range [5, 20]
      • Each child should sleep for a (potentially) different amount of seconds
    • At the end print a message that it is finished
  • Parent process instructions
    • Before forking, print out some initial message
    • After the fork, wait for any child to finish
    • Once a child has finished, print out the pid of the completed child as well as how many seconds it was asleep for.
      • Do not run any kind of timer, think about how the child could send this information back to the parent.
    • Print a message that the parent is done and then end the program
      • The other child might still be running, that's ok.
github repo:

1-10 of 28