Re: [PHP] Problem with "shell_exec"

2010-12-05 Thread Boyan Penev
Hello,

i am sorry for it took ridiculously long for me to respond, but i have been
struggling with the issue ever since. I still don't really know what the
problem was, but i have managed to solve it through a shortcut.

I have tried everything recommended from you. In php.ini the shell_exec
wasn't listed under "disabled functions". I have tried adding a new user
with the (i presume) right permissions and starting the server through it. I
have tried busybox httpd and lighttpd with the new user, as well as with the
old "nobody". I have installed bash (instead of busyboxs' shell) and even
tried installing it in the root server folder (/var/www)- still the problem
persisted.

What i have done today is compiling php through buildroot and than copy over
the binary php-cgi to the embedded system. It worked like a charm- out of
the box, without the adjustments i made previously. So it seems- to me- that
this was a cross- compiling issue on my side. I don't know what have i done
wrong with the compilation, but right now i don't have much time to look it
up- i must proceed with the project. If i find out what was causing the
problem, i will be sure to post a solution here.

So- thank you very much. Your help is indeed appreciated.

Yours,

Boyan

1.

On Sun, Oct 31, 2010 at 11:24 PM,  wrote:

> After going over this a thousand times in my head and on sever.
> Here are a few reasons why a shell_exec will not function.
>
> First I tested the PHP CLI
> Can I see my version of php.
> $output = shell_exec('php -v');
> Echo $output;
> If I am not getting the information about the php version. Is shell_exec
> for
> php and http on?
>
> In your php.ini file there will be a section called disable_functions.
> If you are sure that shell_exec is not in the list.
>
>
> If neither of these are an issue for you, It has to be a permissions issue.
>
>
> I do not claim to be an expert in the shell_exec area of php, I cannot
> duplicate your error.
>
> Richard L. Buskirk
>
>
> -Original Message-
> From: Boyan Penev [mailto:boyan...@googlemail.com]
> Sent: Sunday, October 31, 2010 12:26 PM
> To: ad...@buskirkgraphics.com
> Cc: php-general@lists.php.net
> Subject: Re: [PHP] Problem with "shell_exec"
>
> Hello Richard,
>
> thank you for the prompt reply. I just tried to follow your suggestion, but
> i couldn't solve my problem:
>
> 1. I  have started the server with user "nobody". All the binaries i was
> trying to execute(e.g. /bin/ls) were "chown"-ed to the user "nobody"
> Problem presisted. Than i "chown" -ed /var/www to the user "nobody". Than
> the php and php-cgi interpreters as well- same thing.
> I tried the same with users "adm" and even "root"
>
> 2. I than gave the executables all the permissions possible("777"- i know
> it
> is dangerous, but i am just testing)- still nothing.
>  I copied the binaries from /bin to /var/www and tried to execute them
> with all kinds of permissions and "chown"'s- didn't work
>
> 3. Than i moved to the command line interpreter: i tried to execute it in
> /var/www and in the home folder. The permissions were also adjusted. I
> executed it with root privileges- i always get "Segmentation fault". One
> more thing- if i omit the arguments in shell_exec( "$output =
> shell_exec();)
> i get "Missing parameters" but no "Segmentation fault"
>
> Boyan
>
> On Sun, Oct 31, 2010 at 4:34 PM,  wrote:
>
> > It seems most probably a permission problem.  If I were you I would
> > check the permissions on the bin directory and the files in it.  PHP
> > will probably run under the uid of the webserver, which, on most
> > systems is either "apache" or "nobody" depending on the configuration.
> >
> > Richard L. Buskirk
> >
> >
> > -Original Message-
> > From: Boyan Penev [mailto:boyan...@googlemail.com]
> > Sent: Sunday, October 31, 2010 11:16 AM
> > To: php-general@lists.php.net
> > Subject: [PHP] Problem with "shell_exec"
> >
> > Hello,
> >
> > i have installed php 5.2.14 on an embedded system. I have run a couple of
> > test scripts and everything works fine,
> >  but i can't get "shell_exec" to work. When i invoke "shell_exec", the
> > script doesn't get interpreted, instead
> > i get prompted to download the whole .php file. I have tried both
> /bin/php
> > and /bin/php-cgi- same problem.
> > When i try to execute it per command line instead of web server, with
> both
> > php and php-cgi i get "Segmentation fault"
> > and nothing happens. I use busybox http as a web server, if it's
> relevant.
> > Does anybody have an idea what the problem
> > might be? Any help would be appreciated.
> >
> > Best regards,
> >
> > Boyan
> >
> >
>
>


[PHP] http request

2010-12-05 Thread Moses
Hi Everyone,

I would like to know whether there is a http request PHP script. I
would like to use in cases where a background script is running for
sometime and outputs the results in PHP once the script  has been executed.


Thanks.

musa


Re: [PHP] http request

2010-12-05 Thread Daniel Molina Wegener
On Sunday 05 December 2010,
Moses  wrote:

> Hi Everyone,

  Hello...

> 
> I would like to know whether there is a http request PHP script. I
> would like to use in cases where a background script is running for
> sometime and outputs the results in PHP once the script  has been
> executed.

  You can try cURL:

  http://php.net/manual/en/book.curl.php

> 
> 
> Thanks.
> 
> musa


Best regards,
-- 
Daniel Molina Wegener 
System Programmer & Web Developer
Phone: +56 (2) 979-0277 | Blog: http://coder.cl/


Re: [PHP] http request

2010-12-05 Thread Shreyas
I am not sure if I understand the question with clarity. What exactly  
do you mean by a HTTP request script?


Since it involves a web server to run the PHP script, the HTTP request  
and response will be the backbone of the whole transaction. But like I  
mentioned earlier, I could be seeing the question wrong.


--Shreyas

Sent from my iPhone

On 05-Dec-2010, at 18:09, Moses  wrote:


Hi Everyone,

I would like to know whether there is a http request PHP script. I
would like to use in cases where a background script is running for
sometime and outputs the results in PHP once the script  has been  
executed.



Thanks.

musa


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] desire your recommendation for our specific HTML -> PDF project

2010-12-05 Thread Tommy Pham
> -Original Message-
> From: Govinda [mailto:govinda.webdnat...@gmail.com]
> Sent: Friday, December 03, 2010 3:12 PM
> To: PHP-General List
> Subject: [PHP] desire your recommendation for our specific HTML -> PDF
> project
> 
> Hi all
> 
> I have a question which I see from googling has been discussed at length..
> but I want to know what you would recommend based on our particular
> needs.  I want to be on the right track before I find out a- week-of-work
> later that I chose the wrong tool (a tool which works, but whose
peculiarity,
> in the end, would rule it out for our project).
> 
> We have a dynamic HTML page that displays 30 "address labels" within the
> dimensions of one single US-letter-size document.  We want the user to be
> able to print the single letter-sized page and have the content line up
> perfectly (as it does in the browser) for the Avery address label
(printed)
> sticker paper which they will use to then peel the 30 stickers and affix
to
> physical product.  The HTML page is ~ 200k worth of HTML (s and
> s), text, gifs, jpgs, a barcode PNG graphic, and heavy use of
exacting
> CSS - CSS2 as well as a touch of CSS3 (CSS3 property transform), i.e.
this:
> /* --- for firefox, safari, chrome, etc. --- */
> -webkit-transform: rotate(90deg);
> -moz-transform: rotate(90deg);
> /* --- for ie --- */
> filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);
> 
> ...which I use to rotate (90 degrees) a barcode which I grab off of this
> site/service:
> http://www.barcodesinc.com/generator/index.php
> 
> We could drop that barcode PNG/service only if I could easily replace it
with
> another... and the barcode must be rotated 90 degrees - to thus fit in its
tiny
> (vertically-oriented) alloted slot on each of the
> 30 "address label cells".
> 
> A thread on stackOverflow has people making recommendations all over
> the map.. as I would expect - our needs and experiences are all over the
> map.
> 
> - I wish we had budget for the server version of PrinceXML ;-) ... but no
luck.
> - I have never used any PHP libraries like FPDF or TCPDF, but am concerned
> about speed; corporate users (on various browsers) will need the pdf in
real
> time.  They may be patient and wait for the final PDF if keep the solution
> free.. but if it takes minutes to generate, that is a minus point.

Govinda,

Have you/your team consider using pure CSS (using media screen & print) for
formatting?  This may save you from having to deal with PDF (extra codes ->
slower performance, extra steps in save then print, extra storage space just
for temp save, etc... ) since they only need to print as you mentioned.  If
you use CSS pt (1/72 inch) unit, you should get a pretty good precision.
IMO, I only see the need to save as/generate PDF if it's to create an
e-book, just to print to paper is not worth the time & effort. With either
method CSS/PDF, you'd still have to deal with the exact formatting & layout
(with PDF, you may have to twice - once for the screen and again in PDF).

> Also I am not sure how good these are for HTML -> PDF (as opposed to
> straight PDF from scratch).. plus not sure how good is the CSS support.
Our
> page is a bit of an HTML/CSS kludge.
> - I have used the command-line tools HTMLDOC and wkpdf, but the former
> lacked the CSS I need now, and the latter introduces margin that kills it
for
> exact address-label formatting (plus this project is on Linux).
> 
> My PHP skills are not super strong yet.. but I am willing to do whatever
it
> takes to pull any solution together.
> In case you have any familiarity with any PDF generation tools that you
feel
> would fit the need here, then *please advise*!
> 
> Thanks!
> -Govinda
> 
> 
> 
> Govinda
> govinda(DOT)webdnatalk(AT)gmail(DOT)com
> 
> 

Regards,
Tommy


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] desire your recommendation for our specific HTML -> PDF project

2010-12-05 Thread Govinda



Govinda,

Have you/your team consider using pure CSS (using media screen &  
print) for
formatting?  This may save you from having to deal with PDF (extra  
codes ->
slower performance, extra steps in save then print, extra storage  
space just
for temp save, etc... ) since they only need to print as you  
mentioned.  If
you use CSS pt (1/72 inch) unit, you should get a pretty good  
precision.

IMO, I only see the need to save as/generate PDF if it's to create an
e-book, just to print to paper is not worth the time & effort. With  
either
method CSS/PDF, you'd still have to deal with the exact formatting &  
layout
(with PDF, you may have to twice - once for the screen and again in  
PDF).


Tommy, thanks for taking the time to read my long post!  :-)

I tend to think like you too..  why make more work! ; I already got  
the thing laid out nice for the browser..
*but* the client is wary of the idea that every browser is going to  
have a slightly different rendition..and so we then have to either  
require use of one browser or another (and maintain the code as that  
browser version gets updated), or we have to code for lots of  
browsers.. and also code the mechanism by which either we sniff/detect  
which browser is being used.. or else the user tells the page which  
rendition they need - before printing.  As they ponder all that, and  
the budget.. the client said, "it must be PDF!"


-Govinda

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] desire your recommendation for our specific HTML -> PDF project

2010-12-05 Thread Tommy Pham
> -Original Message-
> From: Govinda [mailto:govinda.webdnat...@gmail.com]
> Sent: Sunday, December 05, 2010 9:19 AM
> Cc: 'PHP-General List'
> Subject: Re: [PHP] desire your recommendation for our specific HTML -> PDF
> project
> 
> >>
> > Govinda,
> >
> > Have you/your team consider using pure CSS (using media screen &
> > print) for
> > formatting?  This may save you from having to deal with PDF (extra
> > codes -> slower performance, extra steps in save then print, extra
> > storage space just for temp save, etc... ) since they only need to
> > print as you mentioned.  If you use CSS pt (1/72 inch) unit, you
> > should get a pretty good precision.
> > IMO, I only see the need to save as/generate PDF if it's to create an
> > e-book, just to print to paper is not worth the time & effort. With
> > either method CSS/PDF, you'd still have to deal with the exact
> > formatting & layout (with PDF, you may have to twice - once for the
> > screen and again in PDF).
> 
> Tommy, thanks for taking the time to read my long post!  :-)
> 
> I tend to think like you too..  why make more work! ; I already got the
thing
> laid out nice for the browser..
> *but* the client is wary of the idea that every browser is going to have a
> slightly different rendition..and so we then have to either require use of
> one browser or another (and maintain the code as that browser version gets
> updated), or we have to code for lots of browsers.. and also code the
> mechanism by which either we sniff/detect which browser is being used..
> or else the user tells the page which rendition they need - before
printing.
> As they ponder all that, and the budget.. the client said, "it must be
PDF!"
> 
> -Govinda
> 

IIRC, the browser rendering difference should only be on the screen and with
available fonts on the client.  But for print, if you use pt, it should be
accurate.  The only issue I see with print is the font difference on printer
and in the client's system, that's the printer driver problem.  If you use
some special fonts, then you'll have to create a PDF so acrobat can attempt
to rasterize it.  Another option is just generate each label as a picture
via GD, ImageMagick, etc..., then no problems with browser differences or
font issues  :D.  If you do generate pics or PDF, beware of the quality of
printer's dpi vs. visual screen.  Any decent printer should be able to print
1200 dpi, or at least 600 dpi.

Here's the sample CSS print media since 1pt = 1/72 inch, assuming you're
using Avery labels with 1/4 inch margins:

body { width: 100%; min-width: 756pt; text-align: center; }
div.container { width: 576pt /*8 / (1/72) */; height: 756pt /* 10.5 inch /
(1/72) */;  overflow: hidden; }
div.label { float: left; width: 192pt /*576 / 3 columns */;  height: 72pt /*
1 inch height label */; overflow: hidden; }

For the font size, you should use pt also - 10 or 11 pt is readable on the
print out.  Each label is inside the div and it should fit nicely.  If you
do with CSS, you can permit the users to change size of label, as their need
may change, with calculations from PHP to get dimensions (width & height of
the label).  If anyone can tell visually the difference of 1pt or fractions
thereof, that person isn't normal :))
 
Regards,
Tommy


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] desire your recommendation for our specific HTML -> PDF project

2010-12-05 Thread Govinda
IIRC, the browser rendering difference should only be on the screen  
and with

available fonts on the client.


I am finding just the opposite of what you are saying.  The page looks  
the same in the browsers.. but when I print from different browsers I  
get different results on paper.  Like just for starters - the top and  
left whitespace margin introduced by the browser.. (which is *outside*  
any margin I have set (or not set) with HTML/CSS) is different.  Also  
the scaling is different... as though I am using zoom/scaling in one  
print dialogue but not the other (even when I am not using any scaling  
options, while printing, in any of the print dialogues).



But for print, if you use pt, it should be
accurate.  The only issue I see with print is the font difference on  
printer
and in the client's system, that's the printer driver problem.  If  
you use
some special fonts, then you'll have to create a PDF so acrobat can  
attempt

to rasterize it.



Another option is just generate each label as a picture
via GD, ImageMagick, etc..., then no problems with browser  
differences or
font issues  :D.  If you do generate pics or PDF, beware of the  
quality of
printer's dpi vs. visual screen.  Any decent printer should be able  
to print

1200 dpi, or at least 600 dpi.


that is not a bad idea, in this case.  I enjoy exploring and getting  
good at lots of different solutions..  In the end, I'll have to defer  
to client and budget.  So far we are just gathering ideas before  
committing to trying something.  Budget is such that we need to do  
this only once if at all possible.


Here's the sample CSS print media since 1pt = 1/72 inch, assuming  
you're

using Avery labels with 1/4 inch margins:

body { width: 100%; min-width: 756pt; text-align: center; }
div.container { width: 576pt /*8 / (1/72) */; height: 756pt /* 10.5  
inch /

(1/72) */;  overflow: hidden; }
div.label { float: left; width: 192pt /*576 / 3 columns */;  height:  
72pt /*

1 inch height label */; overflow: hidden; }


Each label contains within it layered (z-index) divs, tables, graphics..
I did used pt for the font sizes (or em on top of a pt base font  
size)..  and I used inches as the length/width units.. so it was  
intuitive for layout on paper.


It looks great on screen (easy to line up with an AVERY template)..  
but now we just need to pin down the print method so the client's  
client can print reliably..  without needing to be technically involved.
I really appreciate your effort to help conceptualize.  Now if you  
feel like it, and have time.. try laying out a single letter-size page  
to print 30 address labels and then actually print that page from  
different browsers and see what you get.  Does your page's data cells  
(now printed on paper) exactly line up with the Avery template which  
you modeled after?  Are the tests from different browsers producing  
the exact same printout?


-Govinda

For the font size, you should use pt also - 10 or 11 pt is readable  
on the
print out.  Each label is inside the div and it should fit nicely.   
If you
do with CSS, you can permit the users to change size of label, as  
their need
may change, with calculations from PHP to get dimensions (width &  
height of
the label).  If anyone can tell visually the difference of 1pt or  
fractions

thereof, that person isn't normal :))

Regards,
Tommy



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP] desire your recommendation for our specific HTML -> PDF project

2010-12-05 Thread Tommy Pham
> -Original Message-
> From: Govinda [mailto:govinda.webdnat...@gmail.com]
> Sent: Sunday, December 05, 2010 1:33 PM
> Cc: 'PHP-General List'
> Subject: Re: [PHP] desire your recommendation for our specific HTML -> PDF
> project
> 
> > IIRC, the browser rendering difference should only be on the screen
> > and with available fonts on the client.
> 
> I am finding just the opposite of what you are saying.  The page looks the
> same in the browsers.. but when I print from different browsers I get
> different results on paper.  Like just for starters - the top and left
> whitespace margin introduced by the browser.. (which is *outside* any
> margin I have set (or not set) with HTML/CSS) is different.  Also the
scaling is
> different... as though I am using zoom/scaling in one print dialogue but
not
> the other (even when I am not using any scaling options, while printing,
in
> any of the print dialogues).
> 

That's because each browser has the a different page setup for printing,
margin, header & footer (including date, time, url, etc.).  You'll have
similar problems with PDF.  I have a few Word documents with 1/4 inch
margins saved as PDFs, via Acrobat Pro, to send out some folks.  When they
try to print w/o checking the configuration, Acrobat would just try to scale
and center, essentially reducing the overall size.  Either way, the user has
to check the configuration prior to printing just as they would have to set
the page layout in the word processor.  The only way I see around this is to
actually generate Word type document, where the user doesn't need to do
check the configuration.  Since Word format is proprietary, you'll might
some problems getting the code.

> > But for print, if you use pt, it should be accurate.  The only issue I
> > see with print is the font difference on printer and in the client's
> > system, that's the printer driver problem.  If you use some special
> > fonts, then you'll have to create a PDF so acrobat can attempt to
> > rasterize it.
> 
> > Another option is just generate each label as a picture via GD,
> > ImageMagick, etc..., then no problems with browser differences or font
> > issues  :D.  If you do generate pics or PDF, beware of the quality of
> > printer's dpi vs. visual screen.  Any decent printer should be able to
> > print
> > 1200 dpi, or at least 600 dpi.
> 
> that is not a bad idea, in this case.  I enjoy exploring and getting good
at lots
> of different solutions..  In the end, I'll have to defer to client and
budget.  So
> far we are just gathering ideas before committing to trying something.
> Budget is such that we need to do this only once if at all possible.
> 

I too like to do things right the first time :)

> > Here's the sample CSS print media since 1pt = 1/72 inch, assuming
> > you're using Avery labels with 1/4 inch margins:
> >
> > body { width: 100%; min-width: 756pt; text-align: center; }
> > div.container { width: 576pt /*8 / (1/72) */; height: 756pt /* 10.5
> > inch /
> > (1/72) */;  overflow: hidden; }
> > div.label { float: left; width: 192pt /*576 / 3 columns */;  height:
> > 72pt /*
> > 1 inch height label */; overflow: hidden; }
> 
> Each label contains within it layered (z-index) divs, tables, graphics..
> I did used pt for the font sizes (or em on top of a pt base font size)..
and I
> used inches as the length/width units.. so it was intuitive for layout on
> paper.
> 

IIRC, if you used em, it relies on each browser's font configuration.  So
you'll have to pt with !important.

> It looks great on screen (easy to line up with an AVERY template)..
> but now we just need to pin down the print method so the client's client
can
> print reliably..  without needing to be technically involved.
> I really appreciate your effort to help conceptualize.  Now if you feel
like it,
> and have time.. try laying out a single letter-size page to print 30
address
> labels and then actually print that page from different browsers and see
> what you get.  Does your page's data cells (now printed on paper) exactly
> line up with the Avery template which you modeled after?  Are the tests
> from different browsers producing the exact same printout?
> 
> -Govinda

Yup on the HP 2015 at 1200 dpi.  The only browsers that didn't print out
correctly (on Windows) are Chrome & Safari, both are web toolkit...  which I
can't seem to find the scaling on the print configuration.  Apparently, I'm
not the only person with the printing issue [1].   IE 8 (w/o compatibility -
shrink to fit off), Firefox 3.16 (shrink to fit off), and Opera 10.63 (fit
to paper width off and scale print to 100%)  have scaling capability.  All
have margins at 1/4 inch or .635 cm.  This is from my template a while back.

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>





@media all {
body { font: 11pt Arial, Helvetica, sans-serif !important; line-height:
1.25em; margin: 0; padding: 0;}
div { margin: 0; padding: 0; }

body { width: 100%; min-wi