Thanks Greg that's what I'll use. It seems to use NIS too to find out the default shell of the user. And even if I'm in ksh for a user with a bash default it finds my variables just fine. I knew this - damn it why didn't I think of it!!!
Thanks again, Alex > > From: "Messner, Greg" <[EMAIL PROTECTED]> > Date: 2003/12/16 Tue PM 08:55:12 EST > To: "Avalon framework users" <[EMAIL PROTECTED]> > Subject: RE: Re: Problem starting Merlin on Solaris > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
