httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allasso Travesser <allassopra...@gmail.com>
Subject [users@httpd] command line app behaves differently when called from http request context
Date Sat, 08 Mar 2014 17:07:55 GMT
Hello,

I have a command line app, apertium, that I am trying to run from cgi script.  It is an english
to spanish translator, and I have observed that the output of the command is different (and
incorrect or UTF-8 encoding) when run from an http request, than when run on the command line
on the server.  Specifically, non-ascii characters are not as they should be.

I am trying to run the command using system call from a cgi script.  I have tried using various
system/shell_exec type calls (system(), shell_exec(), backticks, open(), etc) from both PHP
and Perl scripts, but all give the same results.

My question will be, is there any reason an app should behave differently when called from
an htttp request context than its normal usage on the system?

Here are the details:

apertium works like this:

echo “english phrase” | apertium en-es

Output is the translated phrase.

So for test in my script, I have for example in test.pl (test.php is similar):

print "Content-type: text/html\n\n”;
print "<pre>".`echo "to me" | apertium en-es | xxd`."</pre>";
print "<pre>".`echo "to me" | apertium en-es`."</pre>";

When I run test.pl directly on the command line, output is (excluding the html):

0000000: 4120 6dc3 ad0a                           A m…

A mí

which is expected behavior.

HOWEVER,

When calling test.pl from an http request, the output on the displayed web page is:

0000000: 4120 236d 3f0a                           A #m?.
A #m?
Please note that as long as the output falls in the ascii range, there is no problem, it is
only when output is non-ascii characters.

Using php script yields the same result.  I have the default character encode in php set to
UTF-8.  I am not aware of any similar setting in mod_perl.

The output of xxd reveals to me that the problem has nothing to do with browser behavior,
etc.

Thinking that the problem may have to do with piping in the system call from the script, I
ran a variant test in which apertium reads the contents of a file and outputs to a file:

apertium en-es infile outfile

Checking the contents of outfile in each case reveals the same behavior.

I also tried (skeptically) changing users to the user when processing http requests before
running the command on the command line, e.g.: su www-data

But it doesn’t matter which user, if run from command line, behavior is one way, (correct
way), if run from http request, behavior is incorrect.

Thank you very kindly for any helpful input.

Allasso



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message