Ant uses in this order: /bin/env, /usr/bin/env, env (in PATH). Check out getProcEnvironment() and getProcEnvCommand() in:
http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/Execute.java?view=markup With Ant if you are running on a Unix OS and the env command fails you are out of luck, however I do know that it is supported on Solaris and Linux. Greg -----Original Message----- From: Alex Karasulu [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 3:55 PM To: Avalon framework users Subject: Re: Re: Problem starting Merlin on Solaris Hello, <snipped-a-bunch/> > >Tracking through the org.apache.avalon.util.env.Env.getUnixUserShell code, > >it looks like > >is won't work on systems like Solaris which use NIS for the password file, > >where users > >are not kept in the /etc/passwd file. Yep you're right on. The problem here lies in the fact that shell environment variables are based obviously on the shell used by the UNIX users. This on vanilla boxes is stored in /etc/passwd. Now NIS throws another problem our way. As you can see this Env stuff is really a PITA. For the time being I suggest just adding a local user account if you can do that and run Merlin on the local account. This is obviously a cop out but you can do this and fire things up without having to wait on us to make a change. Anyway there are a few ways to deal with this for the long term: 1). Add a system property for the default shell to be used by the env class. If the property exists then it overrides the need to check the passwd file for the default shell. If this property is not found and the user is a NIS user then the EnvAccessException still needs to be handled gracefully to inform the user about the need to specify a default shell sys property: env.shell=/usr/bin/bash etc. 2). Add the ability to do a ypcat on the respective NIS map using the correct domain to resolve the user's default shell. This is not a good way to go because now we'll need to read other files to see which NIS domain the user is part of and so on. The problem grows and the PITA becomes a RPITA (Royal PITA). 3a). Change the Env code to search for any shell it can find. This is not a good idea because weird things will happen. Namely if the user defines the MERLIN_HOME in .bashrc and the Env class uses ksh then we've got a really confused user on our hands pulling his/her hair out. We don't want that. 3b+1). Use the shell script that fires up merlin to set the shell system property (env.shell) defined in 1. This is like 3a in that the shell used by the script may not be the default shell of the user. This leads to similar problems as option 3a hence the 3b+1 label for this option. Also note that even though Claude is using the shell script (I think), the shell script may not always be the manner in which Merlin is fired up so this would not be a complete solution for every case. 4). Look inside the users home directory for shell resource and/or profile files to guess the shell used. This is tricky as well since some users may use more than one shell to work with. Perhaps we can expand this solution to avoid a shell fork for reading environment variables and just perform a scan of shell resource and profile files in the sequence used by shells. Namely sourcing the users ~/.profile and other files it sources. However we would do this for all resource files of all shells and take the UNION of environment variables. So if MERLIN_HOME is defined somewhere in some resource file like the system resource file /etc/profile or the users resource file ~/.profile then we'll pick it up. The same goes for the other shells like csh, bash, ksh or other exotic shells. The only problem with this approach is the potential for conflicts. If one shell resource file defines Merlin's home in one place and the resource file of another shell defines MERLIN_HOME in yet another install root then we get confusion. 5). Do a ps and see which process is the Parent PID - meaning look up the PPID of the current PID. Or just figure out what shells the user is running currently and pick one to use. Again this imposes problems if the user uses more than one shell and is running both. Which one do you use. Also getting the PPID of the current executing process requires you to know the current process' PID and supposes that all 'ps' implementations on all platforms offer this PPID value. Most do but some require special switches and that needs to be coded. 6). Change the API using an overloaded constructor to accept a default shell in case the user's shell cannot be found so an EnvAccessException does not result. This then leaves the problem of specifying the default shell upto the user of the API. In the end this would boil down to a combination of #1 and #6. If others have more ideas then please let me know. I think my +1 goes to option #1 & #6 together. There really is no good way to work with Env variables and this is probably why Java does not offer a standard means to access them. Again I appologize for any inconvenience this may have caused you. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
