[SOLVED] should there be another input/output stream (3:stdinfo)
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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
Last edited by schneidz; 05-22-2014 at 10:43 AM.
Reason: wget is a better example than time
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.
Last edited by suicidaleggroll; 05-22-2014 at 11:55 AM.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.