Problems with System V Release 2.1 on 68010

[Ron Janzen]

I am posting this for a friend who doesn't have net access. PLEASE reply
to his e-mail address which is given at the end of the posting. mcvax can
be reached thru seismo.

-------------------------------------------------------------------------
I'm working with System V Release 2.1 from Motorola, for the 68010.
I've come across some very poorly documented, or strangely implemented
things in the kernel and shell, and would like to find out whether these
are problems with our (Motorola) release, or whether they are problems
inherent in System V. I'd also like to know what the easiest and most
elegant solutions to these problems are.

1) I know that some (berkeley?) versions of exec(2) understand shell scripts.
   The implementation i've seen is to put "#! interpreter-path" at the
   start of the script. As far as i can see, this is very kludgy, but good
   for several reasons. It means that any "program", either a binary or a shell
   script, can be exec(2)'d. It means that shell scripts can be setuid (is
   this possible anyways? I couldn't see a way). It allows a consistent
   way to handle scripts for several shells.
   Is this mechanism only a berkeley thing? I know it's not very elegant,
   but is it hard to implement for some non-obvious reason? (given the
   source to exec(2), i mean). I can see that it means the file needs read
   perms so that exec can read it, but the interpreter is going to need
   them anyways.

2) Does our exec(2) have a bug here? A file cannot be exec'd (by our exec(2))
   by root unless execute permissions are set for one or more of user, group,
   other. There are several things which make me think that this is a bug:
   - it is inconsistent with the way read and write perms are given;
     root can read and write a file regardless of the read and write permission
     bits.
   - intro(2) says "... execute permissions on a file are granted to a process
     if one or more of the following are true: The process's effective user
     ID is superuser. ..."
   - access(2) on a file with no execute perms, by a process with real uid
     of root, returns 0, indicating that root can execute the file.

3) Why is there no eaccess(2) which uses effective uid? It can be done
   with stat(2), but so can access(2), can it not? The fact that access(2)
   uses real uid makes it not so convenient, and might cause programs that
   use it to be incorrect (like maybe the shell? - see below)

4) Is it true that the sh construct "$@" (in a shell script) is supposed
   to be identically equal to the command-line arguments? It seems that
   it should, because otherwise there is no way to get at these because
   $@ = $* gets reparsed, and "$*" is one word.
   In our sh, "$@" is exactly equivalent to the command line args if there
   are some, otherwise it is equal to "" instead of nothing.
   Seems like a bug to me. If so, how wide-spread is it?

5) Shell functions. Are they such a kludge on all System V sh's? On ours
   the definitions seem to be stored with shell parameters, so if you do a set
   you get a huge mess of junk. They are not part of the environment though
   (thank god), but it would be nice if there was some mechanism for getting
   them into every sh started up. They do get into forked sh's though, which
   means they are "exported" to shell scripts, and commands in (). The former
   is a disaster! It's easy enough to write a shell script with
   PATH=/bin:/usr/bin
   in it, but there is no simple way to ensure that commands used in the
   script are not going to be shell functions.
   Also, executing a shell function gives values to $1, $2, ... in the
   executing shell. This is really messy; these should only be changed
   while executing the function. That is, $1, $2, ... should be auto
   variables to a shell function, not external.

6) Is the PATH variable so screwed up on all System V's? It used to
   be that the component were *separated* with :, and a null component was ".",
   so an initial :, or ::, or a final : meant ".". Now it seems that the final
   : isn't "." anymore. Bug or feature?
   PATH cannot be unset either, so it can't be removed from the environment
   once it's there.
   By the way, with previous (say version 7) shells, how did you unexport
   a parameter, i.e. remove it from the environment of invoked commands?

7) It seems our shell checks file permissions before trying to exec the
   file. It will not execute a command for which the effective uid (gid)
   has permissions, but for which the the real uid (gid) doesn't. Looks
   like it uses access(2) to me, which is an error, 'cause access only
   looks at real uid (gid), and effectives are the ones that count to exec(2).

8) Command Hashing. This could be good, but our shell screws up in some
   really stupid ways:
   - if you try to execute a directory (that has execute, i.e. search, perms),
     the shell reports that it can't be executed, then hashes the name anyways.
   - executables used in shell functions aren't hashed.
   - if a name is hashed (by executing it) then removed, the shell correctly
     finds another executable with the same name if there is one, but
     doesn't replace the old hash table entry with the newly found path.

9) The new "type" shell builtin makes mistakes, and is horribly designed.
   It does the things that Kernighan and Pike's which command did, but is
   so verbose that it is unusable for anything non-interactive. It makes
   mistakes too, saying that directories are executable, among other things.

10) Shell parameters used on a command line (i.e. "TERM=xx vi file") don't
    work for shell builtins and shell functions, on our shell. The semantics
    should be that the value of the parameter is set and exported to the
    command, but when the command finishes, the variable should be back to it's
    old state. For shell builtins, the parameter isn't restored to its old
    state. For shell functions, the new value of the parameter isn't used at
    all.

11) Many of the shell scripts in /bin and /usr/bin are very poorly written.
    - they don't initialize shell variables (parameters) so any imported from
      the environment don't have a null value.
    - they don't set PATH=/bin:/usr/bin so they are very unrobust as to
      which version of a command they execute.
    Where did they get the people who wrote these?


As you can see, i'm not especially delighted with the system i'm using.
Sorry for the verbosity, but i figured that it was important to state the
problems precisely.
Please mail responses to me, as we are not on the net yet.
Thanks,
Alan Rooks - Bruel & Kjaer Copenhagen - ...!mcvax!bk!alan or ...!diku!bk!alan