I am looking at a program coded in C. The issue with this program relies on this line of code.

system("/usr/bin/env echo and now what?");

I understand that the system() just runs the command. But I am just not sure why it is like that.

Normally it would just be "echo and now what". But why is that "usr/bin/env" put in front of it? What exactly is that doing?

  • I am still not fully understanding it. I get what environmental variables are. A list of variables like used in programming that are used to hold data. But I don't understand why the calling of /usr/bin/env. – sqlsqlsql May 11 '17 at 23:12
  • Or does calling the /usr/bin/env OR env before echo just say use the $PATH variable when looking for the "echo" command? – sqlsqlsql May 11 '17 at 23:21

/usr/bin/env followed by the name of a program executes that program. It looks up the program name as an executable file in the directories configured by the PATH environment variable. It's a special case of the usage of env: env is followed by some environment variable assignments and then a program name and arguments — here there happens to be zero variable assignments.

/usr/bin/env echo … is equivalent to /bin/echo …, except that it doesn't hard-code the path to echo — depending on the system and on the value of PATH, it could be /bin/echo, /usr/bin/echo, /usr/xpg4/echo, /usr/ucb/echo, /usr/local/bin/echo, /home/bob/bin/echo, …

Almost every shell has an echo command built in. There may be differences in behavior between the shell builtin and the external command. In practice, there are variations between echo commands in two respects: what happens if the first argument begins with - (some versions of echo process a few options), and how a backslash is processed (some versions print it literally, others treat it as an escape character). So forcing a version of echo is useful occasionally, when you want to use these implementation-dependent behavior. In most cases it's better to use printf instead — printf can do everything that echo can do, and is portable except to antiques.

With the arguments passed in your sample code, the choice of an echo implementation doesn't matter. If there's a point to this madness, it would require a lot more context to figure out.

  • I am practicing some pentesting and this was part of a small C program on a Linux VM. The issue here is that I am able to edit the $PATH variable and add my own directory. So like /tmp. That way I can create my own "echo" command and then when the /usr/bin/env is used, it will go to the $PATH and see /tmp and look in there for my own echo. Which then my echo could be used to do what I need. – sqlsqlsql May 12 '17 at 0:54

I understand that the system() just runs the command.


Normally it would just be "echo and now what".

Your are missing the last character.

But why is that "/usr/bin/env" put in front of it?

That's the full path of the env command which is then the command executed instead of echo.

What exactly is that doing?

It prevents the echo builtin to be executed by the shell spawned by the system libc function so the echo executable first found in the PATH is used instead. Depending on the respective echo implementations, the behavior might be different although I don't see here anything particular. In both cases, "and now what?" should be printed unless you are unlucky and have a file which five letters name starts with "what", like for example "whatz" in your current directory. If it is the case, what would be printed is:

and now whatz

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.