[system]

[Richard Nixon]

I'll just be in and out with a quick question.

If you have an unzip32.exe and a.zip in the same directory as the ensuing
executable, what source in c++ imitates the following pseudo-source:

#include <stdio.h>

int main(void)

system " unzip32 " "a.zip"

end program

I have another question:

What's new and nice in c plus plus?

--
Richard Milhous Nixon

A good memory and a tongue tied in the middle is a combination which gives
immortality to conversation.
~~ Mark Twain

[Victor Bazarov]

Richard Nixon wrote:

If you have an unzip32.exe and a.zip in the same directory as the ensuing
executable, what source in c++ imitates the following pseudo-source:

#include <stdio.h>

int main(void)

system " unzip32 " "a.zip"

end program

I believe 'system' is declared in <stdlib.h>, not <stdio.h(that's in
C, BTW). So, add a couple of curly braces and parentheses and you might
even get your program right there...

#include <stdlib.h>

int main(void)
{
system("unzip32 a.zip");
return 0;
}

Whether it imitates anything or not, I am not sure. The behaviour of
the 'system' function is implementation-defined, so nothing really we
can say for sure of the outcome of that program. Sorry about that!

I have another question:

What's new and nice in c plus plus?

Many things. How many years are you prepared to spend learning them?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Oct 15, 4:14 am, Victor Bazarov <[e-mail]:

Richard Nixon wrote:

If you have an unzip32.exe and a.zip in the same directory
as the ensuing executable, what source in c++ imitates the
following pseudo-source:

#include <stdio.h>

int main(void)

system " unzip32 " "a.zip"

end program

I believe 'system' is declared in <stdlib.h>, not <stdio.h>
(that's in C, BTW).

There's a <stdlib.hin C++ as well. And a <cstdlibwith
std::system, for those who prefer it.

So, add a couple of curly braces and parentheses and you might
even get your program right there...

#include <stdlib.h>

int main(void)
{
system("unzip32 a.zip");
return 0;
}

Whether it imitates anything or not, I am not sure. The
behaviour of the 'system' function is implementation-defined,
so nothing really we can say for sure of the outcome of that
program. Sorry about that!

Well, he sort of provided the system dependent part. The real
problem he'll probably run into is that unzip32.exe and a.zip
are in the same directory as his executable, which is not
necessarily the diretory in which his code is running. There's
definitely nothing in C++ which supports finding where the
executable was actually started. The closest you can come is to
try parsing argv[0] (which is supposed to contain the name used
to invoke the program---but in practice doesn't always), then
emulating the way the system looks up executables---a lot of
work, not completely portable, and in practice, not necessarily
reliable. On specific platforms, you may have something in the
system API which would help (try GetModuleFileNameEx(
GetCurrentProcess(), NULL, ... ) under Windows---I don't know of
anything similar under Unix, however).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Paavo Helde]

James Kanze <ja*********@gmail.comkirjutas:

There's
definitely nothing in C++ which supports finding where the
executable was actually started. The closest you can come is to
try parsing argv[0] (which is supposed to contain the name used
to invoke the program---but in practice doesn't always), then
emulating the way the system looks up executables---a lot of
work, not completely portable, and in practice, not necessarily
reliable. On specific platforms, you may have something in the
system API which would help (try GetModuleFileNameEx(
GetCurrentProcess(), NULL, ... ) under Windows---I don't know of
anything similar under Unix, however).

In general, there is no way to relate an (unstarted executable, or any
other) file to a certain directory. In Unix filesystems there are
hardlinks and mounts, and on Windows there are subst commands, network
drive mapping, etc, which mean that the same file can have multiple
directory paths. However, when launching the application, the kernel
finds it in a certain directory path, and this information might be
useful for the application. Windows makes it available through the
GetModuleFileName[Ex]() function (as you said) and Linux makes it
available through the /proc/PID/exe or /proc/self/exe, which is probably
more reliable than argv[0]. In both cases this is a piece of dynamic
information related to the process creation by the kernel.

Paavo

[James Kanze]

On Oct 23, 12:28 am, Paavo Helde <[e-mail]:

James Kanze <[e-mail]:

There's definitely nothing in C++ which supports finding
where the executable was actually started. The closest you
can come is to try parsing argv[0] (which is supposed to
contain the name used to invoke the program---but in
practice doesn't always), then emulating the way the system
looks up executables---a lot of work, not completely
portable, and in practice, not necessarily reliable. On
specific platforms, you may have something in the system API
which would help (try GetModuleFileNameEx(
GetCurrentProcess(), NULL, ... ) under Windows---I don't
know of anything similar under Unix, however).

In general, there is no way to relate an (unstarted
executable, or any other) file to a certain directory.

Portably. For a number of systems (including Windows and most
Unix), there is a system specific way, but it's not portable;
even within the Unix community, different Unix may do it
differently.

In Unix filesystems there are hardlinks and mounts, and on
Windows there are subst commands, network drive mapping, etc,
which mean that the same file can have multiple directory
paths.

Which isn't necessarily a problem, as long as you can find one
of them.

However, when launching the application, the kernel finds it
in a certain directory path, and this information might be
useful for the application. Windows makes it available through
the GetModuleFileName[Ex]() function (as you said) and Linux
makes it available through the /proc/PID/exe or
/proc/self/exe, which is probably more reliable than argv[0].

But is pure Linux; there's no /proc/self under Solaris, for
example.

For some programs, it might be sufficient to search for argv[0]
in PATH environment variable; it's certainly not 100% reliable,
but it will cover a lot of use case scenarios. Of course, you
still have the portability issue that the path separator under
Unix is :, under Windows ;, and that the directory separator
must be / under Unix, but can be either \ or / under Windows
(and that an initial <alpha>: has a special meaning, and that
some files systems are case insensitive, others case sensitive).

If you control the installation, of course, the simplest
solution under Windows is to put such information in the
registry, during installation. Under Unix, a lot of programs
require you to set an environment variable, something like
MYPROG_HOME, which specifies the installation root.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]