对stdin,stdout和stderr感到困惑? [英] Confused about stdin, stdout and stderr?

查看:121
本文介绍了对stdin,stdout和stderr感到困惑?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我对这三个文件的目的感到很困惑.如果我的理解是正确的,则stdin是程序在其中写入其在进程中运行任务的请求的文件,stdout是内核在其中写入其输出并且请求其访问信息的进程的文件. ,而stderr是所有异常都输入到的文件.打开这些文件以检查它们是否确实发生时,我发现似乎没有任何提示!

我想知道的是这些文件的目的是什么,用很少的技术术语就完全是愚蠢的答案了!

解决方案

标准输入-这是您的进程读取以获取您的信息的文件句柄. /p>

标准输出-您的进程将正常信息写入此文件句柄.

标准错误-您的进程将错误信息写入此文件句柄.

那简直就是愚蠢了:-)

当然,多数情况下都是按照惯例.如果您愿意,没有什么可以阻止您将错误信息写入标准输出.您甚至可以完全关闭三个文件句柄,并为I/O打开自己的文件.

进程启动时,它应该已经打开了这些句柄,并且可以从中读取和/或写入它们.

默认情况下,它们可能已连接到您的终端设备(例如,/dev/tty),但是通过Shell,您可以在设置这些句柄与特定文件和/或设备(甚至是通往其他进程的管道)之间建立连接.您的过程开始了(某些可能的操作相当聪明).

一个例子是:

my_prog <inputfile 2>errorfile | grep XYZ

它将:

  • my_prog创建一个进程.
  • 打开inputfile作为标准输入(文件句柄0).
  • 打开errorfile作为标准错误(文件句柄2).
  • grep创建另一个过程.
  • my_prog的标准输出附加到grep的标准输入.

发表您的评论

当我在/dev文件夹中打开这些文件时,为什么我再也看不到正在运行的进程的输出了?

这是因为它们不是普通文件.尽管UNIX将一切呈现为文件系统中某个位置的文件,但在最低级别上却并非如此. /dev层次结构中的大多数文件是字符设备或块设备,实际上是设备驱动程序.它们没有大小,但确实有主设备号和次设备号.

打开它们时,您连接的是设备驱动程序而不是物理文件,并且设备驱动程序足够聪明,可以知道应该单独处理单独的进程.

Linux /proc文件系统也是如此.这些不是真实的文件,只是对内核信息进行严格控制的网关.

I am rather confused with the purpose of these three files. If my understanding is correct, stdin is the file in which a program writes into its requests to run a task in the process, stdout is the file into which the kernel writes its output and the process requesting it accesses the information from, and stderr is the file into which all the exceptions are entered. On opening these files to check whether these actually do occur, I found nothing seem to suggest so!

What I would want to know is what exactly is the purpose of these files, absolutely dumbed down answer with very little tech jargon!

解决方案

Standard input - this is the file handle that your process reads to get information from you.

Standard output - your process writes normal information to this file handle.

Standard error - your process writes error information to this file handle.

That's about as dumbed-down as I can make it :-)

Of course, that's mostly by convention. There's nothing stopping you from writing your error information to standard output if you wish. You can even close the three file handles totally and open your own files for I/O.

When your process starts, it should already have these handles open and it can just read from and/or write to them.

By default, they're probably connected to your terminal device (e.g., /dev/tty) but shells will allow you to set up connections between these handles and specific files and/or devices (or even pipelines to other processes) before your process starts (some of the manipulations possible are rather clever).

An example being:

my_prog <inputfile 2>errorfile | grep XYZ

which will:

  • create a process for my_prog.
  • open inputfile as your standard input (file handle 0).
  • open errorfile as your standard error (file handle 2).
  • create another process for grep.
  • attach the standard output of my_prog to the standard input of grep.

Re your comment:

When I open these files in /dev folder, how come I never get to see the output of a process running?

It's because they're not normal files. While UNIX presents everything as a file in a file system somewhere, that doesn't make it so at the lowest levels. Most files in the /dev hierarchy are either character or block devices, effectively a device driver. They don't have a size but they do have a major and minor device number.

When you open them, you're connected to the device driver rather than a physical file, and the device driver is smart enough to know that separate processes should be handled separately.

The same is true for the Linux /proc filesystem. Those aren't real files, just tightly controlled gateways to kernel information.

这篇关于对stdin,stdout和stderr感到困惑?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆