In good old days the Turbo Pascal had an EXEC procedure that could execute another program by invoking the DOS command interpreter.

In better new days the FPC does not seem to have such an option, or I couldn’t find it in the docs.
Now I am particularly interested in doing such a thing in a Linux system.

I have found in the unix unit a function FPEXECV(path, pp) that may be used for it, but it leaves a few questions to me.

According to the docs the function does not return (if it succeeds). Is there no way of calling another program and then continue the calling program? Could it be done by starting a new thread, putting the call into that thread and let that thread not return while the main program continues? Will it leave allocated memory, that is never freed?

If the function does not return, why is there a return integer value defined?
(Or: why is it called a function, when it does not return?)

In the doc’s example the FPEXECV(path, pp) has the same pchar in the path and as the first pchar of the pchar array that pp points to. I have tried similar examples, and they always seem to work with the same phar in the two places, but not otherwise. Is there some deeper philosophy in having the program-name in both path and in the first phar of the array?

Hans Maartensson

Hans Mårtensson wrote

In good old days the Turbo Pascal had an EXEC procedure that could execute another program by invoking the DOS command interpreter.

I think that function is in the DOS unit. And it even works in Linux!

You must call fork() first an then call execv from the child process.

If the function does not return, why is there a return integer value defined? (Or: why is it called a function, when it does not return?)

Who knows?

In good old days the Turbo Pascal had an EXEC procedure that could execute another program by invoking the DOS command interpreter.

Dos.exec still exist, but as a substitute sysutils.ExecuteProcess is recommended. (1.9.2+ though)

Note that both don't exec the command itself.

See the earlier replies (and the source of executeprocess)

Note that fp* calls are calls that roughly comply to unix standards. A man page for the call minus the "fp" is usually available. (so "man execv" in this case). From the FreeBSD version:

..... The
first argument, by convention, should point to the file name associated with the file being executed. The list of arguments must be terminated by a NULL pointer.....

So the answer is "by convention" :-)

Also have a look at the tprocess class in the VCL, it allows for executing processes and keeping pipes to it open.

Only if these two instruments (tprocess/executeprocess) are not enough, then you need to mess with OS specific routines like execv, or windows like shellexecute.

Note that both don't exec the command itself.

Clarification: the commandPROCESSOR, so cmd.exe or /bin/sh.

Thank you for the information
Sometimes the docs looks like a haystack with no needle. (According to my view)

Until recently I have only made win32 programs. Now I am trying to do something on a Linux box. And I was surprised that the Linux version of FPC had the same units. Even the DOS unit works on the Linux system? Wonderful!

Thank you
Hans Mårtensson

The more normal functions yes. Dos interrupt calls of course don't work.

However please use executeprocess, it will avoid problems with too deeply nested paths. (dos.exec is limited to an overall 255 chars).

Marco van de Voort wrote

However please use executeprocess, it will avoid problems with too deeply nested paths. (dos.exec is limited to an overall 255 chars).

Yes I got that - and that is exactly the function I need for my program, I think.