I don't think this is correct. If bar.cr is actually a file that is going to be used from macro run, then the STDERR output of foo.cr will be incldued in the output of bar.cr, making the caller of run "bar.cr" fail.

What I mean is, if bar.cr is supposed to be used from a macro run, like:

{{ run "bar.cr" }}

and bar.cr would maybe return "1 + 2", then if "foo.cr" outputs to STDERR then the output of bar.cr will be "1 + 2 Success executing..." and that won't be a valid program anymore.

If you need to debug a macro run you can just run that file. That's the whole point of macro run being able to run files and passing arguments to it, it's just a regular program that you can test outside of macros.

I see what you mean @asterite, maybe the stderr of the macro run should be printed (for debug purpose) on the stderr of the caller, so that nested macro run's debugs always end up in stderr in the end, and are not understood as being part of the macro run's code output?

(not sure if it's clear, I can rephrase otherwise)

Yes, printing to STDERR is probably good.

@asterite

If you need to debug a macro run you can just run that file.

Indeed, but passing correct argument to run script is hard for me.

And I don't understand about what you are afraid. Because this example works:

$ cat foo.cr
STDERR.puts "from foo.cr"
$ cat bar.cr
{{ run("./foo.cr") }}
STDERR.puts "from bar.cr"
puts "pp 1 + 2"
$ cat main.cr
{{ run("./bar.cr") }}
$ ./crystal run main.cr
Success executing run: ./foo.cr
stderr:

    from foo.cr

Success executing run: ./bar.cr
stderr:

    from bar.cr

1 + 2 # => 3

Success executing... is printed on compile-time, and it shows run-time STDERR output.

Hm, for some reason it works. It still looks like a hack, though. Why printing to STDERR is the way to debug this? Why STDERR is only shown on success? I'm still not sure about this.

@makenowjust But why does this example work? Judging from your code, running ./bar.cr should print the stderr of ./foo.cr to stdout, thus including it in main.cr...

@asterite

It still looks like a hack, though.

Debugging tastes like hacking sometime ;)

Why printing to STDERR is the way to debug this? Why STDERR is only shown on success?

Why losing STDERR output is right? This PR comes from that.

@straight-shoota I've already exaplained:

Success executing... is printed on compile-time, and it shows run-time STDERR output.

I think this is generally useful, but how about we just connect the invoked program's stderr to the compiler's? that is we print the stderr of the called file to the compiler's stderr in any case and maybe just prefix it with something like From bar.cr: