Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macro for printing to stderr #1078

Closed
posix4e opened this issue Apr 20, 2015 · 13 comments
Closed

macro for printing to stderr #1078

posix4e opened this issue Apr 20, 2015 · 13 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@posix4e
Copy link

posix4e commented Apr 20, 2015

I see people using http://is.gd/8TYNHp so much, that I wonder if it should be in the standard library.

macro_rules! print_err {
    ($($arg:tt)*) => (
        {
            use std::io::prelude::*;
            if let Err(e) = write!(&mut ::std::io::stderr(), "{}\n", format_args!($($arg)*)) {
                panic!("Failed to write to stderr.\
                    \nOriginal error output: {}\
                    \nSecondary error writing to stderr: {}", format!($($arg)*), e);
            }
        }
    )
}

fn main() {
    print_err!("hi");
}
@petrochenkov
Copy link
Contributor

+1
When writing scripts that output the results of their work to stdout and status messages to stderr it quickly becomes annoying to write let _ = write!(stderr, "blahblahblah") and a standard convenience macro would be highly appreciated.

@oprudkyi
Copy link

oprudkyi commented Nov 7, 2015

+1

@ninjabear
Copy link

+1

@justinmayhew
Copy link

This would be very useful. Most programs require writing to standard error and it'd be nice if the community could standardize on a macro for this.

@cjsut
Copy link

cjsut commented Aug 4, 2016

Let's go beyond "wouldn't it be nice if..." and further justify and bring up additional considerations for the introduction of this feature.

I believe the lack of such a macro encourages (even if only by omission) the use of standard output for diagnostic purposes, which for the end-user degrades user experience and weakens the semantic power of having both streams available. Imagine my surprise when I redirect the output of some (thus far imaginary) utility written in Rust to a file, and later discover that the file simply says "Wrong arguments"!

One might argue that the choice of standard error over standard output is one made by the programmer — and I can not and will not disagree with this. But as programmers, we expect our tools and their documentation to guide us toward the semantically correct choice (arguably more so with Rust than usual). We should consider carefully:

  • how the name we give the macro might affect its perceived purpose. Personally I'm against print_err, if only because I think it may be perceived as intended for error reporting only (and frequently explaining the lack of a print_warn! macro in #rust-beginners on IRC is not something I want to do)
  • and when and in what context this macro should be presented to new Rust users, because println! is currently the single most-visible means of text output for this user group; people won't use something they don't know about.

@BurntSushi
Copy link
Member

I agree this may be nice. In essentially every CLI tool I've written, I've defined macros like eprint! or eprintln! that are just like println!, except they send their output to stderr.

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 30, 2016
@nrc
Copy link
Member

nrc commented Aug 30, 2016

Is there a crate that implements this (and only this)? I suspect a strong motivation for moving to std would be such a crate with wide usage.

@cjsut
Copy link

cjsut commented Aug 30, 2016

@nrc, I personally wouldn't bother with such a crate because such a macro is trivial to define. What's missing is a standardized name for such a macro, and the guidance for new users to learn how to properly separate debug and normal (stderr and stdout) statements as I mentioned in an earlier comment. (This guidance is currently missing from all documentation, and we happily tell those learning Rust that println! is fine for anything.)

It seems to me that, depending on the outcome of this thread, it may be a good idea to have a follow-up RFC that more formally discusses the macro's name and use cases, in addition to how it should be introduced to those learning Rust.

@Mark-Simulacrum
Copy link
Member

I think an in-standard solution to this is generally a good idea (standardized name is a big part of this), and would like to request that whatever the solution is, an output similar to panics "message at foobar.rs:230is nice, at least optionally. Perl'swarn` function is an example of the general functionality I've found lacking.

However, that aside, I also don't want a solution in the standard library. Rust seems to go with the strategy of trying to push programmers into "doing the right thing," which most of the time means println! is fine for trivial programs and something like log/slog should likely be used for larger programs.

@Ericson2314
Copy link
Contributor

Yeah I sometimes wish print* just didn't exist and everybody used log.

@mmstick
Copy link

mmstick commented Jan 13, 2017

I find myself printing to stderr quite often by creating an stderr variable and writing to it with the write! macro. It seems odd that the print and println macro only supports writing to stdout but not have the option to write to stderr. It could easily be done by just adding on to the macro to support some keywords like so:

// Prints to standard error
println!(stderr "Message to print to stderr");
// Prints to standard output
println!(stdout "Message to print to stdout");
// Prints to standard output
println!("Message to print to stdout");

It wouldn't break any existing code -- just extends what kinds of inputs that the print macros can support.

@camsteffen
Copy link

This feature was recently merged in. See rust-lang/rust#40528.

@roblabla
Copy link

This should be closed, eprintln! macro is now stable https://doc.rust-lang.org/std/macro.eprintln.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests