By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,130 Members | 1,359 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,130 IT Pros & Developers. It's quick & easy.

system() function and current working directory

P: n/a
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)?

Mar 21 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
On Mar 21, 9:18 am, "gio" <giorginooo.ro...@yahoo.itwrote:
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
--
Lew

Mar 21 '07 #2

P: n/a
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?

Mar 21 '07 #3

P: n/a
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 Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 21 '07 #4

P: n/a
"Richard Heathfield" <rj*@see.sig.invalidschrieb im Newsbeitrag
news:4N******************************@bt.com...
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.
also it ignores the fact that in UNIX the current directory is not searched,
unless being part of the PATH envionment-variable

Bye. Jojo
Mar 21 '07 #5

P: n/a
"Joachim Schmitz" <no************@hp.comwrote:
"Richard Heathfield" <rj*@see.sig.invalidschrieb im Newsbeitrag
news:4N******************************@bt.com...
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.
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
Mar 21 '07 #6

P: n/a
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?

Mar 21 '07 #7

P: n/a
In article <4N******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>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);
>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>

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
Mar 21 '07 #8

P: n/a
"gio" <gi**************@yahoo.itwrote:
# 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.
Mar 21 '07 #9

P: n/a
"gio" <gi**************@yahoo.itschrieb im Newsbeitrag
news:11**********************@n59g2000hsh.googlegr oups.com...
>
>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?
in Windows it would have \ where UNIX would have /

Bye, Jojo
Mar 21 '07 #10

P: n/a
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

Mar 21 '07 #11

P: n/a
In article <11**********************@o5g2000hsb.googlegroups. com>,
gio <gi**************@yahoo.itwrote:
>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.)
--
Programming is what happens while you're busy making other plans.
Mar 22 '07 #12

P: n/a
Walter Roberson wrote:
>
.... 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 22 '07 #13

P: n/a
"gio" <gi**************@yahoo.itwrote:

[ Don't over-strip attributions. ]
And that on Windows, it may or may not work depending on the format of
the path string.

The solution should be portable.
You miss the point: there _is_ no portable solution.

Richard
Mar 22 '07 #14

P: n/a
On Wed, 21 Mar 2007 23:57:46 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
<snip: OP wants system() to cd somewhere and do something>
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).

Apr 15 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.