Wrapping existing UNIX commands in C

Discussion in 'C Programming' started by Chicken McNuggets, Jul 29, 2012.

  1. Hi,

    So I am aware of the exec family of functions and the system function to
    execute external commands but they do not seem to offer the
    functionality to allow me to get the output of said executable so I can
    use it in the rest of my program. For instance a simple example would be
    to use the "ls" command. I would want to get the output of the directory
    listing and be able to manipulate it later on in my program.

    Is there an easy way to do this? I realise that this is technically not
    standard C and is most likely a POSIX extension but it would be nice if
    someone could offer some advice.

    Thanks.
    Chicken McNuggets, Jul 29, 2012
    #1
    1. Advertising

  2. Chicken McNuggets

    Eric Sosman Guest

    On 7/29/2012 11:11 AM, Chicken McNuggets wrote:
    > Hi,
    >
    > So I am aware of the exec family of functions and the system function to
    > execute external commands but they do not seem to offer the
    > functionality to allow me to get the output of said executable so I can
    > use it in the rest of my program. For instance a simple example would be
    > to use the "ls" command. I would want to get the output of the directory
    > listing and be able to manipulate it later on in my program.
    >
    > Is there an easy way to do this? I realise that this is technically not
    > standard C and is most likely a POSIX extension but it would be nice if
    > someone could offer some advice.


    "Technically not Standard C" is an understatement: There is no
    aspect of your question that has anything at all to do with C.[*]

    [*] No, not even the passing mention of system() qualifies this
    as a C question. On some platforms it is possible to use system()
    to run a program and have the output go to a file the invoking
    program can then open and read, but the form of the argument that
    gets system() to do this is entirely platform-specific.

    Try comp.unix.programmer.

    --
    Eric Sosman
    d
    Eric Sosman, Jul 29, 2012
    #2
    1. Advertising

  3. "Chicken McNuggets" <> schrieb im Newsbeitrag
    news:jv3jqk$r1t$...
    > Hi,
    >
    > So I am aware of the exec family of functions and the system function to
    > execute external commands but they do not seem to offer the functionality
    > to allow me to get the output of said executable so I can use it in the
    > rest of my program. For instance a simple example would be to use the "ls"
    > command. I would want to get the output of the directory listing and be
    > able to manipulate it later on in my program.
    >
    > Is there an easy way to do this? I realise that this is technically not
    > standard C and is most likely a POSIX extension but it would be nice if
    > someone could offer some advice.
    >
    > Thanks.


    Do you also know pipes?

    if ((fp = popen("ls")) != NULL)
    {
    while (fgets(Buffer, sizeof(Buffer), fp))
    puts(Buffer);
    fclose(fp);
    }
    Heinrich Wolf, Jul 29, 2012
    #3
  4. On 29/07/2012 16:20, Heinrich Wolf wrote:

    > Do you also know pipes?
    >
    > if ((fp = popen("ls")) != NULL)
    > {
    > while (fgets(Buffer, sizeof(Buffer), fp))
    > puts(Buffer);
    > fclose(fp);
    > }


    Ah. Thank you. popen() looks exactly like what I was looking for.
    Chicken McNuggets, Jul 29, 2012
    #4
  5. On 29/07/2012 16:18, Eric Sosman wrote:

    >
    > "Technically not Standard C" is an understatement: There is no
    > aspect of your question that has anything at all to do with C.[*]
    >
    > [*] No, not even the passing mention of system() qualifies this
    > as a C question. On some platforms it is possible to use system()
    > to run a program and have the output go to a file the invoking
    > program can then open and read, but the form of the argument that
    > gets system() to do this is entirely platform-specific.
    >
    > Try comp.unix.programmer.
    >


    Apologies for being so off-topic.
    Chicken McNuggets, Jul 29, 2012
    #5
  6. On 29-Jul-12 10:11, Chicken McNuggets wrote:
    > So I am aware of the exec family of functions and the system function to
    > execute external commands but they do not seem to offer the
    > functionality to allow me to get the output of said executable so I can
    > use it in the rest of my program. For instance a simple example would be
    > to use the "ls" command. I would want to get the output of the directory
    > listing and be able to manipulate it later on in my program.
    >
    > Is there an easy way to do this? I realise that this is technically not
    > standard C and is most likely a POSIX extension but it would be nice if
    > someone could offer some advice.


    If you've already decided to limit portability to POSIX systems, pipes
    are the general solution for what you're trying to do, but may not be
    the optimal solution. For instance, in the case of "ls", why not just
    call the functions in <dirent.h> yourself rather than opening a pipe to
    a program that calls them for you and then writing an enormous amount of
    code to parse its output to extract the same data?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Jul 29, 2012
    #6
  7. In article <jv3k82$92v$>,
    Eric Sosman <> wrote:
    >On 7/29/2012 11:11 AM, Chicken McNuggets wrote:
    >> Hi,
    >>
    >> So I am aware of the exec family of functions and the system function to
    >> execute external commands but they do not seem to offer the
    >> functionality to allow me to get the output of said executable so I can
    >> use it in the rest of my program. For instance a simple example would be
    >> to use the "ls" command. I would want to get the output of the directory
    >> listing and be able to manipulate it later on in my program.
    >>
    >> Is there an easy way to do this? I realise that this is technically not
    >> standard C and is most likely a POSIX extension but it would be nice if
    >> someone could offer some advice.

    >
    > "Technically not Standard C" is an understatement: There is no
    >aspect of your question that has anything at all to do with C.[*]


    blah, blah, blah, like a biddy old aunt - who hasn't gotten any since the
    war (WWII, that is).

    Isn't it funny how, in the rest of the Usenet (and online forums in
    general), the ethic is "If you can't answer the question, then STFU!", but
    here in comp.lang.c, people still get mileage out of:

    Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

    --
    Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
    an 8 bit operating system based on a 4 bit architecture from a 2 bit company
    that can't stand 1 bit of competition.

    Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
    tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
    operating system based on a 4 bit architecture from a 2 bit company that
    can't stand 1 bit of competition.
    Kenny McCormack, Jul 29, 2012
    #7
  8. "China Blue [Tor], Meersburg" <> writes:
    > In article <jv3k82$92v$>,
    > Eric Sosman <> wrote:
    >> On 7/29/2012 11:11 AM, Chicken McNuggets wrote:
    >> > So I am aware of the exec family of functions and the system function to
    >> > execute external commands but they do not seem to offer the
    >> > functionality to allow me to get the output of said executable so I can
    >> > use it in the rest of my program. For instance a simple example would be
    >> > to use the "ls" command. I would want to get the output of the directory
    >> > listing and be able to manipulate it later on in my program.
    >> >
    >> > Is there an easy way to do this? I realise that this is technically not
    >> > standard C and is most likely a POSIX extension but it would be nice if
    >> > someone could offer some advice.

    >>
    >> "Technically not Standard C" is an understatement: There is no
    >> aspect of your question that has anything at all to do with C.[*]

    >
    > That's odd, because we have been doing this in C since the 1970s.


    But you haven't been doing it in *standard* C. (Well, prior to 1989
    there was no standard.)

    Of course there's nothing wrong with writing non-standard C; the
    ability to write system-specific code is one of the language's
    greatest strengths. And yes, POSIX is also a standard. But as
    you probably know, the people who know about it tend to hang out
    in comp.unix.programmer, not in comp.lang.c

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jul 29, 2012
    #8
  9. Chicken McNuggets

    Ike Naar Guest

    On 2012-07-29, Heinrich Wolf <> wrote:
    > if ((fp = popen("ls")) != NULL)
    > {
    > while (fgets(Buffer, sizeof(Buffer), fp))
    > puts(Buffer);
    > fclose(fp);


    pclose(fp); ?
    Ike Naar, Jul 29, 2012
    #9
  10. Chicken McNuggets

    Ike Naar Guest

    On 2012-07-29, China Blue [Tor], Meersburg <> wrote:
    > system("mkfifo ../pipe");
    > FILE *ls = open("../pipe", "r");


    FILE *ls = fopen("../pipe", "r"); ?
    Ike Naar, Jul 29, 2012
    #10
  11. Chicken McNuggets

    Rui Maciel Guest

    China Blue [Tor], Meersburg wrote:

    > Did you know comp.lang.c predates 1989? And that we weren't obnoxious
    > twits back then?


    Well, it appears that you are now contributing for that turn of events.


    > Are you happy you're wasting more electrons being a dick
    > than where spent just giving a straightfotward and useful answer?


    If you took the time to actually read what has been repeatedly pointed out
    to you, you would notice that the replies you've got were actually straight
    forwrad and useful. It's pretty obvious that you would be better served if
    you posted questions regarding unix APIs to a newsgroup dedicated to unix
    programming. Yet, instead of following that advice you decided to ignore it
    and instead waste "more electrons being a dick", as you've put it. Go
    figure.


    Rui Maciel
    Rui Maciel, Jul 30, 2012
    #11
  12. "Ike Naar" <> schrieb im Newsbeitrag
    news:...
    > On 2012-07-29, Heinrich Wolf <> wrote:
    >> if ((fp = popen("ls")) != NULL)
    >> {
    >> while (fgets(Buffer, sizeof(Buffer), fp))
    >> puts(Buffer);
    >> fclose(fp);

    >
    > pclose(fp); ?


    Yes of course. I am sorry.
    Heinrich Wolf, Jul 30, 2012
    #12
  13. "Heinrich Wolf" <> schrieb im Newsbeitrag
    news:jv3kb3$fk6$-online.net...

    ....

    > if ((fp = popen("ls")) != NULL)


    popen("ls", "r")

    > {
    > while (fgets(Buffer, sizeof(Buffer), fp))
    > puts(Buffer);
    > fclose(fp);


    pclose in place of fclose

    > }


    I'm sorry.
    My code is untested.
    Heinrich Wolf, Jul 30, 2012
    #13
  14. On Jul 29, 10:00 pm, "China Blue [Tor], Meersburg"
    <> wrote:
    > In article <>, Keith Thompson <>
    > > "China Blue [Tor], Meersburg" <> writes:
    > > > In article <jv3k82$>,
    > > >  Eric Sosman <> wrote:
    > > >> On 7/29/2012 11:11 AM, Chicken McNuggets wrote:


    > > >> > So I am aware of the exec family of functions and the system function to
    > > >> > execute external commands but they do not seem to offer the
    > > >> > functionality to allow me to get the output of said executable so I can
    > > >> > use it in the rest of my program. For instance a simple example would be
    > > >> > to use the "ls" command. I would want to get the output of the directory
    > > >> > listing and be able to manipulate it later on in my program.

    >
    > > >> > Is there an easy way to do this? I realise that this is technically not
    > > >> > standard C and is most likely a POSIX extension but it would be nice if
    > > >> > someone could offer some advice.

    >
    > > >>      "Technically not Standard C" is an understatement: There is no
    > > >> aspect of your question that has anything at all to do with C.[*]

    >
    > > > That's odd, because we have been doing this in C since the 1970s.


    how would I do this on a Windows system?

    > > But you haven't been doing it in *standard* C.  (Well, prior to 1989
    > > there was no standard.)

    >
    > > Of course there's nothing wrong with writing non-standard C; the
    > > ability to write system-specific code is one of the language's
    > > greatest strengths.  And yes, POSIX is also a standard.  But as
    > > you probably know, the people who know about it tend to hang out
    > > in comp.unix.programmer, not in comp.lang.c

    >
    > Did you know comp.lang.c predates 1989? And that we weren't obnoxious twits back
    > then? Are you happy you're wasting more electrons being a dick than wherespent
    > just giving a straightfotward and useful answer?


    where was your "straightfotward and useful answer"?

    > Do you know that you are
    > allowed to create a moderated newsgroup that is actually moderated instead of
    > flouncing around on an unmoderated newsgroup?
    Nick Keighley, Jul 30, 2012
    #14
  15. Chicken McNuggets

    jacob navia Guest

    Le 29/07/12 23:00, China Blue [Tor], Meersburg a écrit :
    > In article <>, Keith Thompson <>
    > wrote:
    >
    > Did you know comp.lang.c predates 1989? And that we weren't obnoxious twits back
    > then?


    Of course! We were 22 years younger!

    Some people tend to change for the worst when they get old... They
    forget what youth means, even.

    > Are you happy you're wasting more electrons being a dick than where spent
    > just giving a straightfotward and useful answer? Do you know that you are
    > allowed to create a moderated newsgroup that is actually moderated instead of
    > flouncing around on an unmoderated newsgroup?
    >


    Nobody has appointed Mr Thompson as a moderator of this group but he
    is playing the moderator since such a long time that somehow people
    (including me) got used to that situation.

    Happily he tells everywhere that I am in his killfile so that now
    he can't answer my postings, so I can say and do whatever I want.

    :)

    You should try the same solution: just get into his killfile and then
    you will live happily thereafter.
    jacob navia, Jul 30, 2012
    #15
  16. Chicken McNuggets

    Nobody Guest

    On Sun, 29 Jul 2012 11:57:32 -0500, Stephen Sprunk wrote:

    > If you've already decided to limit portability to POSIX systems, pipes
    > are the general solution for what you're trying to do, but may not be
    > the optimal solution. For instance, in the case of "ls", why not just
    > call the functions in <dirent.h> yourself rather than opening a pipe to
    > a program that calls them for you and then writing an enormous amount of
    > code to parse its output to extract the same data?


    Because that requires learning the API, whereas someone who already knows
    about system() and popen() can just write half-baked code and avoid the
    effort of learning to do it correctly.

    I have seen real-world code which did:

    char buf[100];
    sprintf(buf, "rm %s", filename);
    system(buf);
    Nobody, Jul 30, 2012
    #16
  17. Chicken McNuggets

    jacob navia Guest

    Le 30/07/12 13:13, Nobody a écrit :
    > On Sun, 29 Jul 2012 11:57:32 -0500, Stephen Sprunk wrote:
    >
    >> If you've already decided to limit portability to POSIX systems, pipes
    >> are the general solution for what you're trying to do, but may not be
    >> the optimal solution. For instance, in the case of "ls", why not just
    >> call the functions in <dirent.h> yourself rather than opening a pipe to
    >> a program that calls them for you and then writing an enormous amount of
    >> code to parse its output to extract the same data?

    >
    > Because that requires learning the API, whereas someone who already knows
    > about system() and popen() can just write half-baked code and avoid the
    > effort of learning to do it correctly.
    >


    Why is that not correct?

    Why bothering to learn the API, and spend hours debugging a new
    version of "ls"?


    If performance is not a big concern the code below will work correctly
    even if in this case a call to remove() would be shorter.


    > I have seen real-world code which did:
    >
    > char buf[100];
    > sprintf(buf, "rm %s", filename);
    > system(buf);
    >


    Yes, the hard coded buffer size is a problem but in principle
    this thing will work as intended.
    jacob navia, Jul 30, 2012
    #17
  18. jacob navia <> writes:

    > Le 30/07/12 13:13, Nobody a écrit :

    <snip>
    >> I have seen real-world code which did:
    >>
    >> char buf[100];
    >> sprintf(buf, "rm %s", filename);
    >> system(buf);

    >
    > Yes, the hard coded buffer size is a problem but in principle
    > this thing will work as intended.


    ....and you just hope that 'filename' does not contain a space, or a '*'
    or a ';' followed by something worse.

    Of course one can imagine an implementation of system that keeps such
    things safe, but I don't know of any.

    --
    Ben.
    Ben Bacarisse, Jul 30, 2012
    #18
  19. Chicken McNuggets

    Mark Bluemel Guest

    On 30/07/2012 12:39, Ben Bacarisse wrote:
    > jacob navia <> writes:
    >
    >> Le 30/07/12 13:13, Nobody a écrit :

    > <snip>
    >>> I have seen real-world code which did:
    >>>
    >>> char buf[100];
    >>> sprintf(buf, "rm %s", filename);
    >>> system(buf);

    >>
    >> Yes, the hard coded buffer size is a problem but in principle
    >> this thing will work as intended.

    >
    > ...and you just hope that 'filename' does not contain a space, or a '*'
    > or a ';' followed by something worse.


    Obligatory XKCD reference follows - <http://xkcd.com/327/>
    Mark Bluemel, Jul 30, 2012
    #19
  20. Chicken McNuggets

    Jorgen Grahn Guest

    On Sun, 2012-07-29, Rui Maciel wrote:
    > China Blue [Tor], Meersburg wrote:
    >
    >> Did you know comp.lang.c predates 1989? And that we weren't obnoxious
    >> twits back then?

    >
    > Well, it appears that you are now contributing for that turn of events.
    >
    >> Are you happy you're wasting more electrons being a dick
    >> than where spent just giving a straightfotward and useful answer?

    >
    > If you took the time to actually read what has been repeatedly pointed out
    > to you, you would notice that the replies you've got were actually straight
    > forwrad and useful.


    As far as I can tell, it wasn't "China Blue" who asked; that guy
    learned about popen() (and comp.unix.programmer, I hope), thanked
    and left.

    I do think the first "this is offtopic, try c.u.p." post could have
    been formulated better.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jul 30, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ben Pfaff

    Re: man pages for C commands (GCC commands)

    Ben Pfaff, Jun 24, 2003, in forum: C Programming
    Replies:
    4
    Views:
    3,966
    Thomas Stegen
    Jun 28, 2003
  2. Tim Stanka
    Replies:
    1
    Views:
    790
    Jeff Epler
    Aug 2, 2004
  3. Replies:
    1
    Views:
    265
    Gabriel Genellina
    Nov 15, 2006
  4. dduck
    Replies:
    11
    Views:
    672
  5. Neville Dempsey
    Replies:
    1
    Views:
    256
    Bruno Desthuilliers
    Sep 1, 2008
Loading...

Share This Page