More shell_exec issues

[skiflyer]

Ok, I'm running shell_exec/backtick on a program... all is fine... once'n awhile I send it an invalid path because well, it kicks back a harmless error I just parse away, and that's alot nicer than making sure I send well formatted path.

Now, for some reason that error message is showing up on my page.

If I cut and paste the relevant code to another php page and run it, all is fine, the error is parsed away and never shows up.

Does anyone know of anything which would cause this to happen?

To add to the confusion, it only happens on the error, when the program executes properly it processes the output correctly.

-Rob

 

[sleipnir214]

Sounds to me like there is a character in the error return from the external app that your script isn't catching.

Cutting and pasting the output and reprocessing probably changes unprintable characters.

I'd run the external app by hand in such a way as to generate an error, and pipe that error return to a file. Then take a look at the file with a hex editor to see what you've got. Want the best answers? Ask the best questions:

http://www.tuxedo.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[skiflyer]

I'll run it through that, but I think it's more complex than such.

A little more depth on the scenario.

I basically have
$output = shell_exec("$shell_cmd"

then later I parse up $output and print what I want to.

If I disable the parsing and printing, I still get that message on my page, it appears simply from the call.

-Rob

 

[BB101]

you can use ob_start() and ob_end_clean() to stop any output going to your page.

http://www.php.net/manual/en/ref.outcontrol.php

--BB

 

[skiflyer]

Sounds wonderful!

Doesn't work.

-Rob

 

[skiflyer]

How did I forget to mention, this is being inserted randomly on my page.

Different location depending on the parameters. It is not part of my printed output, it's literally getting inserted in the middle of a word which is generated by a separate function... and while the line it gets inserted to is constant, the position on that line is not even constant.

-Rob

 

[skiflyer]

So I tracked and hunted and spotted this bug down. And it was trully bizarre.

I had a function which read in a file... if I didn't read the file it didn't happen.

So I hard coded the file into the script, it happened again... odd.

So I shortened the file to basically nothing, it went away. I added it to a little info, and it came back... very strange indeed.

Something about this array reaching a certain size, and then being processed in any way, caused this error message to be printed to the page.

Even if I simply said
$lines=file("thisfile.ini"
echo serialize($lines);

It was printed out... not as part of the array that is lines, but just randomly somewhere in the serialized info.

I still have no idea what happened.

My workaround, for anyone who may ever run into such a problem, was to go to my main controller file, and just put a big ob_start(), ob_end_flush() around all my includes... I can't say I'm so pleased with the performance of the pages under this method... but it works, perhaps I'll try and refine the output buffering to the trouble areas and see if that helps. (I tried the very narrow scope of just the area giving the trouble, that didn't cut mustard).

-Rob

 

[sleipnir214]

There are some known issues with serialize, particularly with quotes in strings.

In situations where you are reading in data from a file and processing it, I recommend whenever possible doing it a line at a time. Want the best answers? Ask the best questions:

http://www.tuxedo.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[skiflyer]

No quoted strings here, and serialize was just one way in which I received this behavior in the testing environment.

In the actual environment I was using a foreach.

But are you suggesting using a fopen(), and a loop until EOF rather than file() is a better practice? And if so, why?

-Rob

 

[sleipnir214]

That's exactly what I'm saying.

The only time I open a file and slurp down its complete contents is when the file structure is simple and I know for a fact that the file will never get very large.

There are several reasons...

If I'm getting data-driven errors (which I suspect you are), I can put in enough footprinting to know exactly what single piece data is causing the error.

If I'm parsing the info into a data structure, I don't have to have the entire contents in the file twice (once from the file() statement, and once as I parse it).

I make a point of never loading anything into memory that I don't need. If I don't need the whole file at once, I don't read the whole file at once. Want the best answers? Ask the best questions:

http://www.tuxedo.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[skiflyer]

Understood... it is a small file though, about 5kb.

This has now gone to low priority, but perhaps i'll be playing with it again tomorrow.

In the meantime though, I don't know that that's where my error is coming from, because I hardcoded the entire file into my script.

I made it such that
$lines = "
blah blah
blah blah
blah blah";

$lines = split("\n", $lines);

rather than the $lines=file("config.ini"

And the error remains, the error being the output of an error message from another unrelated function.

I'll let you know if that helps things any when I have the time to play with it.

-Rob