LinuxQuestions.org - [SOLVED] should there be another input/output stream (3:stdinfo)

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - should there be another input/output stream (3:stdinfo) (https://www.linuxquestions.org/questions/linux-general-1/should-there-be-another-input-output-stream-3-stdinfo-4175505768/)

should there be another input/output stream (3:stdinfo)

should there be another text stream for the terminal.

i propose 3:stdinfo where stuff isnt an error or warning that would get redirected to 2:stderr but informational stuff like wget server information or mysql fetch information about how many rows pulled and how long it took ?

output from the time command would be another example.

How is that different from stdout?

stdout is info i care about. stdinfo would be info that is not essential but good to know. e.g.:

Code:

[schneidz@hyper ~]$ wget www.02144.com > std.info 

--2014-05-22 11:32:17--  http://www.02144.com/

Resolving www.02144.com... 64.235.229.141

Connecting to www.02144.com|64.235.229.141|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 421 [text/html]

Saving to: “index.html”



100%[==============================================================================================>] 421        --.-K/s  in 0s      



2014-05-22 11:32:18 (12.1 MB/s) - “index.html” saved [421/421]



[schneidz@hyper ~]$ cat std.info # empty

[schneidz@hyper ~]$ cat index.html 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<title>West Somerville, baby.</title>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<link href="02144.css" rel="stylesheet" type="text/css">

</head>



<body>

<table width="50%" border="0" cellspacing="10" cellpadding="0">

  <tr>

    <td><span class="headertext">02144.com</span></td>

  </tr>

</table>

</body>

</html>

[schneidz@hyper ~]$

note that the wget information wasnt redirected to the file because it was in the stderr stream (eventhough technically the command did not error).

what i am proposing would be this would be used for error details:
wget http://www.this-site-doesnt-exist.com 2> error.out

and this would be for informative details that arent vital such as resolved ip-addresses/bits per second/...:
wget http://www.linuxquestions.org 3> info.out

and like normal this would be for normal program output:
wget -q -O - www.02144.com 1> std.out

you can easily implement such feature in your environment. But I do not have any idea if it was really useful. See syslogd, it has much better capabilities...

I'd like that. Many programs are built to send their output to stdout, which means you can't send informative messages into stdout or it will be mixed with the actual program output. [in my opinion] you shouldn't dump informative messages into stderr either, or it will look like error.

There are many cases in which the program I'm trying to run dumps its output on stdout. I need the output uncorrupted, and I want to see any errors as well, but I don't want to clutter it up with random informative messages.

Some programs have a -q flag to shut off informative messages while retaining error messages, but the implementation is inconsistent. Sometimes -q shuts off error messages as well, sometimes there is no -q flag and you either get stdout or stderr loaded up with information you often don't care about. If this is running in a cron job, this forces you to either get an email every time the job runs which is filled with random informative messages, or you have to redirect stderr to a file or /dev/null and risk not being notified at all in the event of an actual error. You could check the exit status, but then you don't have the message to go along with it. Before too long a little 1-line cron job turns into a 20 line script with exit status checking, stderr file parsing, email, etc.

As with most other things in the computing world, there are ways around the problem, but I do think the cleaner and better solution is a third stream for information like this.

wget already has a way to do this. "-o" puts the log messages to a file. You can also use "-d" "-v" "-nv" and "-q" to turn up or down the amount of messages. I think these types of options are common.