PHP exec throwing unexpected results

Question

I am trying to automate my deployment using phing. I get the below error when I use svnlastrevision task

Execution of target "builddiff" failed for the following reason: /home/ramjee/Work/Projects/it/dev-stack/build.xml:88:1: Failed to parse the output of 'svn info --xml'.

On debugging the issue further I zeroed it on to the following:

The following is a small program to recreate the issue:

$cmd = "/usr/bin/svn info --non-interactive '/home/ramjee/Work/Projects/trunk/src' '--xml'";
exec("$cmd 2>&1",$out,$ret_var);

print_r($out);

When I execute the above

i. With PHP (5.2.17) that is shipped with bitnami lampstack.1.2-5. I get the following result (not expected):

Array
(
    [0] => /usr/bin/svn: /home/ramjee/Work/lampstack-1.2-5/common/lib/libsasl2.so.2: no version information available (required by /usr/lib/libldap_r-2.4.so.2)
    [1] => /usr/bin/svn: /home/ramjee/Work/lampstack-1.2-5/common/lib/libsasl2.so.2: no version information available (required by /usr/lib/libsvn_ra_svn-1.so.1)
    [2] => <?xml version="1.0"?>
    [3] => <info>
    [4] => <entry
    [5] =>    kind="dir"
    [6] =>    path="/home/ramjee/Work/Projects/trunk/src"
    [7] =>    revision="818">
    [8] => <url>svn://abc.abc.abc.abc/data/repositories/src</url>
    [9] => <repository>
    [10] => <root>svn://abc.abc.abc.abc/data/repositories/</root>
    [11] => <uuid>f74a063e-5e8e-11e0-b400-13ff509e0209</uuid>
    [12] => </repository>
    [13] => <wc-info>
    [14] => <schedule>normal</schedule>
    [15] => <depth>infinity</depth>
    [16] => </wc-info>
    [17] => <commit
    [18] =>    revision="802">
    [19] => <author>shweta</author>
    [20] => <date>2012-01-03T12:07:46.427638Z</date>
    [21] => </commit>
    [22] => </entry>
    [23] => </info>
)

ii. With PHP (5.3.17) which was part of a lampp setup. I get the following result (expected):

Array
(
    [0] => <?xml version="1.0"?>
    [1] => <info>
    [2] => <entry
    [3] =>    kind="dir"
    [4] =>    path="/home/ramjee/Work/Projects/trunk/src"
    [5] =>    revision="818">
    [6] => <url>svn://abc.abc.abc.abc/data/repositories/src</url>
    [7] => <repository>
    [8] => <root>svn://abc.abc.abc.abc/data/repositories/</root>
    [9] => <uuid>f74a063e-5e8e-11e0-b400-13ff509e0209</uuid>
    [10] => </repository>
    [11] => <wc-info>
    [12] => <schedule>normal</schedule>
    [13] => <depth>infinity</depth>
    [14] => </wc-info>
    [15] => <commit
    [16] =>    revision="802">
    [17] => <author>shweta</author>
    [18] => <date>2012-01-03T12:07:46.427638Z</date>
    [19] => </commit>
    [20] => </entry>
    [21] => </info>
)

In the first line we have two unwanted lines which cause the phing task to throw error.

I don't know how to fix this? Any help on this will be very valuable.

Have a look at http://ubuntuforums.org/showpost.php?p=5883384&postcount=3 and see if that fixes your issue. — cmbuckley, Jan 05 '12 at 13:36
I tried that, and it doesn't help. I guess in this case, the libraries are picked from lamp path and not the shared library path. (though not sure) — rAm, Jan 05 '12 at 23:26
A hacky workaround would be to remove the `2>&1` part of the exec, as the XML seems valid otherwise. As far as the error is concerned, I only found [this](http://stackoverflow.com/questions/3535110/svnserve-and-sasl-problem). Also, [a bit more info](http://stackoverflow.com/questions/137773/what-does-the-no-version-information-available-error-from-linux-dynamic-linker) on shared objects. — cmbuckley, Jan 06 '12 at 00:02
Wonderful the hack worked, any idea what is the impact of this change. I have to make this change in a third party library so little concerned about the impact (also if you can put it as an answer will select it). — rAm, Jan 06 '12 at 02:08

score 1 · Accepted Answer · edited May 23 '17 at 12:03

This is not a great solution, as it simply masks the problem (and potentially other problems), but you can remove the 2>&1 part from the exec:

exec($cmd, $out, $ret_var);

2>&1 is used in bash to redirect STDERR (where the first 2 lines are being sent) to STDOUT (where the XML is sent) — see this question for more information.

The impact of this is that you're masking the error, and any other errors that you may encounter in the future from that command. Here's a longer solution that still involves you patching the library, but at least feels like less of a hack:

$cmd = "/usr/bin/svn info --non-interactive '/home/ramjee/Work/Projects/trunk/src' '--xml'";

$descriptors = array(
    1 => array('pipe', 'w'), // stdout
    2 => array('pipe', 'w')  // stderr
);

$process = proc_open($cmd, $descriptors, $pipes);

$out = $err = '';
while ($data = fgets($pipes[1])) { $out .= $data; } // contains your XML
while ($data = fgets($pipes[2])) { $err .= $data; } // contains any errors (which you can log)

thanks cbuckley, since this is an internal application for me (used to automate my build), I am going on with first solution. But thanks for the detailed solution. — rAm, Jan 07 '12 at 05:19

PHP exec throwing unexpected results

1 Answers1