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.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Redirect
  • 107

1 Answers1

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 03 '19 at 08: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 03 '19 at 08: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. –  May 03 '19 at 08: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 03 '19 at 09:10
  • Actually, the link from my comment is the 2nd reference in the wiki, sorry ;-) –  May 03 '19 at 09:18