A. This is the correct syntax for using execlp and will work if gimp is in the user's path and filename refers to a file on the filesystem that gimp can read and the user has permission to access. (If filename doesn't refer to such a file, gimp will still run but will give an error message saying that no such file exists.)

For such simple questions about syntax, you are probably better off writing simple pieces of code to test things out, rather than sending your question in email and waiting for a reply. For example, the code to test your question above would (assuming you have a jpeg file named "flower.jpg") simply be:

#include 

int main(void){
    char * filename = "flower.jpg";

    execlp ("gimp", "gimp", filename, (char *)0);
}

Pretty simple, isn't it? Because it is so simple, you can concentrate on the part you don't understand (execlp) without having to worry about the rest of the project. If this didn't work, you could easily add some printing statements to test error conditions.

A. Because execl is succeeding. Remember what we talked about in class for exec family system calls -- they are called once and (if they succeed) they never return. We stressed how this was very different from most other functions or system calls.

Take your call to the printf function, for example. It is a very ordinary function call, in that it is called once and (if it succeeds) returns once. What this means is that if you are following through the control flow of your code, you can ignore how printf does its job -- you simply need to know that it is called with some parameters, does something, then the control moves on to the next line in your code (the scanf, in your case) in a nice, orderly way.

However, we emphasized that exec family system calls don't work that way. Instead, if the call to exec works, your code will never reach the line after the exec. Note that, in class and in the textbook, the line following the exec is almost always a function to print out an error message that says that the exec failed. Why? Because this message won't be printed out unless exec has failed.

Now, recall from class the explanation for how exec family system calls work. What did we say they did? They replace the text (executable code) and variables of the program that is currently running with the text and variables of a different program. So, the printf and scanf that you have coming after the execl system call won't be executed because the execl worked and the code of your program has been replaced in memory by the code of the /bin/ls program.

Understanding this is fundamental, not only to understanding how to complete this programming assignment, but to understanding why not all processes on a UNIX system are running the exact same program.

A. PicShare should rename the file user2673-picshare.jpg when it places it in the /tmp directory. This is because, while you may have as many pictures as you want in your own directories, PicShare will only help you share one picture at a time.

A. It is working fine for me. Perhaps we should ask ourselves what behavior we would expect to see.

First, most programs will not change the permissions of files that they use, unless they have a good reason to. Therefore, we would expect pico to leave the permissions of an existing file alone, because it doesn't have a good reason to change the permissions . (If a user wants to change file permissions, the way to do it is to use chmod, not to run pico and edit the file!)

This is exactly what pico does for me. Regardless of the value of umask, pico leaves the permissions of existing files alone. So, pico works as I would expect.

Second, when a program creates a new file, we'd expect it to create the file with appropriate permissions for the type of file it is creating. Let's see, pico is a text editor. This means that, by default, we'd expect pico to create files that can be read and written but not executed. So, who should be able to read and write these files? The user, group members, others? Well, pico isn't a special purpose utility for editing secret information like passwords or credit card information. Rather, it is just a general purpose text editor, for editing whatever text files the user wants to edit. So, we'd expect it to go with the default values that the user has set up. These values are set up using umask.

You say you set umask to 0. What does this mean? It means you have asked for no restrictions on access. Your default is no restrictions and pico should create files that can be read and written but not executed. When I create a new file with pico after setting my umask to 0, it creates the file with read and write permissions for user, for group, and for other. This is exactly what I would expect to have happen. Again, pico works just as I would expect.

So, is pico not working this way for you? Or, are your expectations wrong?

Perhaps it is your syntax. To change the umask in your shell, you need to type

% umask 0

% umask(0)