in reply to Re^5: The importance of avoiding the shell
in thread The importance of avoiding the shell

At least on my machine, it doesn't:

C:\Users\Corion>perl -le "warn 'foo';print 'bar'" foo at -e line 1. bar C:\Users\Corion>perl -le "warn 'foo';print 'bar'" >tmp.txt foo at -e line 1. C:\Users\Corion>perl -le "warn 'foo';print 'bar'" 2>&1 >tmp.txt foo at -e line 1. C:\Users\Corion>ver Microsoft Windows [Version 6.1.7601] C:\Users\Corion>

Update: And I think I've been using the shell direction wrong, because it understands it if I redirect the filehandles in a different order:

C:\Users\Corion>perl -le "warn 'foo';print 'bar'" >tmp.txt 2>&1 C:\Users\Corion>type tmp.txt foo at -e line 1. bar

I always think "First, redirect filehandle 2 to filehandle 1, then redirect the output to filehandle 1 to a file.". But that this is wrong and I need to do it the other way around.

Replies are listed 'Best First'.
Re^7: The importance of avoiding the shell
by BrowserUk (Patriarch) on Sep 27, 2014 at 13:42 UTC
    Update: And I think I've been using the shell direction wrong, because it understands it if I redirect the filehandles in a different order: ... But that this is wrong and I need to do it the other way around.

    Indeed. It does seem somewhat backwards, but it has always been that way.

    When 2>&1 is seen, stderr is redirected to wherever stdout is pointing at that time. If you then redirect stdout somewhere else, stderr is not then re-redirected.

    So if you want to redirect both to the same place, you have to redirect stdout first; then 2>&1 does the expected thing.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.