Name: joT67522 Date: 11/19/97


Java is not a binary file, rather it is a Korn Shell script that calls
the real interepreter. Being a ksh script, if the use has the
environment variable ENV set, then upon running the java interpreter
the file pointed to by the ENV environment variable will be processed
before the real java interpreter is called.

There is at least one case where this behavior is undesirable: if the
user changes his umask in the ENV file.

If I write the following Java program:

  import java.io.*;
  public class test {
    public static void main(String args[]) {
      if(args.length != 1) {
        System.out.println("You must suply as an argument the name of a directory to create!");
        return;
      }
      File tempFile = new File(args[0]+"dir");
      try {
        tempFile.mkdir();
      } catch (Exception e) {
        System.out.println("Can't create directory!");
      }
    }
  }

Then the execution of the commands:

  $ umask 007
  $ java test newdir

should result in a directory "newdirdir" being created with
permissions 770. Tracing the java executable with the command "truss
java test newdir" shows that Java internally executes the system call
"mkdir("newdirdir", 0771)" and if the umask is 007 then the directory
created will be indeed:
   
      drwxrwx--- 2 krsul 512 Nov 19 12:46 newdirdir/

However, the following can happen REGARDLESS OF WHAT SHELL I USE!

   $ umask 007
   $ rmdir newdirdir
   $ java test newdir
   $ ls -ld newdirdir
   drwxr-x--x 2 krsul krsul 512 Nov 19 12:47 newdirdir

   # oh, oh.... this should have been 770!! The problem is that
   # the ENV variable is set and whatever it points to was executed too.
   $ printenv ENV
   kshfile
   $ cat kshfile
   umask 022

   # test the theory: Unset the ENV variable and see if the same thing
   # happens....
   $ ENV=
   $ export ENV
   $ umask 007
   $ rmdir newdirdir
   $ java test newdir
   $ ls -ld newdirdir
   drwxrwx--- 2 krsul krsul 512 Nov 19 12:52 newdirdir

   # this is much better....

One could argue that this is expected IF YOU CAN ASSUME THAT THE USER
KNOWS THAT java IS A ksh SCRIPT... but I argue otherwise. I have a
java application that is used by many users who share files and
databases. The behavior of the java program should be the same
regardless of what shell they are using and this is not the case, and
that includes the creation of directories. If a user types the command
"umask 007; java test dir" then the java program should create a
directory with mode 770. If the user types the command
"umask 077; java test dir" then the program should create a directory
with mode 700".

A much larger problem is that the user could have no clue what ENV
means for ksh... or may not even know what ksh is. If a tcsh user
decides to write a script called "remove_backup_files" and types
"setenv ENV remove_backup_files"... and then sometime later runs a
java program... all his backup files will be gone! This test proves
it:

  # Running tcsh
  $ setenv ENV print_my_environment
  $ cat print_my_environment
  printenv

  # Some time later... maybe weeks... run a Java program
  $ java test file1
  MANPATH=/usr/man:/usr/local/gnu/man:/usr/local/perl/man
  PAGER=/usr/local/gnu/less
  ENTOMB=on
  PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/gnu:/usr/local/perl
  USER=krsul
  TERM=xterm
  TZ=EST5
  ENV=print_my_environment
  SIGNATURE=Ivan V. Krsul Andrade
  LINES=24

Now this.... is not acceptable.

Incidentally, if the user types "umask 000; java test dir" the java
program should create a directory with mode 777.... which doesn't
happen even under csh or sh without the ENV variable set because the
java application executes the command "mkdir("newdirdir",
0771)"... why the choice of mode 771? What happens if I want to
create a files

My suggestion is that you use something other than ksh to write the
java script.
(Review ID: 20553)
======================================================================