in reply to Re^3: how to supress stdout
in thread how to supress stdout

First, standard output is redirected to /dev/null. Assuming 1 is standard output file descriptor & 2 is standard error, standard error is also redirected to the same place as standard output (which is to /dev/null).

Above will work only when a bourne-like shell (FreeBSD /bin/sh, bash, zsh, etc.) handles the redirection.

Replies are listed 'Best First'.
Re^5: how to supress stdout
by ikegami (Patriarch) on Dec 13, 2008 at 17:26 UTC
    Aren't fd 1 and 2 stdout and stderr by definition?

      Yes, they are.

      As for the assumption in "Assuming 1 is standard output ...", if fd's 1 & 2 have been already closed & opened to some other fd's (before redirection), would fd's 1 & 2 still work for the purpose (of redirection after being redirected)?

        I don't see why > would depend on the previous state of the file descriptors. If the fd is closed, > should reopen it.

        And that's what I see happening:

        $ ( echo foo ) 1>&- -bash: echo: write error: Bad file descriptor $ ( echo foo > /dev/tty ) 1>&- foo
Re^5: how to supress stdout
by Bloodnok (Vicar) on Dec 13, 2008 at 16:54 UTC
    ... and there's me thinking that is only true if the re-direction is done in the shell - perl seems to 'know' how 'proper' re-direction works when done as in this example i.e. in a call to one of the open() functions.

    Maybe it's senility setting in big time ??

    A user level that continues to overstate my experience :-))
      No, Perl doesn't know. open invokes the shell when it sees shell meta characters such as > in the command.
        ikegami, I was commenting on observations we made on my last project (Strawberry perl on XP & Win2K3), where we resorted to using proper re-direction in a call to open() coz it (appeared to) work - having tried and failed to use it [proper redirection] in a DOS command window.

        A user level that continues to overstate my experience :-))