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:
Then, in the main-process, the pipes are set for IPC:
Afterwards, the content of a text-file is fed to the STDIN of the running external program.
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

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

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.

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.

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

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.

You could set an Environment variable or pass it in using 'execvpe' which the child can test with 'getenv'
You could have a simple protocol for the stdin, say start a line with a token and work accordingly:

GBP .....
USD .....
CHF .....

simplicity

Yes. I will consider this.
For the time, I have evaded the situation that I hoped to handle by additional program arguments, i.e. evaded the need for FLNews to talk to a post-processor application, by imposing more configuration to the end-user. The (more or less) result of my endeavor is https://rubygems.org/gems/flnews_post_proc.

Very old blog I wrote about fork() and exec() and passing arguments to the child.

https://www.linuxquestions.org/quest...ocesses-35540/

Skip to the section titled Creating Child Processes for a description of what you're asking about.

There's another blog about the use of select() to wait on data from pipes.

I must read it again and maybe once more during my own experimenting, but that is a cool doc.

what you are speaking about is (are) two different things.
You can specify command line arguments when you start a program to pass parameters to it.
You can use pipes (for example) to communicate with a running process, for example send some data/command to it and also it may respond using pipe.

1 members found this post helpful.

I will mark this thread as [Solved] for now.

While my solution to use a permanent configuration instead of parameters for the child process is much less flexible than the communication via pipes, it has however clarified for me that the optional behavior that I want to enable, should not be part of the main program. It should probably not be in the responsibility of the latter to prepare alterations in the called routine, and – as the programmer cannot know what users might want from the child process – should not be changed to allow them.

I will experiment with a graphical input dialog (which may again become optional), where a user can choose to override standard behavior, if needed. After that, “sophistry” might become a better title for my thread. It is a little inconvenient that I did not need any GUI-elements until now and that the GUI-library used in the man program (fltk) is none of my closer friends. I shall instead check the system for Yad and Zenity and call one of those, if available.

Thank you, I have learned a few things – and remembered others – by this thread.