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]
