piping cmd output problem

Discussion in 'Perl Misc' started by dimsol@gmail.com, Mar 22, 2005.

  1. Guest

    Hi

    I have the following scenarion:

    open(FILE, "some_cmd |") || die "some error message";
    my $output = <FILE>;
    close(FILE) || die "some error message";

    The problem is that some_cmd failes (exit status 1) and prints error
    message to STDOUT.

    The return value of open() according to man pages is the pid of forked
    process.
    Now, the problem, how I can find out that some_cmd failed.

    BR
    Dima
     
    , Mar 22, 2005
    #1
    1. Advertising

  2. Guest

    wrote:
    > Hi
    >
    > I have the following scenarion:
    >
    > open(FILE, "some_cmd |") || die "some error message";
    > my $output = <FILE>;
    > close(FILE) || die "some error message";
    >
    > The problem is that some_cmd failes (exit status 1) and prints error
    > message to STDOUT.
    >
    > The return value of open() according to man pages is the pid of forked
    > process.
    > Now, the problem, how I can find out that some_cmd failed.


    Since you say it prints the error message to its STDOUT, which has been
    redirected into Perl's file handle FILE, why don't you just read the error
    message from FILE? Alternatively, inspect $! and/or $? when either the
    open or the close fails.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Mar 22, 2005
    #2
    1. Advertising

  3. wrote:

    > Hi
    >
    > I have the following scenarion:
    >
    > open(FILE, "some_cmd |") || die "some error message";
    > my $output = <FILE>;
    > close(FILE) || die "some error message";
    >
    > The problem is that some_cmd failes (exit status 1) and prints error
    > message to STDOUT.
    >
    > The return value of open() according to man pages is the pid of forked
    > process.
    > Now, the problem, how I can find out that some_cmd failed.


    Think logically. You cannot get this answer from open() because that
    would need information to travel backwards in time. So perhaps the
    information is available from close().

    perldoc -f close
     
    Brian McCauley, Mar 23, 2005
    #3
  4. Guest

    Re: piping cmd output problem

    Parsing output of some_cmd is not good idea, since I can't filter all
    error messages (I just don't know all possibilities and in the future
    the author of some_cmd can add/modify them).

    The safest and the simplest way is to know exit status of some_cmd.
    $? returns zero.
    close doesn't fail (since FILE is open file descriptor)

    Dima
     
    , Mar 23, 2005
    #4
  5. Dima Guest

    Re: piping cmd output problem

    Parsing output of some_cmd is not good idea, since I can't filter all
    error messages (I just don't know all possibilities and in the future
    the author of some_cmd can add/modify them).

    The safest and the simplest way is to know exit status of some_cmd.
    $? returns zero.
    close doesn't fail (since FILE is open file descriptor)

    Dima
     
    Dima, Mar 23, 2005
    #5
  6. Guest

    Re: piping cmd output problem

    "" <> wrote:
    > Parsing output of some_cmd is not good idea, since I can't filter all
    > error messages (I just don't know all possibilities and in the future
    > the author of some_cmd can add/modify them).


    So you are running a program that you have no control over and don't
    understand what types of output it presents, yet you expect meaningful
    results?

    > The safest and the simplest way is to know exit status of some_cmd.


    Really? If the author of the program just makes up error messges
    wily-nily, why do you expect the he is more conscientious with the exit
    status?

    > $? returns zero.


    Then maybe there isn't actually an error occurring.

    > close doesn't fail (since FILE is open file descriptor)


    If the file handle came from a piped open "close" will addi-
    tionally return false if one of the other system calls
    involved fails or if the program exits with non-zero status.
    (If the only problem was that the program exited non-zero $!
    will be set to 0.) Closing a pipe also waits for the
    process executing on the pipe to complete, in case you want
    to look at the output of the pipe afterwards, and implicitly
    puts the exit status value of that command into $?.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Mar 23, 2005
    #6
  7. Joe Smith Guest

    Re: piping cmd output problem

    Dima wrote:

    > close doesn't fail (since FILE is open file descriptor)


    Just because FILE is an open file descriptor does not mean
    that close(FILE) will never fail. You need to check the
    docs on close() - it shows how to do what you want.
    -Joe
     
    Joe Smith, Mar 24, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Achim Domma (Procoders)

    read input for cmd.Cmd from file

    Achim Domma (Procoders), Jun 3, 2005, in forum: Python
    Replies:
    2
    Views:
    8,099
    Peter Otten
    Jun 3, 2005
  2. Sarir Khamsi

    Interpreter-like help in cmd.Cmd

    Sarir Khamsi, Jun 9, 2005, in forum: Python
    Replies:
    4
    Views:
    389
    Bengt Richter
    Jun 26, 2005
  3. =?ISO-8859-1?Q?Sch=FCle_Daniel?=

    [exec cmd for cmd in cmds]

    =?ISO-8859-1?Q?Sch=FCle_Daniel?=, Mar 8, 2006, in forum: Python
    Replies:
    3
    Views:
    397
    Scott David Daniels
    Mar 8, 2006
  4. Diez B. Roggisch

    pydb remote debugging/cmd.Cmd over socket?

    Diez B. Roggisch, May 28, 2008, in forum: Python
    Replies:
    2
    Views:
    559
    Diez B. Roggisch
    May 29, 2008
  5. Diez B. Roggisch

    cmd.Cmd bug or at least docu-bug

    Diez B. Roggisch, May 29, 2008, in forum: Python
    Replies:
    1
    Views:
    347
    Michele Simionato
    May 29, 2008
Loading...

Share This Page