Alex, God I wish you get a mail clent that can do threading... ;o) I just say KISS. Look at WHY the shell is required, and the answer is so banal it is embarrassing. Do you see any reason why return "/bin/sh"; wouldn't work in all weathers? We are only trying to extract a environment variable, nothing more.
Niclas On Wednesday 17 December 2003 07:55, Alex Karasulu wrote: > 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]
