Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23892 > unrolled thread

Wrapping existing UNIX commands in C

Back to article view | Back to comp.lang.c

Contents

  Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-07-29 16:11 +0100
    Re: Wrapping existing UNIX commands in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-29 11:18 -0400
      Re: Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-07-29 16:24 +0100
      Re: Wrapping existing UNIX commands in C "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-29 08:34 -0700
        Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-07-29 12:05 -0700
          Re: Wrapping existing UNIX commands in C "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-29 14:00 -0700
            Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-07-29 15:19 -0700
            Re: Wrapping existing UNIX commands in C Rui Maciel <rui.maciel@gmail.com> - 2012-07-30 00:35 +0100
              Re: Wrapping existing UNIX commands in C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 14:54 +0000
                Re: Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-07-30 17:15 +0100
                Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-07-30 12:44 -0400
                  Re: Wrapping existing UNIX commands in C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-02 13:51 +0000
            Re: Wrapping existing UNIX commands in C jacob navia <jacob@spamsink.net> - 2012-07-30 11:13 +0200
            Re: Wrapping existing UNIX commands in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 01:59 -0700
      Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-07-29 17:10 +0000
        Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-07-31 14:55 -0700
          Re: Wrapping existing UNIX commands in C jacob navia <jacob@spamsink.net> - 2012-08-01 00:24 +0200
            Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-08-02 06:12 -0700
    Re: Wrapping existing UNIX commands in C "Heinrich Wolf" <invalid@invalid.invalid> - 2012-07-29 17:20 +0200
      Re: Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-07-29 16:24 +0100
      Re: Wrapping existing UNIX commands in C Ike Naar <ike@sverige.freeshell.org> - 2012-07-29 21:41 +0000
        Re: Wrapping existing UNIX commands in C "Heinrich Wolf" <invalid@invalid.invalid> - 2012-07-30 06:46 +0200
      Re: Wrapping existing UNIX commands in C "Heinrich Wolf" <invalid@invalid.invalid> - 2012-07-30 06:49 +0200
    Re: Wrapping existing UNIX commands in C "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-07-29 08:31 -0700
      Re: Wrapping existing UNIX commands in C Ike Naar <ike@sverige.freeshell.org> - 2012-07-29 21:46 +0000
    Re: Wrapping existing UNIX commands in C Stephen Sprunk <stephen@sprunk.org> - 2012-07-29 11:57 -0500
      Re: Wrapping existing UNIX commands in C Nobody <nobody@nowhere.com> - 2012-07-30 12:13 +0100
        Re: Wrapping existing UNIX commands in C jacob navia <jacob@spamsink.net> - 2012-07-30 13:26 +0200
          Re: Wrapping existing UNIX commands in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-30 12:39 +0100
            Re: Wrapping existing UNIX commands in C Mark Bluemel <mark_bluemel@pobox.com> - 2012-07-30 13:16 +0100
              Re: Wrapping existing UNIX commands in C BGB <cr88192@hotmail.com> - 2012-07-30 12:39 -0500
            Re: Wrapping existing UNIX commands in C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 15:02 +0000
          Re: Wrapping existing UNIX commands in C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 15:18 +0000
          Re: Wrapping existing UNIX commands in C Nobody <nobody@nowhere.com> - 2012-07-31 14:53 +0100
          Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-08-02 06:21 -0700
      Re: Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-07-30 18:10 +0100
        Re: Wrapping existing UNIX commands in C Paul <nospam@needed.com> - 2012-07-30 13:30 -0400
        Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-07-30 13:34 -0400
          Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-15 21:21 +0000
            Re: Wrapping existing UNIX commands in C Stephen Sprunk <stephen@sprunk.org> - 2012-08-15 17:17 -0500
        Re: Wrapping existing UNIX commands in C Stephen Sprunk <stephen@sprunk.org> - 2012-07-30 13:18 -0500
        Re: Wrapping existing UNIX commands in C Cal Dershowitz <cal@example.invalid> - 2012-08-01 21:08 -0600
          Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-02 12:20 +0000
            Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-08-02 06:15 -0700
              Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-02 14:16 +0000
                Re: Wrapping existing UNIX commands in C Kenneth Brody <kenbrody@spamcop.net> - 2012-08-02 11:33 -0400
                Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-08-02 11:51 -0700
                  Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-02 15:03 -0700
                    Re: Wrapping existing UNIX commands in C tom st denis <tom@iahu.ca> - 2012-08-02 18:46 -0700
                      Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-03 02:18 +0000
                      Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-02 21:07 -0700
                        Re: Wrapping existing UNIX commands in C Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-04 10:40 +0100
                          Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-04 03:22 -0700
                          Re: Wrapping existing UNIX commands in C "Heinrich Wolf" <invalid@invalid.invalid> - 2012-08-04 12:34 +0200
                            Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-04 13:25 +0000
                              Re: Wrapping existing UNIX commands in C Kenneth Brody <kenbrody@spamcop.net> - 2012-08-15 13:52 -0400
                            Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-04 16:26 -0700
                            Re: Wrapping existing UNIX commands in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-05 03:27 -0700
                              Re: Wrapping existing UNIX commands in C gwowen <gwowen@gmail.com> - 2012-08-06 01:50 -0700
                                Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 07:15 -0400
                                  Re: Wrapping existing UNIX commands in C gwowen <gwowen@gmail.com> - 2012-08-06 04:25 -0700
                                    Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 09:14 -0400
                                      Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-06 14:14 +0000
                                      Re: Wrapping existing UNIX commands in C gwowen <gwowen@gmail.com> - 2012-08-06 07:43 -0700
                                        Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 11:52 -0400
                                        Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-06 11:37 -0700
                                    Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-06 11:34 -0700
                                      Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-06 11:53 -0700
                                      Re: Wrapping existing UNIX commands in C gwowen <gwowen@gmail.com> - 2012-08-07 00:33 -0700
                                        Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-07 06:44 -0400
                                          Re: Wrapping existing UNIX commands in C gwowen <gwowen@gmail.com> - 2012-08-07 05:15 -0700
                                            Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-07 08:37 -0400
                                            Re: Wrapping existing UNIX commands in C Neil Cerutti <neilc@norwich.edu> - 2012-08-07 13:04 +0000
                                            Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-07 12:57 -0700
                                              Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-07 21:24 +0000
                                                Re: Wrapping existing UNIX commands in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-08 00:58 -0700
                                Re: Wrapping existing UNIX commands in C "BartC" <bc@freeuk.com> - 2012-08-06 18:04 +0100
                                  Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-06 18:24 +0000
                                    Re: Wrapping existing UNIX commands in C jgk@panix.com (Joe keane) - 2012-08-22 17:08 +0000
                                  Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 14:46 -0400
                                    Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-06 11:55 -0700
                                      Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 19:13 -0400
                                  Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-08-06 11:50 -0700
                                    Re: Wrapping existing UNIX commands in C "BartC" <bc@freeuk.com> - 2012-08-06 20:28 +0100
                                      Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-08-06 15:44 -0400
                                        Re: Wrapping existing UNIX commands in C Robert Miles <milesrf@Usenet-News.net> - 2012-09-09 22:46 -0500
                                          Re: Wrapping existing UNIX commands in C Kaz Kylheku <kaz@kylheku.com> - 2012-09-10 04:29 +0000
                                          Re: Wrapping existing UNIX commands in C Keith Thompson <kst-u@mib.org> - 2012-09-09 22:42 -0700
                                            Re: Wrapping existing UNIX commands in C Kaz Kylheku <kaz@kylheku.com> - 2012-09-10 19:15 +0000
                                              Re: Wrapping existing UNIX commands in C pete <pfiland@mindspring.com> - 2012-09-10 22:25 -0400
                                          Re: Wrapping existing UNIX commands in C Öö Tiib <ootiib@hot.ee> - 2012-09-10 03:10 -0700
                                          Re: Wrapping existing UNIX commands in C James Kuyper <jameskuyper@verizon.net> - 2012-09-10 08:01 -0400
                                      Re: Wrapping existing UNIX commands in C "io_x" <a@b.c.invalid> - 2012-08-07 10:22 +0200
                                    Re: Wrapping existing UNIX commands in C "China Blue [Tor], Meersburg" <chine.bleu@yahoo.com> - 2012-08-07 01:55 -0700
                                    Re: Wrapping existing UNIX commands in C gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-07 21:26 +0000
                                      Re: Wrapping existing UNIX commands in C Rui Maciel <rui.maciel@gmail.com> - 2012-08-08 08:47 +0100
                                        Re: Wrapping existing UNIX commands in C "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-10 21:58 -0600
                                Re: Wrapping existing UNIX commands in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-07 00:07 -0700
            Re: Wrapping existing UNIX commands in C Kenneth Brody <kenbrody@spamcop.net> - 2012-08-02 11:27 -0400
        Re: Wrapping existing UNIX commands in C Rui Maciel <rui.maciel@gmail.com> - 2012-08-16 09:43 +0100

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#23908

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

pclose(fp);  ?

[toc] | [prev] | [next] | [standalone]

#23918

"Ike Naar" <ike@sverige.freeshell.org> schrieb im Newsbeitrag 
news:slrn3vfsk1bbgu.jeo.ike@sverige.freeshell.org...
> On 2012-07-29, Heinrich Wolf <invalid@invalid.invalid> wrote:
>> if ((fp = popen("ls")) != NULL)
>>   {
>>   while (fgets(Buffer, sizeof(Buffer), fp))
>>     puts(Buffer);
>>   fclose(fp);
>
> pclose(fp);  ?

Yes of course. I am sorry. 

[toc] | [prev] | [next] | [standalone]

#23919

"Heinrich Wolf" <invalid@invalid.invalid> schrieb im Newsbeitrag 
news:jv3kb3$fk6$1@news.m-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. 

[toc] | [prev] | [next] | [standalone]

#23897

In article <jv3jqk$r1t$1@speranza.aioe.org>,
 Chicken McNuggets <chicken@mcnuggets.com> 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.

The easiest way is to use popen/pclose which opens an anonymous pipe to (mode 
"w") or from (mode "r") a child process executing the command:
        FILE *ls = popen("ls -l .", "r");
        while (fgets(ls, line, sizeof line)) process(line);
        pclose(ls);

Using named pipes, you can do this with just system():
        system("mkfifo ../pipe");
        FILE *ls = open("../pipe", "r");
        system("ls -l . >../pipe &");
        while (fgets(ls, line, sizeof line)) process(line);
        fclose(ls);

You can also use exec by openning a pipe:
        int pp[2]; pipe(pp);
        int child = fork();
        if (child) {
            close(pp[1]);
            FILE *ls = fdopen(pp[0],"r");
            while (fgets(ls, line, sizeof line)) process(line);
            fclose(ls);
            int status; waitpid(child, &status, 0);
        } else {
            close(pp[0]);
            dup2(pp[1], 1);
            close(pp[1]);
            execl("/bin/ls", "/bin/ls", "-l", ".", 0);
        }

-- 
My name Indigo Montoya.      |            Die, Robbie Ferrier! Die!
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#23909

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

FILE *ls = fopen("../pipe", "r");  ?

[toc] | [prev] | [next] | [standalone]

#23899

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

[toc] | [prev] | [next] | [standalone]

#23942

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

[toc] | [prev] | [next] | [standalone]

#23944

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.

[toc] | [prev] | [next] | [standalone]

#23945

jacob navia <jacob@spamsink.net> 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.

[toc] | [prev] | [next] | [standalone]

#23949

On 30/07/2012 12:39, Ben Bacarisse wrote:
> jacob navia <jacob@spamsink.net> 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/>

[toc] | [prev] | [next] | [standalone]

#23971

On 7/30/2012 7:16 AM, Mark Bluemel wrote:
> On 30/07/2012 12:39, Ben Bacarisse wrote:
>> jacob navia <jacob@spamsink.net> 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/>
>

yep...

a JS/ES/... analogue would be something like:
eval("setName(\""+name+"\");");

(not sure if similar also applies to PHP, would have to look into this).


where some clever entries in the name field can do all sorts of things...


so, it is a good indication for things like:
for something which prints/composes something, be sure to filter the 
string (or "C-ify" it, where any uncertain characters are escaped);
for code which parses something, it is a good idea to check for and make 
sure one has the intended type of token (as a poorly written parser can 
have "interesting" effects when fed cleverly crafted code).

nevermind all the usual annoyances, like trying to avoid buffer-overflow 
risks, ...

[toc] | [prev] | [next] | [standalone]

#23958

On Mon, 2012-07-30, Ben Bacarisse wrote:
> jacob navia <jacob@spamsink.net> 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.

Depends on if 'filename', in the actual application, can be based on
user input.  Of course, if you use remove() or something, you don't
have to worry about that.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#23961

On Mon, 2012-07-30, jacob navia wrote:
> 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?

He didn't say it's incorrect.  If he's like me, he's all for
half-baked code and avoiding effort -- up to a point.

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

Depends. If all he wants is an unordered list of file names, learning
the API may well be easier than popen()ing ls.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#24027

On Mon, 30 Jul 2012 13:26:34 +0200, jacob navia wrote:

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

The lack of quoting/escaping is a bigger problem than the fixed buffer
size. Apart from the need to protect against interpretation by the shell,
"rm" will interpret the argument as an option if it begins with a dash.

Using a relative path to "rm" means that it may run something other than
/bin/rm.

And performance is several orders of magnitude worse than remove() or
unlink() (fork() and/or exec() can be particularly expensive).

At least system() usually does the right thing with respect to signals;
the situation for popen() is much more complex.

[toc] | [prev] | [next] | [standalone]

#24131

On Jul 30, 7:26 am, jacob navia <ja...@spamsink.net> wrote:
> 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?

In theory "remove()" is more portable given that "rm" is a typical
*NIX command not found on [say] Windows.

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

Depends on what you want to do with the information and how you want
to present it.  When I hit "read file" in nano it presents me with a
directory listing that is nicely formatted that I can walk through
with the arrow keys.  Can't do that with "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.

Except where the system doesn't have an "rm" command... And this code
snippet [though just an example] doesn't check the return code of
system.  This code can also fail simply because it cannot start a
shell to run "rm" whereas remove() will fail for reasons more directly
related to failing to remove the damn file/directory.

Tom

[toc] | [prev] | [next] | [standalone]

#23967

On 29/07/2012 17:57, 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?
>
> S
>

Because the "ls" command was an example. I really want to process the 
output of things like "iostat", "/proc/loadavg", "sar" and "tcpdump".

dirent.h would be great if I needed to analyse information about 
directories but since I don't need that functionality (and I have 
already used it in the past) it is a rather pointless suggestion.

[toc] | [prev] | [next] | [standalone]

#23968

Chicken McNuggets wrote:
> On 29/07/2012 17:57, 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?
>>
>> S
>>
> 
> Because the "ls" command was an example. I really want to process the 
> output of things like "iostat", "/proc/loadavg", "sar" and "tcpdump".
> 
> dirent.h would be great if I needed to analyse information about 
> directories but since I don't need that functionality (and I have 
> already used it in the past) it is a rather pointless suggestion.

Does the language need to be C ?

    Paul

[toc] | [prev] | [next] | [standalone]

#23970

On 07/30/2012 01:10 PM, Chicken McNuggets wrote:
> On 29/07/2012 17:57, 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?
>>
>> S
>>
> 
> Because the "ls" command was an example. I really want to process the 
> output of things like "iostat", "/proc/loadavg", "sar" and "tcpdump".
> 
> dirent.h would be great if I needed to analyse information about 
> directories but since I don't need that functionality (and I have 
> already used it in the past) it is a rather pointless suggestion.

We can only comment on the questions you actually ask. The only specific
example you gave was for "ls", for which there are utilities from
section 2 of the Unix manual that provide the same information in a form
that's easier to deal with from inside a program than parsing the output
of "ls". There's lots of other POSIX command line utilities for which
that's also true. The fact that you were interested in utilities for
which it's not true was not at all obvious.

[toc] | [prev] | [next] | [standalone]

#24525

In article <5016C58C.5070802@verizon.net>,
James Kuyper  <jameskuyper@verizon.net> wrote:
...
>We can only comment on the questions you actually ask. The only specific
>example you gave was for "ls", for which there are utilities from
>section 2 of the Unix manual that provide the same information in a form
>that's easier to deal with from inside a program than parsing the output
>of "ls". There's lots of other POSIX command line utilities for which
>that's also true. The fact that you were interested in utilities for
>which it's not true was not at all obvious.

This, incidentally, is a very good illustration of why, when posting in
hostile environments, such as this one (though, to be fair, most of Usenet
also qualifies), it is a good idea to not be too specific about what your
real problem is *or* to give examples (analogies) which are not your real
problem.

In both cases, the goons will latch onto the specific problem (as you have
proudly done) and ignore the question that you actually asked.

-- 
They say compassion is a virtue, but I don't have the time!

    - David Byrne -

[toc] | [prev] | [next] | [standalone]

#24526

On 15-Aug-12 16:21, Kenny McCormack wrote:
> In article <5016C58C.5070802@verizon.net>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
> ...
>> We can only comment on the questions you actually ask. The only specific
>> example you gave was for "ls", for which there are utilities from
>> section 2 of the Unix manual that provide the same information in a form
>> that's easier to deal with from inside a program than parsing the output
>> of "ls". There's lots of other POSIX command line utilities for which
>> that's also true. The fact that you were interested in utilities for
>> which it's not true was not at all obvious.
> 
> This, incidentally, is a very good illustration of why, when posting in
> hostile environments, such as this one (though, to be fair, most of Usenet
> also qualifies), it is a good idea to not be too specific about what your
> real problem is *or* to give examples (analogies) which are not your real
> problem.
> 
> In both cases, the goons will latch onto the specific problem (as you have
> proudly done) and ignore the question that you actually asked.

Vague questions get vague answers--probably too vague to be of any use.

Specific questions get specific answers--but if the specifics do not
match your actual problem, they probably won't be of any use either.

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web