in reply to Re: How to stop printing the output of a command on screen when the command fails?
in thread How to stop printing the output of a command on screen when the command fails?

Roboticus,your suggesting doesnt seem to working,why is it so?

foreach my $file (@changed_files) { my $p4where_output=`p4 where $file 2>&1`; print "P4 where output:$p4where_output\n"; if($p4where_output =~ /file(s) not in client view/) { push @changed_paths,"$file\n"; }
  • Comment on Re^2: How to stop printing the output of a command on screen when the command fails?
  • Download Code

Replies are listed 'Best First'.
Re^3: How to stop printing the output of a command on screen when the command fails?
by cdarke (Prior) on Dec 24, 2010 at 12:12 UTC
    Roboticus's suggestion should have worked, and is the simplest solution. Some programs (not many) do not write to stderr, but to the terminal driver direct. Check the documentation for the product you are using that it is actually writing to stderr. If that does not tell you, then run it under strace(1) or truss(1) to check (these are UNIX/Linux commands which trace kernel calls).

      What's confusing me is,if I run the below command from command prompt I see stderr getting supressed but where as when I run it in perl using backticks it fails,what could be going wrong>

      >p4 where //depot/perl/tools/files/data.c > NUL: 2>&1
        it fails is rather unspecific, but I'm guessing you mean that the error message is still displayed on the screen.

        So, what is the difference betweeen "command prompt" and using back-ticks? The most obvious is the shell you are using for "command prompt". I can't find in your posts which operating system you are using. The path style is UNIX-like, yet the use of NUL: is Windows (on UNIX/Linux you would use /dev/null).

        I just tried a simple version of your command on Windows and Linux and it worked as I would expect - no output was displayed on either. It was not using p4 though.