Maybe I wasn't clear.
I'm writing a C program (a server) that runs a Java program (an agent)
with some arguments.
The agent's shell is unknown, so I need to check, within my C code
what kind of shell runs on the account that runs the agent.
Are the agent and server even running on the same system? If so then
[OT]
you may be able to find out the client's username and use system-
specific functions to request information about the login shell
registered for the user in the user's password control entry;
unfortunately, the shell the user logs in to is not necessarily
the shell the user is running at the time they invoke the agent
[/OT]
But what does the server care what shell the agent is running under?
If the *server* executes system(), that is going to be in the context
of the *server's* process. In order to get the agent to execute system()
you would have to send something information back to the agent
that the agent knows to interpret to invoke the appropriate system
call. But you've already said that the agent is running Java, no C,
and if you want to find out about the Java equivilent of system(),
you will need to look in Java documentation or in a Java newsgroup.
I was wondering whether you know any kind of function that can get
environment variables - so I'll be able to check the value of $SHELL
in the agent's machine.
[OT]
There is no TCP/IP mechanism that would allow a server to
inquire about the environment variables of the process at the far
end of a network socket, so if this is a client-server architecture,
the only thing you can do is have the server send a message to the
client (agent) that the agent knows to turn in to a request to send
back the environment information; but you've said the agent is
running in Java, not C, so if you are programming the agent you would
need to find out what the Java equivilent of getenv() is.
If this is not TCP/IP client/server (e.g., if this is running through
pipes or unix domain sockets) with both server and agent on the same
machine, your options are system-dependant. I don't know what can
be done in Windows. In the System V Unix family, there is no (or at least
traditionally was no) mechanism to find out about the environment
of another process; I don't know about the historical BSD family of
Unices. In -some- Unix or Unix-like operating systems (SGI IRIX,
Linux I think, possibly others), a process which starts another
process has (clumsy) mechanisms available to get at the memory
and environment of the child process; these mechanisms may also
be available to processes running under high levels of authorization
(e.g., 'root') with respect to arbitrary other processes on the same
system. But if you are thinking about anything even close to
this, then you are solving completely the wrong problem!
[/OT]
Why not solve the problem a completely different way?
1) use tmpname() to generate a temporary file name (this is ANSI C).
2) strcat() that filename onto the end of the string "echo \\\\ > "
(this is ANSI C).
3) Use system(NULL) to find out whether there is a shell there at all.
(this is ANSI C).
4) If there is a shell, system() the string generated in step (2).
ANSI C promises you can submit the string; it doesn't make any promises
about how the shell will interpret the string. check the return value of
the system() command; if it didn't work, then this mechanism cannot be
used so break out of this sequence.
5) try to open and read the filename generated in (1). If you are able
to open it and able to read it, then check to see how many \ it contained.
If it contains a single \ then you know that whatever shell is being
used is translating \\ into \ ; if the file contains two \ then you
know that the shell is treating each \ literally.
Close and remove the temporary file afterwards.
This arrangement won't work on -every- machine, especially as not
every machine will have an 'echo' shell command, but it will work on
a wide variety of machines and will directly answer the question of
whether the shell is preserving all \ or not, instead of trying to
answer the round-about question of which shell it is and having an
internal (necessarily incomplete) table of shell names and expected
behaviours, together with the risk that a user might have configured
the shell to act differently than you expect.
