Assignment 2, due Feb 8

        sed 's/xxx/yyy/' < a > b

will take input from file a and copy it to b while changing the first occurance of xxx on each line to yyy.

        sed -e 's/xxx/yyy/' -e 's/x/X/g' < a > b

The above converts the first xxx on each line to yyy and then capitalizes all remaining x characters on each line.

a) Write a shell script that lists all files in the current directory, one per line, with a leading tab on each line and quotation marks around the filename. (0.5 points)

#!/bin/tcsh

# list all files in the current directory, one per line, with a
# leading tab on each line and quotation marks around the filename.

# uses ls to list the files one per line,
# then pipes the text into sed to add the decorations

ls | sed -e 's/^/        "/' -e 's/$/"/'

b) Write a shell script that echoes all of its command line arguments, one per line, where each argument is in quotes and is preceeded by its argument number and an equals sign. (0.5 points)

#!/bin/tcsh

# echo all command line arguments, one per line, in fancy format.

@ number = 1
foreach parameter ($argv)
        echo $number=\"$parameter\"
        @ number = $number + 1
end

a) How did Apple handle fat binary files in the transition to the Power PC from the older Motorola 68000? (0.5 points)

They used a kluge that relied on the fact that each file in the Mac file system has a resource fork and a data fork. They simply stored one object file in each fork. This solution does not generalize!

b) Consider the alternative of storing fat binaries as directories of thin binaries with one directory entry for each architecture, versus the alternative of creating a new file type for fat binaries. What would make you prefer one model over the other? (Note, each has its own appeal.) (0.5 points)

This solution generalizes, but it exposes to the user the internal structure of the fat binary -- an internal structure that may better be hidden to prevent tampering. This solution might be better if we had a way to force the user to think of the directory representing the fat binary as a single indivisable object.

In fact, the textual parameters in the array of strings and in the environment may be file names, numbers, or just strings, but the Unix model leaves it entirely up to the launched program to check its parameters and the values of environment variables.

a) It would be nice if the shell, on launching a program, could check the types of some or all of the program's parameters. Briefly suggest a change to the object file content to allow type checking of program parameters. Please, don't go into details about the data formats, just give a high-level description of the information to be stored. (0.3 points)

The object file could have a special section listing the arguments for the program and, for each, giving the expected type of the argument.

b) In strongly typed languages such as Pascal and Java, user-defined types are allowed. What barriers are there to extending your solution in part a) to user defined types? (0.4 points)

The suggested format is fairly straightforward for a finite list of predefined types, but there is no obvious system-level notion of type that would allow user defined types to be supported.

c) Discuss how the notion of a resource-fork, as in the Apple Macintosh file system, might be used to uniformly enforce parameter type rules for both executable object files and shell scripts. (0.3 points)

It would be reasonable to put the list of expected parameter types as an entry in the resource fork of the file.