Lab 6: Input and Output

In this lab you'll extend your simple database to include "save" and "load" capabilities and also interact with a user.

When you're done with this lab you will have done the following things:

  1. Extend your database program to load and store its contents
  2. Interact with users through a small set of commands
  3. Create some automated tests for your database program

Before you begin, launch your Linux, and git pull in your repository. You should have a lab6 directory. Do all your work for the lab in that directory.

Part 1: Implement dbe_fprint (a more flexible dbe_print)

Right now dbe_print can only print to the screen, but today you'll be writing data to a file as well. To make this happen, the first step is to implement dbe_fprint to print a database entry to a file

  1. Follow the comments of dbe_fprint in data.c to finish this part.
  2. You will need to use the fprintf function. It is used to write formatted output to a file. It is similar to the printf function in that it allows you to format and print data to the standard output (console), but instead of printing to the console, it prints to a file. For more info on how fprintf works, see this tutorial.

Part 2: Implement getALine() to read input

  1. Implement getALine(). The comments in data.c should guide you. So will the manpage for fgets.
  2. Check if you're on the right track by making and running the test executable.

Part 3: Adding an interaction prompt

Now that you can get input and write output, it's time to interact with a user. In this part of the lab, you'll be creating a run loop that repeatedly asks for input, processes the input (the command), then repeats.

To get started, open up local.c and read the comment block above handleLocalInput. It explains all the commands you will implement!

Read input from the user

If you make and then run ./local, you'll see the program loops forever without stopping. This is because the program skips getting input from the user. Uncomment the line in handleLocalInput that says to uncomment it. Test your work by making local and running it again.

implement some commands:

The TODO comments in the body of the function will tell you where to implement things. Make sure the parts you implement work by running the local executable to test each new command you implement.

You will implement most of the "hard work" parts of each command in data.c, only calling helper functions from local.c. Look at data.h to see what helper functions may be available for each command.

Some more information about the commands and suggestions below. We recommend completing the commands in this order:

NOTE: Each time you finish a command, you can run ./local and manually test this command. If the result looks good to you, you can run ./test_local.sh to give it a more thorough test. (Warning: Without correct q or x command, the script will freeze. In this case, you can type ctrl + c to terminate it forcefully.)

(The code uses switch statement. If you are unfamiliar with switch, feel free to go through this quick tutorial)

The q command

To quit, find a way to break out of the loop!

The l command

When a user issues the l, command, list all the database entries using do_list_database().

(Local)> l
x => y
w => z
(Local)>

In order to test this command, you need to implement the a command. So don't test until you implement the next command.

The a command

When a user issues the a, command, prompt for two more inputs (one at a time). A session should look like this:

(Local)> a
       name? myname
       value? myvalue
(Local)>

In the last lab you implemented a helper function in data.c that will do the hard work. HINT: you can use the character arrays buf and buf2 already declared inside the handleLocalInput function body.

The r command

When a user issues the r, command, prompt for one more input: the name to remove. Find the first match and remove that one. A session should look like this:

(Local)> r
       name to remove? bob
(Local)>

In the last lab you implemented a helper function in data.c that will do the hard work! Simply prompt the user for a name and then call that function!

Part 4: Adding an export capability

The e command

For this command, you need to implement the user-interaction parts in local.c, but also will need to implement some functionality in data.c (specifically, comments in the do_export_db() function).

Part 5: Adding an import capability

The i command

This is very similar to the e command.

Part 6: Finding matches

The f command

Implement do_find_all_matches, which is triggered by the 'f' command.

Hint: you use db_find_one repeatedly until you run out of matches.

To test, run make first and execute the ./test to verify your implementation.

Finishing the Lab

  1. Make sure you can pass all test cases by running both ./test and ./test_local.sh
  2. If your code does not compile and run, you will get a zero on this lab. You may get partial credit for finishing some of the functions, but your code must at minimum compile and run.
  3. Ensure both your names are on all of the files you edited. Both of you should submit a copy of the code on Gradescope.
  4. Upload any files you modified (data.c local.c) to Gradescope