[C/C++] arguments to child process.

Michael Uplawski · 04-25-2023, 07:49 AM

I am *not* programming this but try to understand a program. I have a feature-request in mind but cannot say, if it makes sense: Allow an external process to receive an optional argument,

Situation as I interpret it:
In a fork()-induced child process, an external routine is started with execl(), posix_execl being an alias:

Code:

posix_execl(path, pathname, (char*) NULL);

Then, in the main-process, the pipes are set for IPC:

Code:

rv = posix_fcntl(fd_out[1], POSIX_F_SETFL, POSIX_O_NONBLOCK);
if(-1 != rv)
  {
     rv = posix_fcntl(fd_in[0], POSIX_F_SETFL, POSIX_O_NONBLOCK);
  }

Afterwards, the content of a text-file is fed to the STDIN of the running external program.

Code:

rv3 = posix_write(fd_out[1], (void*) &content[i], len - i);

My question:
I understand that the external routine receives arguments in the call to execl(). But if the actual content which is piped to STDIN – in the last line of code above – sets a condition, how would you communicate this condition to the external process?

Let's say the content can be of diverse nature and the specific type of content should be known to the external program ...

As I see it, my idea does not justify the profound changes which it would necessitate.

This is basically about execl() and write(), but please say, if my scenario is not clear.

Thank you

dugan · 04-25-2023, 09:26 AM

Quote:

But if the actual content which is piped to STDIN – in the last line of code above – sets a condition, how would you communicate this condition to the external process?

That would be communicated via the actual content that is piped to the external process' STDIN. Which the external process reads and presumably understands.

Did I miss something?

(If you just open a text file and pipe its contents into a child process, then the contents of that file would not be setting a condition. Code in either the parent or child process would be setting the condition).

Michael Uplawski · 04-26-2023, 12:58 PM

Quote:

Originally Posted by dugan

That would be communicated via the actual content that is piped to the external process' STDIN. Which the external process reads and presumably understands.

Did I miss something?

No, but I may have expressed myself poorly. What I am hoping for, is a way to communicate an optional additional value – as an argument – to the external process. It should certainly be possible to define a delimiter and then to append anything to the text which is piped-in to STDIN, but as I would like the additional data to be optional, an argument would probably be better.

As I see it, the “additional data” must already be known upon calling execl() or the whole procedure would have to be changed, in a way that I do not understand and which can have too many consequences. In both cases, I refrain from suggesting a new feature.

dugan · 04-26-2023, 03:17 PM

Are you asking if you could code the child process to take a command-line argument, and also code the parent process to launch it with that command-line argument?

If you're writing the child process, then that's easy.

Michael Uplawski · 04-27-2023, 07:30 AM

Quote:

Originally Posted by dugan

Are you asking if you could code the child process to take a command-line argument, and also code the parent process to launch it with that command-line argument?

If you're writing the child process, then that's easy.

I have done that... but have never used the technique of the program I am talking about: The Newsreader flnews.
My code to launch an external application contained all, the path to the program and all possible arguments. What I see here is a process which is started *without* any arguments but will later processes data that comes in via STDIN, a text in this case.

What I am wondering about is,

whether the arguments could come to existence *only when* the data to pipe into the child process is available
whether this will need a different function than execl(), a modification that I consider too important.
(most of all) whether I miss something and thus cannot (yet) evaluate the consequences of my potential feature request.

Maybe shared memory would help, but I cannot say what the caveats are.

Put another way, my C-knowledge is rotten and dates from many standards ago.

dugan · 04-27-2023, 08:11 AM

Link to the actual code you’re asking us to help you look at.

smallpond · 04-27-2023, 09:07 AM

Command line arguments must exist when the program is started. There is no standard mechanism to add more elements to argv later, or any way to tell a program to look at it's arguments again. Of course you could come up with your own nonstandard way, but it seems far more complicated than other ways to provide input to a program: files, signals, shared memory, sockets, etc.

Michael Uplawski · 04-28-2023, 03:24 AM

Quote:

Originally Posted by smallpond

Command line arguments must exist when the program is started. There is no standard mechanism to add more elements to argv later, or any way to tell a program to look at it's arguments again. Of course you could come up with your own nonstandard way, but it seems far more complicated than other ways to provide input to a program: files, signals, shared memory, sockets, etc.

Thank you.
Without wanting to modify profoundly the program, appending to the pipe appears to be the simplest way to implement my idea. The problem is then only, that the receiving process must be prepared to parse *or to actively ignore* the additional data.

Cheerio.