LinuxQuestions.org - how to use ls in a system call in C in linux

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - how to use ls in a system call in C in linux (https://www.linuxquestions.org/questions/programming-9/how-to-use-ls-in-a-system-call-in-c-in-linux-211576/)

how to use ls in a system call in C in linux

learn how to ask a question. what the hell are you talking about? "use ls"? do u mean, how does ls get its info? man getdents

newguy21; not quite sure, but do you have reference to C language or is that what os has as a command within lists (ls). according to my resources ls or -l is directory command, ls gives pattern to match but not
those starting with c on the other (-l) will give long list contents. with proper options defined files will be shown.

Code:

xxx:~$ cat mine-ls.c

#include <stdio.h>

#include <stdlib.h>



int main(int argc, char **argv)

{

  FILE *fp

      ;

  char rd_line[128]

      ,*p1

      ;

  if (argc != 2)

  {

    fprintf(stderr, "Usage: %s <directory>\n", argv[0]);

    exit(EXIT_FAILURE);

  }

  strcpy(rd_line, "ls -l ");

  strcat(rd_line, argv[1]);

  if ((fp = popen(rd_line, "r")) == NULL)

  {

    fprintf(stderr, "%s %s: could not open pipe file\n", argv[0]);

    exit(EXIT_FAILURE);

  }

  while (fgets(rd_line, sizeof(rd_line), fp) != NULL)

  {

    for (p1 = rd_line + strlen(rd_line); p1 >= rd_line && *p1 < ' '; *p1--)

      *p1 = '\0';

    printf("%s\n", rd_line);

  }

  pclose(fp);

  return(0);

}

Quote:

Originally posted by osvaldomarques

Code:

/* buffer overflow */ strcpy(rd_line, "ls -l "); strcat(rd_line, argv[1]);

Quote:

Originally posted by infamous41md
learn how to ask a question. what the hell are you talking about? "use ls"? do u mean, how does ls get its info? man getdents

"man getdents" says:

Quote:

DESCRIPTION
This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface.

i know, i was assuming he wanted the system call and not the libc func tho. :) hard to give an answer when someone asks such an unclear question.

Hi gentlemen,
Infamous41md is right about the risk of buffer overflow in any program which deals with arguments, but the purpose of this simple program is to offer a functional example.
Hko is also right; if we just want to read the contents of a directory, nothing is better than opendir(3), readdir(3) and closedir(3).
Again Infamous41md is right about the difficulty to answer a question so generic. So, reading the answers already given, I decided to contribute with one more example, one more generic, which could help newguy21.

not trying to pick on u, but there is not a risk in any program that deals with arguments, only a risk in programs that use functions like strcpy() with user input, or other insecure programming techniques. a simple strncpy() solves the problem in the above code.

Quote:

Originally posted by infamous41md
learn how to ask a question. what the hell are you talking about? "use ls"? do u mean, how does ls get its info? man getdents

You should really learn to be more polite. If someone asks a question you don't understand, show a little patience and try to kindly ask them to explain it further. No reason to get abusive to other members, when members do this it makes LQ.org as a whole look bad, so show some respect to not only members but the site itself. Lets make this your last warning please.

I may have misunderstood the question.. but ..how about..

char *cmd="ls -l /path/here/";
system(cmd);

or system("ls -l /path/here/");

to read the result..
system("ls -l /path/here/ > file_name");

now the output is in the file..

Rohan

Quote:

Originally posted by trickykid
You should really learn to be more polite. If someone asks a question you don't understand, show a little patience and try to kindly ask them to explain it further. No reason to get abusive to other members, when members do this it makes LQ.org as a whole look bad, so show some respect to not only members but the site itself. Lets make this your last warning please.

maybe u should read the original post again. wtf kind of question is that supposed to be? if people want an answer, they need to learn how to ask a question first. that was the most incomprehensible question i've read in awhile. damn, just look at the replies for proof of how poor the question is. i thought he was talking about what system call is used to get directory entries, another person thought he wanted to use the system() function, and itsme was just plain confused. instead of wasting your energy telling me about politeness, u should be telling the OP how to post a question. and if u want to see rude, maybe u should go post that question @ comp.unix.programmer and see what happens. as im sure u know, people answer questions during their free/spare time, and it's frustrating trying to help someone who doesn't even have the courtesy to phrase a semi-intelligent - wait scratch that, semi-comprehensible, question. as long as i see questions that look like that, i'll continue to respond in the exact same way. sometimes a little rudeness gets people to put the same effort into their question that they expect us to put into the reply.

Gentlemen,
I'm back here, not to flame about, but to discuss some concepts. I want to discuss about the risk of buffer overflow again. I want to discuss about strcpy. After I read the first reply to my prior post oft today, I started to think if I am sooo wrong? I program C for about 15 years. strcpy is my breakfast, my lunch and my dinner. Is it a risky function? Yes! It is unsafe to cross the street. It is dangerous go out of home. It is dangerous to stay at home. To live is dangerous!
I decided to see if someone uses this function. I greped kernel sources (2.4.26). I removed all the comments, defines and references on Makefile. Result: ~1473 calls to strcpy and ~558 to strncpy.
The risk of buffer overflow is in the use of strcpy in an uncontrolled environment as in the example I did. I would check the size of the argument passed to the program before accept it. As I am programming, one of my attributions is to specify the proper size of the variable. The unsafe code would be replaced by:

Code:

#include <stdio.h>

#include <stdlib.h>



int main(int argc, char **argv)

{

  FILE *fp

      ;

  char rd_line[128]

      ,cmd[] = "ls -l "

      ,*assy_cmd

      ,*p1

      ;

  if (argc != 2)

  {

    fprintf(stderr, "Usage: %s <directory>\n", argv[0]);

    exit(EXIT_FAILURE);

  }

  assy_cmd = (char *) alloca(strlen(cmd) + strlen(argv[0]) + 1);

  strcpy(assy_cmd, cmd);

  strcat(assy_cmd, argv[1]);

  if ((fp = popen(assy_cmd, "r")) == NULL)

Please forgive me for talking about this matter again but I returned to this topic for clarification purposes.
Have a nice week end!

Quote:

Originally posted by infamous41md
maybe u should read the original post again. wtf kind of question is that supposed to be? if people want an answer, they need to learn how to ask a question first. that was the most incomprehensible question i've read in awhile. damn, just look at the replies for proof of how poor the question is. i thought he was talking about what system call is used to get directory entries, another person thought he wanted to use the system() function, and itsme was just plain confused. instead of wasting your energy telling me about politeness, u should be telling the OP how to post a question. and if u want to see rude, maybe u should go post that question @ comp.unix.programmer and see what happens. as im sure u know, people answer questions during their free/spare time, and it's frustrating trying to help someone who doesn't even have the courtesy to phrase a semi-intelligent - wait scratch that, semi-comprehensible, question. as long as i see questions that look like that, i'll continue to respond in the exact same way. sometimes a little rudeness gets people to put the same effort into their question that they expect us to put into the reply.

I understand completely on some parts. I wish every question was perfect but that is also what sets us aside from other forums, news groups, bb's and so on..

We're not here to bash others, for no reason. If you can't refrain, then move on and ignore, no one is forcing you to reply. If you do reply, I'm asking you now to refrain from posting such utter crap posts in the future. Sure his question was utter crap, but were not here to talk down to anyone, were here to help, not make matters worse. If you replied to every member who asks a question that others might not understand themselves in a rude fashion, well no one would ever come to this site, it would not be as big and helpful as it is now.

Is it so hard to just be polite though? Think about it... if you can't and you just want to act like a bitter old perfect question asking member, then maybe you shouldn't respond to the members who can't ask proper questions and only search for the more intelligient question askers..

But this is not your forum and I'm following the rules set by the administrator. I can assure you, he'd rather have people who can't ask decent questions and then have decent people to encourage them to ask better questions in a polite and professional manner than those who respond like you did only most likely to run the person off or make them feel even dumber.

So again, if you have a problem, click that button that says email under my name.. or you can email Jeremy the site administrator and owner if you don't like following our simple rules that let me remind you agreed to when registering.

Regards.

Quote:

Originally posted by osvaldomarques
Gentlemen,
I'm back here, not to flame about, but to discuss some concepts. I want to discuss about the risk of buffer overflow again. I want to discuss about strcpy. After I read the first reply to my prior post oft today, I started to think if I am sooo wrong? I program C for about 15 years. strcpy is my breakfast, my lunch and my dinner. Is it a risky function? Yes! It is unsafe to cross the street. It is dangerous go out of home. It is dangerous to stay at home. To live is dangerous!
I decided to see if someone uses this function. I greped kernel sources (2.4.26). I removed all the comments, defines and references on Makefile. Result: ~1473 calls to strcpy and ~558 to strncpy.
The risk of buffer overflow is in the use of strcpy in an uncontrolled environment as in the example I did. I would check the size of the argument passed to the program before accept it. As I am programming, one of my attributions is to specify the proper size of the variable. The unsafe code would be replaced by:

Code:

#include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { FILE *fp ; char rd_line[128] ,cmd[] = "ls -l " ,*assy_cmd ,*p1 ; if (argc != 2) { fprintf(stderr, "Usage: %s <directory>\n", argv[0]); exit(EXIT_FAILURE); } assy_cmd = (char *) alloca(strlen(cmd) + strlen(argv[0]) + 1); strcpy(assy_cmd, cmd); strcat(assy_cmd, argv[1]); if ((fp = popen(assy_cmd, "r")) == NULL)

Please forgive me for talking about this matter again but I returned to this topic for clarification purposes.
Have a nice week end!

couple problems here. first, alloca() is not a function one should be using to allocate dynamic memory. in the man page it says that implementations are buggy and inconsistent. and even worse, when the function in which u call alloca returns, the memory allocated gets junked. now in this case u alloc in main, so it's inconsequential, but what if you were in a function that main called and did that? that string would be worthless after the function returned. i'm not sure if that's what u intended, but that's not what alloca is intended to be used for. secondly, look closely at the line where u alloca(), you are using the length of argv[0], when u should be using argv[1]. thirdly, u haven't checked the return value of alloca(), it returns NULL on failure(actually some versions don't return NULL and some do, another reason to avoid this function). i would do this:

Code:

ptr = calloc(1, (len = strlen(cmd) + strlen(argv[1]) + 1) );

if(!ptr)  errror()

snprintf(ptr,  len, "%s%s", cmd, argv[1]);

in regards to the kernel and strcpy(). the calls to strcpy() don't deal with user input(hopefully), but still, i tend to avoid that func like the plague unless it's something like this:

Code:

char buf[BS]



strcpy(buf, "bla");

but even that should be avoided. what if one day u change the size of define BS, or if u use a different string instead of "bla" and forget to change the BS. better to be safe than sorry.