system() function and current working directory

[gio]

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).

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).

There is a way to execute command wich paths are relatives to the
"otherpath" variable (in this example is Y)?

 

[Lew Pitcher]

I have a problem and the solution should works under windows and unix
OS.

OK, so you are looking for a "portable" solution.

Suppose I have a program ex.c in the directory X (so the current
working directory of ex.c is X). [snip]
There is a way to execute command wich paths are relatives to the
"otherpath" variable (in this example is Y)?

Unfortunately (for you), standard C does not recognize (let alone
provide tools to manipulate) directories or program execution paths.
Your answer lies elsewhere, as we can't help you here.

<OT>
It is likely that you will not find a simple, portable solution to
your program that will work without modification in both the Unix and
Windows environments. For Unix,
system("PATH=Y:$PATH cmd");
may work. However, it is unlikely that this trick in the shell will
work for Windows.
</OT>

HTH

 

[gio]

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?

 

[Richard Heathfield]

gio said:

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?

Looks good except for the failure to take into account the possibility
that malloc fails and returns NULL.

 

[Richard Bos]

also it ignores the fact that in UNIX the current directory is not searched,
unless being part of the PATH envionment-variable

And that on Windows, it may or may not work depending on the format of
the path string.

Richard

 

[gio]

And that on Windows, it may or may not work depending on the format of
the path string.

The solution should be portable.
Please can you tell me what is the problem of format of path on
Windows?

 

[Walter Roberson]

gio said:

Looks good except for the failure to take into account the possibility
that malloc fails and returns NULL.

It also uses $s as a format descriptor to write out cmd
in the sprintf. Should be %s .

Also, you usually do not want to cd to the directory of the
executable, as your datafiles are usually back where you started.
And as the other pointer indicated, the current directory might
not be on the PATH.

Take care in Windows, where changing drive letters must be done
in a seperate cd from changing the directory.

This calls for something closer to
sprintf(newcmd, "%s%s%s", otherpath, pathsep, cmd )
where pathsep is the path seperator (e.g., "/" for unix, "\\"
for Windows.); the path seperator is only required here
if the otherpath variable does not already terminate with the
proper seperator.

Regretably, there is no C standard way to detect
whether you are in unix or Windows, so there is no C portable
way to decide what the path seperator is with certainty. Worse yet,
it could vary according to branch of the filesystem you are
visiting. <OT>I thought I remembered a POSIX pathconf() that returned
the seperator, but my references indicate otherwise.</OT>

 

[SM Ryan]

# I have a problem and the solution should works under windows and unix
# OS.

I doubt you can do this is pure ANSI C without some tricky
uses of system(...). Then what you end up with is something like

#if defined(Unix)
system(...); FILE* f = ...;
system(...); FILE* f = ...;
...
#elif defined(Windows)
system(...); FILE* f = ...;
system(...); FILE* f = ...;
...
....

If you're going to do that, you might as well make system specific
function calls, shielded behind their #ifdefs, for each flavour
of system. Also there are already libraries and interpretters out there
like Perl or Tcl that do much of this behind a unified system
independent interface on a variety systems. Rather than reinventing
their work, you might leverage off of it.

 

[Joachim Schmitz]

gio said:


Looks good except for the failure to take into account the possibility
that malloc fails and returns NULL.

also it ignores the fact that in UNIX the current directory is not searched,
unless being part of the PATH envionment-variable

Bye. Jojo

 

[Joachim Schmitz]

The solution should be portable.
Please can you tell me what is the problem of format of path on
Windows?

in Windows it would have \ where UNIX would have /

Bye, Jojo

 

[gio]

To be more clear this is my problem:
I'm implementing ftp client-server.
The server is multithread.
Each client can navigates the filesystem beginning on the server
working directory.
For each cliet the server have a path variable to store the client
"virtual" working directory and when a client does cd(change
directory), the server update this variable.
Suppose a client is in the dir "minny" and that wants execute a
command(for example ls) witouth specifing a path.
in this way, if the server' s current directory is "X", the call
system("ls") will list the "x"directory, but it should list the
"minny" directory.

THE PROBLEM IS NOT THE SEARCH OF EXECUTABLE.

THANKS FOR YOUR EFFORTS

 

[Walter Roberson]

I'm implementing ftp client-server.

For each cliet the server have a path variable to store the client
"virtual" working directory and when a client does cd(change
directory), the server update this variable.
Suppose a client is in the dir "minny" and that wants execute a
command(for example ls) witouth specifing a path.
in this way, if the server' s current directory is "X", the call
system("ls") will list the "x"directory, but it should list the
"minny" directory.

THE PROBLEM IS NOT THE SEARCH OF EXECUTABLE.

If you have the search for the executable down already (and
have taken into account that there might happen to be an
executable in the directory with the same name that isn't
the one you want!), then you still have the cross-platform
problem that windows "cd" command does not allow you
to switch drive letters on the same command as you switch directories.

The basic tactic of system() of "cd %s;ls" is fine for unix
if you have scrubbed the virtual path for security reasons,
like not allowing a virtual path that contains ";cat /etc/passwd" .
But windows is not as friendly.


I would suggest that since you are going to have some
system specific portions, that you may wish to require a
couple of minor system extensions, available in POSIX for example,
and use the chdir() extension call; you might find that even
on Windows it allows you to switch drives at the same time.
(Maybe. I don't program on Windows, so check the documentation.)

 

[CBFalconer]

.... snip ...

If you have the search for the executable down already (and
have taken into account that there might happen to be an
executable in the directory with the same name that isn't
the one you want!), then you still have the cross-platform
problem that windows "cd" command does not allow you to switch
drive letters on the same command as you switch directories.

But if you install a decent shell, such as 4DOS or 4NT, you have
the cdd command to do just that.

 

[Richard Bos]

[ Don't over-strip attributions. ]

The solution should be portable.

You miss the point: there _is_ no portable solution.

Richard

 

[David Thompson]

If you have the search for the executable down already (and
have taken into account that there might happen to be an
executable in the directory with the same name that isn't
the one you want!), then you still have the cross-platform
problem that windows "cd" command does not allow you
to switch drive letters on the same command as you switch directories.

As of W2k at least (not sure about NT and can no longer test)
cd/d does. You still have the issue that the pathname specified to
Windows cd, with or without drive letter, uses \ versus Unix /.
(Windows _API calls_ can use /.) And the command separator is & vs ;
in Unix (or at least in all Unix shells I'm familiar with).