CSCI 4061 Lab04: dup() / dup2()
and the File Descriptor Table
- Due: 11:59pm Mon 2/22/2021 on Gradescope
- Approximately 1.00% of total grade
CODE DISTRIBUTION: lab04-code.zip
- Download the code distribution
- See further setup instructions below
CHANGELOG: Empty
Table of Contents
1 Rationale
As discussed in lecture, Unix maintains a table of open File
Descriptors for all processes. Using the dup()
and dup2()
system
calls, programs can manipulate this table to achieve interesting
effects, notably redirection of output from standard locations to
other places. This lab demonstrates some common techniques for doing
so and will acquaint students with the basics of how the file
descriptor table works and how it is inherited by child processes.
Grading Policy
Credit for this Lab is earned by completing the exercises here and
submitting a Zip of the work to Gradescope. Students are responsible
to check that the results produced locally via make test
are
reflected on Gradescope after submitting their completed
Zip. Successful completion earns 1 Engagement Point.
Lab Exercises are open resource/open collaboration and students are encouraged to coopearte on labs. Students may submit work as groups of up to 5 to Gradescope: one person submits then adds the names of their group members to the submission.
See the full policies in the course syllabus.
2 Codepack
The codepack for this lab is linked at the top of this document. Always download it and unzip/unpack it. It should contain the following files which are briefly described.
File | Use | Description |
---|---|---|
QUESTIONS.txt |
EDIT | Questions to answer: fill in the multiple choice selections in this file. |
switch_stdout.c |
Study | C file to study to answer QUIZ questions |
redirect_child.c |
COMPLETE | Create and complete the program for the CODE portion of the lab |
nums.txt |
Data | Data used in the tests |
QUESTIONS.txt.bk |
Backup | Backup copy of the original file to help revert if needed |
Makefile |
Build | Enables make test and make zip |
testy |
Testing | Test running scripts |
test_lab04.org |
Testing | Tests for this lab |
3 QUESTIONS.txt File Contents
Below are the contents of the QUESTIONS.txt
file for the lab.
Follow the instructions in it to complete the QUIZ and CODE questions
for the lab.
__________________ LAB 04 QUESTIONS __________________ Lab Instructions ================ Follow the instructions below to experiment with topics related to this lab. - For sections marked QUIZ, fill in an (X) for the appropriate response in this file. Use the command `make test-quiz' to see if all of your answers are correct. - For sections marked CODE, complete the code indicated. Use the command `make test-code' to check if your code is complete. - DO NOT CHANGE any parts of this file except the QUIZ sections as it may interfere with the tests otherwise. - If your `QUESTIONS.txt' file seems corrupted, restore it by copying over the `QUESTIONS.txt.bk' backup file. - When you complete the exercises, check your answers with `make test' and if all is well, create a zip file with `make zip' and upload it to Gradescope. Ensure that the Autograder there reflects your local results. - IF YOU WORK IN A GROUP only one member needs to submit and then add the names of their group. QUIZ Questions on switch_stdout.c ================================= Analyze the `switch_stdout.c' program. Compile and run it via ,---- | > make switch_stdout | ... | > ./switch_stdout | ... `---- Analyze the code and focus your attention on the use of `open() / dup() / dup2()' which this program demonstrates. Answer the following Questions about the techniques used in this program. You may need to consult the Manual Page / Documentation on some functions to answer confidently. Program Output ~~~~~~~~~~~~~~ Which of the following is the output for `switch_stdout' when run? (each of 1. 2. 3. appear on separate lines in the output) - ( ) 1. Now you see me. 2. Now you don't! 3. How mysterious... - ( ) 1. Now you see me. 2. Now you don't! - ( ) 1. Now you see me. 3. How mysterious... - ( ) 1. Now you see me. open() system call ~~~~~~~~~~~~~~~~~~ The `open()' system call is used to open a file for writing in the example. What is returned by this system call? - ( ) A `FILE *' which is passed to subsequent I/O operations or `NULL' for failure - ( ) An integer file descriptor which is >= 0 for success and -1 for failure - ( ) An integer return code that is 1 for success and 0 for failure - ( ) A `char *' which is the name of the opened file or `NULL' for failure Use of dup() ~~~~~~~~~~~~ Which of the following best describes how the `dup()' system call is used in `switch_stdout.c'? - ( ) It creates a duplicate of a file descriptor allowing standard output to be restored to the screen late in the program. - ( ) It manipulates the file descriptor table so output that would go to the screen goes into a file instead. - ( ) It duplicates an existing file creating an efficient copy of it on disk. - ( ) It creates a child process that prints to a file instead of the screen. Use of dup2() ~~~~~~~~~~~~~ Which of the following best describes how the `dup2()' system call is used in `switch_stdout.c'? - ( ) It creates a duplicate of a file descriptor allowing standard output to be restored to the screen late in the program. - ( ) It manipulates the file descriptor table so output that would go to the screen goes into a file instead. - ( ) It duplicates an existing file creating an efficient copy of it on disk. - ( ) It creates a child process that prints to a file instead of the screen. printf() changes in behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Good old `printf()' is used in `switch_stdout.c' in several places but seems to change its behavior in some of these spots. Which of the following best describes this variation in behavior? - ( ) `printf()' is called with different arguments that cause it to print to different destinations, sometimes standard output, sometimes a file - ( ) `printf()' is called the same way in each case but automatically begins printing to a file that is `open()''d and when it is `close()''d, `printf()' reverts to printing to the screen - ( ) `printf()' is called the same in each case and always prints to standard output but by changing what is in the file descriptor table at that position, output goes to the screen or to a file. CODE Complete redirect_child.c ============================== An incomplete file called `redirect_child.c' is present in the code pack which is intended to preform the following operations. 1. Create a child process 2. The child process redirects its output into a file 3. The child process then exec()'s a new process image which will place output in the file specified 4. The parent process blocks until the child is complete and then shows the output file. A skeleton is provided but a number of TODO/??? items must be filled into to complete the program. A number of the techniques are required to complete the code - Process manipulation from previous labs - I/O redirection demonstrated in this lab in `switch_stdout.c' Employ these to complete the program and pass the tests available in `make test-code'. A correct run looks like the following. ,---- | > make | gcc -Wall -Werror -g -o switch_stdout switch_stdout.c | gcc -Wall -Werror -g -o redirect_child redirect_child.c | | > ./redirect_child | usage: ./redirect_child <childfile> | | > ./redirect_child childout.txt | Removing file 'childout.txt' prior to run via a subshell | Creating a child to do 'wc' | Parent waiting for child to complete | Child redirecting output to 'childout.txt', then exec()'ing | Child complete, return code 0 | Showing output of 'childout.txt' via 'cat' command | 25 25 66 nums.txt | | > cat childout.txt | 25 25 66 nums.txt `----
4 Submission
Follow the instructions at the end of Lab01 if you need a refresher on how to upload your completed lab zip to Gradescope.