Echoing the above sentiment ... in Perl circles we have a saying,
TMTOWTDI = There's More Than One Way To Do It.™ And, this should give you pause.
Think very carefully about what exactly it is that you want to
achieve, and exactly why. What is, if you will, the
business purpose?
There are "several ways to do it," if you put your thinking-cap on. One of those, certainly,
might be "to do, programmatically in C, what the user can already do in the Unix/Linux shell." But ... that is
not "the only way," certainly, and it might well not be the best one. Think again in business terms:
- What is the 'return on investment (ROI)' ?
- What is the 'business risk,' and is that risk acceptable?
- Is the money that will be spent in having a developer (i.e. "you") do it ... "money well-spent?" (Never mind if it actually does, or does not, "cost money.")
If I were your project-manager, I think that I'd probably nix the idea, because I'd be rather unconvinced that it was a good use of your time. Although, of course, I have no idea what your actual situation is, and therefore, whether I'd actually do such a thing or not.
So, let's just say that "alarm bells are going off in my head" right now, and perhaps should also be going-off in yours. Those alarms are suggesting to me that maybe you just haven't turned-over all the toadstools yet. That there just might be an equally-satisfactory way to do it which might cost nothing at all.
Trying to put my finger on it ...
"why is an application doing the shell's job?" Yeah, that might be 'it.'