1

For extra context, I asked this question earlier, and thought I understood things, but not anymore.

I know that echo ignores stdin. I know that stdin, stderr and stdout exist and, in this context, I don't know that "things" other than these exist.

So, if echo ignores stdin, where does it get its input from? It seems like stdin, stdout and stderr do not tell the whole story.

  • echo gets all the information it needs from the arguments passed to it. – William Pursell May 3 at 0:28
  • Yes, story is much more than that. A process has much more properties than the three file descriptors. echo gets information from the argv (command line arguments, one of the process's properties). – 炸鱼薯条德里克 May 3 at 1:19
  • @炸鱼薯条德里克 Thanks! This pointed me in the right direction (processes overview). I'm now getting a better sense of all of this (I think). – Redirect May 3 at 9:14
2

I'm not sure I understand the source of your confusion, but keep in mind that in Unix the command line arguments (the foo and bar from echo foo bar) and environment strings (the FOO=bar from env - FOO=bar printenv) are simply copied by the kernel in the address space of the process, where they're simply accessed just like any other memory (via pointers, etc.); they're not passed as files that could be read, written or memory mapped by the process, as the standard stdin, stdout, stderr or any extra file descriptors are.

This is not some law of nature, it's just how it works in Unix. An argument could be made that this is archaic, inconsistent and inefficient (a copy of the whole environment is made for each process, even if it ignores all or most of it).

Different arrangements can be made -- in plan9, the environment strings are actually files in /env (which also means that they can be shared between processes).

Also, a LD_PRELOAD hack could be used in Linux to bypass the argv+env limit by passing the whole thing via a file created with memfd_create.

  • Thanks, mosvy. That helps. I'll try to explain why I'm confused a little better. We have the concept of input. This is not a technological concept, it's just something that exists. When using a shell, specifically when running the command echo foo bar, this is input according to the dictionary definition. Now the resources mention stdin, stderr and stdout and nothing else (the whole story is not being told) and I don't know how to make sense of this. – Redirect May 3 at 8:08
  • Your first paragraph tells me that not all input is handled by file descriptors. Am I inferring this correctly? However, isn't it the case that everything is a file descriptor? So where are foo and bar going to? – Redirect May 3 at 8:12
  • No, not everything is a file. The very first reference from that wiki page already told you that .. this is not exactly the case. And anyways, the only operation common to all file descriptors is close(2) -- many fds cannot be used for any i/o at all (eg. look for O_PATH in the open(2) manpage). Also, a process can have other sources of input (signals + associated siginfo, reading the memory of another process with process_vm_readv(2), etc). And that's just scratching the surface. – mosvy May 3 at 8:57
  • I think this is beyond me at the moment, thanks for all the help. But I didn't say that everything is a file. I said (asked actually) if everything is a file descriptor, that very same source says it is (in truth it says everything is a FD or a process, I missed this). – Redirect May 3 at 9:10
  • Actually, the link from my comment is the 2nd reference in the wiki, sorry ;-) – mosvy May 3 at 9:18

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.