gio wrote:
> If in cmd is specified a relative path, it is relative to the current
> working directory(in this example is X).
>
> There is a way to execute command wich paths are relatives to the
> "otherpath" variable (in this example is Y)?

How about changing the currect working directory before
the system() call and go back to the original
working directory after it?

Just a thought ... Rainer

gio wrote:
> I have a problem and the solution should works under windows and unix
> OS.

> Suppose I have a program ex.c in the directory X (so the current
> working directory of ex.c is X).

Where the program itself is (if 'ex.c' is a program at all, from
the extension I would guess that's a C source file) is absolutely
unrelated to the current working directory. Unless you have changed
the working directory from within your program this is the directory
you were in when you started the program, not the one where the
program itself is. E.g. if you start the program 'ls', which is in
/bin, and you start it from your home directory the working directory
is your home directory, not /bin.

> Also suppose I have this code fragment:
> ...
> char otherpath[PATHLEN];
> char cmd[CMDLEN];
> ...
> ...
> otherpath="Y" //where y is a valid path string
> ...
> system(cmd); //where cmd is any command string
> ...

> If in cmd is specified a relative path, it is relative to the current
> working directory(in this example is X).

Yes, it's relative to the current working directory but if that is
'X' isn't something you can assume just because 'ex.c' is in 'X'.
If you start 'ex.c' while being in 'Z' then 'Z' is the working
directory and all relative paths are relative to 'Z', not 'X'. For
that reason using a relative path in a command you try to execute
with system() is a rather bad idea. (And, by the way, if you come
up with the idea to change the working directory to 'X' to make
the relative path work, forget about it - you won't be able to
find out in a reliable and portable way from within the program
where the file for the program is located.)

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

This could be a solution:

Build a new cmd, e.g.:
char *newcmd = malloc(3+strlen(otherpath)+2+strlen(cmd)+1);
sprintf(newcmd, "cd %s; $s", otherpath, cmd);
then run that command:
system(newcmd);
free(newcmd);

What do you think about?

gio wrote:
> This could be a solution:

> Build a new cmd, e.g.:
> char *newcmd = malloc(3+strlen(otherpath)+2+strlen(cmd)+1);
> sprintf(newcmd, "cd %s; $s", otherpath, cmd);
> then run that command:
> system(newcmd);
> free(newcmd);

> What do you think about?

As long as 'otherpath' is an absolute path that's one of the
possibilites - but if it's a relative path you still have the
same problem as before...

But why do you insist on running the command you want to
start with 'cmd' from with the directory where it is as
the working directory? Normally, a program should be
written in a way that it doesn't matter what it's working
directory is when started. If that is the case you could
simplify the above to

char *newcmd = malloc(strlen(otherpath)+strlen(cmd)+2);
sprintf(newcmd, "%s/%s", otherpath, cmd);
system(newcmd);
free(newcmd);

But again, if 'otherpath' isn't an absolute path this won't
work since then you would again be dependent on the working
directory of the program that does the call of system().

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

> But why do you insist on running the command you want to
> start with 'cmd' from with the directory where it is as
> the working directory?

I have a client-server ftp architeture.
The server is multithread and the client can nivigate the filesystem.
A client starts at the server current directory and the can change its
directory.
The server records the client current directory in a string witouth
call cwd().
If the client wants to execute a command like "ls path" the server
must consider the path relative to the client current drectory.
Is it clear?

Bye

gio wrote:
> > But why do you insist on running the command you want to
> > start with 'cmd' from with the directory where it is as
> > the working directory?

> I have a client-server ftp architeture.
> The server is multithread and the client can nivigate the filesystem.
> A client starts at the server current directory and the can change its
> directory.
> The server records the client current directory in a string witouth
> call cwd().
> If the client wants to execute a command like "ls path" the server
> must consider the path relative to the client current drectory.
> Is it clear?

Yes;-) Your basic problem is that you want the server to be multi-
threaded. If you just would fork of new instances for each client
things would be a lot easier because then you could simple set the
current working directory to wherever the client wants go and you
could avoid all those contortions...

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

On Mar 21, 10:27 am, "gio" wrote:

> I have a client-server ftp architeture.

Okay.

> The server is multithread and the client can nivigate the filesystem.
> A client starts at the server current directory and the can change its
> directory.

That's fine, just store what directory the client is in and change the
stored value. Do not ever change the program's working directory.

> The server records the client current directory in a string without
> call cwd().

Perfect.

> If the client wants to execute a command like "ls path" the server
> must consider the path relative to the client current drectory.
> Is it clear?

You're talking about a case where the client can execute an arbitrary
command or a canned command from a list of commands? If it's a canned
command from a list of commands, just convert the path to the correct
path before you execute the command. (Or better yet, build the command
in.)

If you're talking about allowing the user to execute any command they
want, then you have to set up *everything* in the process that will
run the user's command. The working directory is the *least* of your
problems. You must set up the correct user ID, the correct groups, and
so on. One way to do this is to 'fork', set things up in the child,
and then 'exec' the requested command.

DS