Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #7103 > unrolled thread

Only Allow exec in CLI

Back to article view | Back to comp.lang.php

Contents

  Only Allow exec in CLI cph <cloudpresshosting@gmail.com> - 2012-09-23 16:14 -0700
    Re: Only Allow exec in CLI gordonb.1zi9u@burditt.org (Gordon Burditt) - 2012-09-23 20:06 -0500
      Re: Only Allow exec in CLI cph <cloudpresshosting@gmail.com> - 2012-09-23 18:30 -0700
        Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-23 22:26 -0400
    Re: Only Allow exec in CLI "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-09-24 13:07 +0200
      Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-24 12:43 +0100
        Re: Only Allow exec in CLI Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-09-24 14:08 +0200
          Re: Only Allow exec in CLI Michael Vilain <vilain@NOspamcop.net> - 2012-09-24 10:45 -0700
            Re: Only Allow exec in CLI Michael Fesser <netizen@gmx.de> - 2012-09-24 23:57 +0200
        Re: Only Allow exec in CLI "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-09-24 14:16 +0200
        Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-24 13:19 +0100
          Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-24 13:54 +0100
            Re: Only Allow exec in CLI Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-09-24 16:04 +0200
              Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-24 15:14 +0100
              Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-24 16:09 +0100
                Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-24 19:07 +0100
            Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 02:47 -0600
              Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 11:00 +0100
                Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 04:35 -0600
                  Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-25 11:44 +0100
                    Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 05:31 -0600
                  Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 12:27 +0100
                    Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-25 12:41 +0100
                      Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 12:52 +0100
                        Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-25 14:23 +0100
                          Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 14:46 +0100
                            Re: Only Allow exec in CLI Tim Streater <timstreater@greenbee.net> - 2012-09-25 15:55 +0100
                              Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 16:13 +0100
                          Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 15:05 +0100
                          Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 15:05 +0100
                          Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 12:16 -0600
                      Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 08:10 -0400
                    Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 07:45 -0400
                      Re: Only Allow exec in CLI Anders Wegge Keller <wegge@wegge.dk> - 2012-09-25 14:57 +0200
                        Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 09:03 -0400
                          Re: Only Allow exec in CLI Anders Wegge Keller <wegge@wegge.dk> - 2012-09-25 15:37 +0200
                            Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 12:10 -0400
                              Re: Only Allow exec in CLI Anders Wegge Keller <wegge@wegge.dk> - 2012-09-25 18:25 +0200
                                Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 14:24 -0400
                                  Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 12:38 -0600
                                    Re: Only Allow exec in CLI Anders Wegge Keller <wegge@wegge.dk> - 2012-09-25 20:45 +0200
                                      Re: Only Allow exec in CLI Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-25 16:08 -0400
                        Re: Only Allow exec in CLI Michael Fesser <netizen@gmx.de> - 2012-09-25 15:12 +0200
                          Re: Only Allow exec in CLI Anders Wegge Keller <wegge@wegge.dk> - 2012-09-25 15:39 +0200
                        Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 14:35 +0100
        Re: Only Allow exec in CLI megazzorro <megazzorro.5jed61@no-mx.httppoint.com> - 2012-09-24 08:22 -0400
        Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 02:39 -0600
          Re: Only Allow exec in CLI Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-09-25 09:10 -0600
            Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 16:17 +0100
            Re: Only Allow exec in CLI crankypuss <no@email.thanks> - 2012-09-25 12:20 -0600
              Re: Only Allow exec in CLI The Natural Philosopher <tnp@invalid.invalid> - 2012-09-25 19:32 +0100
        Re: Only Allow exec in CLI Ryan <rbilesky@gmail.com> - 2012-09-27 10:23 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#7126

On 09/25/2012 04:44 AM, Tim Streater wrote:
> In article <k3s1dg018u@news1.newsguy.com>, crankypuss <no@email.thanks>
> wrote:
>
>> That means the "wrapper" addition for PHP over and above what would be
>> needed for a "shell script" amounts to the "<?php" and "?>" lines.
>> For that you get to use a programming language instead of a script
>> abomination; mileage varies, obviously.
>
> Yes, not having to use shell script utter shite to do some work is worth
> any possible bit of extra inefficiency (always assuming there is some),
> given that it saves lots of *my* time.

Run some actual timing tests and you may find that PHP can be quite 
efficient.

An extra 50 microseconds or even a couple milliseconds more than a C 
program can achieve might be a big deal running in a high-traffic 
server, but as part of an interactive program where most time is spent 
waiting for the user to decide what to do, it's invisible.

[toc] | [prev] | [next] | [standalone]

#7125

crankypuss wrote:
> On 09/25/2012 04:00 AM, The Natural Philosopher wrote:
>> crankypuss wrote:
>>> On 09/24/2012 06:54 AM, The Natural Philosopher wrote:
>>>> Tim Streater wrote:
>>>>> In article <k3ph16$7ur$5@news.albasani.net>,
>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>
>>>>>> M. Strobel wrote:
>>>>>> > Am 24.09.2012 01:14, schrieb cph:
>>>>>> >> For security I am looking to add exec() and similar commands to
>>>>>> the >> disable functions >> setting in php.ini but I do have a need
>>>>>> to execute command line commands >> within a cron job I am writing in
>>>>>> PHP.
>>>>>> > > The answer is highly dependent on your system setup, as has been
>>>>>> said > already. I would start with a check to see if different .ini
>>>>>> files
>>>>>> > for web server and CLI are in place already.
>>>>>
>>>>>> I cant imagine why anyone would put PHP in a cron job to start with.
>>>>>>
>>>>>> Shell script or C, or both...
>>>>>
>>>>> Neither. PHP is a lot easier to write and I can't see that there's
>>>>> going to be a great deal that you can't do in PHP that you can with
>>>>> the others. Unless you need every last CPU cycle of course.
>>>>>
>>>> Actually there is a very great deal you can do in C that you cant do in
>>>> PHP.
>>>>
>>>> Multitasking for one thing.
>>>
>>> I find PHP to be an order of magnitude more capable than shell 
>>> scripting.
>>>
>>>     http://php.net/manual/en/function.pcntl-fork.php
>>>
>>
>> yebbut when you have 5 C programs you want to run one after another,
>> creating a php wrapper is overkill.
> 
> If all the arguments are constants, a shell script might do the job as 
> long as you don't bother checking results.  It seems that "modern" 
> programmers don't need to check for unusual conditions because of their 
> godlike programming prowess, but being an old-school geezer it's a 
> longstanding habit I'm unable to discard as a result of lacking the 
> godlike wisdom of newbies.
> 
> The minute you start attempting to parse arguments or do anything else 
> in shell scripts you are resorting to sed or awk or whatever and just 
> doing a simple strpos() becomes a nightmare.
> 
> Do whatever suits you, I find that in general shell scripts are for 
> "ineptocrats" who don't care about error checking and the associated logic.
> 
> The overhead for a php "script" is trivial:
> 
>     #!/usr/bin/php
>     <?php
>         // ini_set('include_path', '/usr/lib/php-local');
>         // include_once 'includes_cli-app.php';
>     ?>
> 
> Of course the ini_set and include_once lines are optional for use by 
> those of us who practice code reuse in addition to other practices like 
> error checking (and most systems don't have a /usr/lib/php-local).  Many 
> of the subroutines I use in PHP "scripts" are also used by PHP 
> page-generation code, and most will operate under Windows or Linux.
> 
> That means the "wrapper" addition for PHP over and above what would be 
> needed for a "shell script" amounts to the "<?php" and "?>" lines.  For 
> that you get to use a programming language instead of a script 
> abomination; mileage varies, obviously.
> 
Mo. I still have to write all the exec() calls.

Consider the case. I have 4 programs I want to run serially  under a 
cron script

I set up the script like this

#!/bin/sh
program1
program2
program3
program4


Now tell me what else I have to add to make that run under php.


Or why on earth I would want to.



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7127

In article <k3s4f8$6ni$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Mo. I still have to write all the exec() calls.
> 
> Consider the case. I have 4 programs I want to run serially  under a 
> cron script
> 
> I set up the script like this
> 
> #!/bin/sh
> program1
> program2
> program3
> program4
> 
> Now tell me what else I have to add to make that run under php.
> 
> Or why on earth I would want to.

If it's as simple as that there's prolly no point. Mind you, I'd prolly 
still do it in PHP because I wouldn't be aware that you can run an 
executable in a script just by giving its name; I avoid all knowledge of 
shell scripting.

And, are you saying that programs 1, 2, 3, and 4 always run successfully 
and don't have any failure modes? No checking of result codes required 
or error handling needed?

In your case you have 4 lines of code and run 4 executables. In my app I 
have some 11,500 lines of PHP and still run just the 4 executables.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#7129

Tim Streater wrote:
> In article <k3s4f8$6ni$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Mo. I still have to write all the exec() calls.
>>
>> Consider the case. I have 4 programs I want to run serially  under a 
>> cron script
>>
>> I set up the script like this
>>
>> #!/bin/sh
>> program1
>> program2
>> program3
>> program4
>>
>> Now tell me what else I have to add to make that run under php.
>>
>> Or why on earth I would want to.
> 
> If it's as simple as that there's prolly no point. Mind you, I'd prolly 
> still do it in PHP because I wouldn't be aware that you can run an 
> executable in a script just by giving its name; I avoid all knowledge of 
> shell scripting.
> 
> And, are you saying that programs 1, 2, 3, and 4 always run successfully 

No

> and don't have any failure modes?

No

> No checking of result codes required 
> or error handling needed?
> 

Yes. If they fail. they fail gracefully. and they leave errors in their 
logfiles.

And because C has better tools, they can be deigned to fail gracefully.



> In your case you have 4 lines of code and run 4 executables. In my app I 
> have some 11,500 lines of PHP and still run just the 4 executables.
> 

I rest my case :-)


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7134

In article <k3s5u9$9hl$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:

> > No checking of result codes required or error handling needed?

> Yes. If they fail. they fail gracefully. and they leave errors in their 
> logfiles.

Are they independent of each other then, such that they could be run in 
parallel? Or are there failure modes for program x that would mean you'd 
not want to run x+1 etc ??

> And because C has better tools, they can be deigned to fail gracefully.

What tools are you referring to? 

> > In your case you have 4 lines of code and run 4 executables. In my app I 
> > have some 11,500 lines of PHP and still run just the 4 executables.
> > 
> 
> I rest my case :-)

<smack> :-)

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#7138

Tim Streater wrote:
> In article <k3s5u9$9hl$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
> 
>> > No checking of result codes required or error handling needed?
> 
>> Yes. If they fail. they fail gracefully. and they leave errors in 
>> their logfiles.
> 
> Are they independent of each other then, such that they could be run in 
> parallel? Or are there failure modes for program x that would mean you'd 
> not want to run x+1 etc ??
> 

The are quasi autonomous.

The data gathering parts stuff semi real time data in a database,. which 
if it fails simply uses the previous value and copies it into 'latest'

i.e. it's of the form.

get last from database
If new data, overwrite it, else leave it
put it back in new database entry.

That was written first to get the data into the database way before 
other code was written to summarise it and graph it

I kept it separate because I did not want to risk the data gathering 
operation whilst I wrote the analysis and presentation stuff. Bugs in 
that, that cause crashes, do not corrupt the data.

It was a context specific decision. The sort of thing Jerry simply 
doesn't understand. Its not 'The Right Way' but in this case I felt it 
was the optimal way.

Mutatis mutandis, the code could have been written in PHP or C. I chose 
C because I am more familar with its way of handling errors. And it has 
slightly better tools to deal with things like timeouts on sockets and 
so on.

In short the two languages are pretty equivalent : PHP has better screen 
output tools and HTML specific tools - the ability to spit out raw HTML 
without 'printf' -ing it is the one reason I use it.

But I hate its sloppy typing. Its a hacker's language.





>> And because C has better tools, they can be deigned to fail gracefully.
> 
> What tools are you referring to?
>> > In your case you have 4 lines of code and run 4 executables. In my 
>> app I > have some 11,500 lines of PHP and still run just the 4 
>> executables.
>> >
>> I rest my case :-)
> 
> <smack> :-)
> 


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7141

In article <k3sciu$oup$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> Tim Streater wrote:
> > In article <k3s5u9$9hl$1@news.albasani.net>,
> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> > 
> >> Tim Streater wrote:
> > 
> >> > No checking of result codes required or error handling needed?
> > 
> >> Yes. If they fail. they fail gracefully. and they leave errors in 
> >> their logfiles.
> > 
> > Are they independent of each other then, such that they could be run in 
> > parallel? Or are there failure modes for program x that would mean you'd 
> > not want to run x+1 etc ??

> Mutatis mutandis, the code could have been written in PHP or C. I chose 
> C because I am more familar with its way of handling errors. And it has 
> slightly better tools to deal with things like timeouts on sockets and 
> so on.
> 
> In short the two languages are pretty equivalent : PHP has better screen 
> output tools and HTML specific tools - the ability to spit out raw HTML 
> without 'printf' -ing it is the one reason I use it.
> 
> But I hate its sloppy typing. Its a hacker's language.

OK. I think I know which website you're updating with this scheme :-) 
and I'd agree that your approach is the best possible in the 
circumstance.

But I disagree about PHP's typing. I find the relaxed typing saves me a 
lot of trouble. Same in JavaScript, where the only place I've been 
caught out recently by types is as follows:

i = 3;                         // i is a nice integer
elmntPtr.dataset.i = i;        // Now save this for later use

...

i = elmntPtr.dataset.i;        // Get my i value back

switch (i)                     // Doesn't effing work, i is a string

switch (parseInt(i))           // OTOH, this works


So the only place I've been fooled is by the fact that the HTML5 dataset 
attribute is always a string, which I discovered by trial & error and 
reading the spec. Very irritating.

Otherwise the loose typing rules make for a relaxing life.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#7143

Tim Streater wrote:
> In article <k3sciu$oup$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
>> > In article <k3s5u9$9hl$1@news.albasani.net>,
>> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>> > >> Tim Streater wrote:
>> > >> > No checking of result codes required or error handling needed?
>> > >> Yes. If they fail. they fail gracefully. and they leave errors in 
>> >> their logfiles.
>> > > Are they independent of each other then, such that they could be 
>> run in > parallel? Or are there failure modes for program x that would 
>> mean you'd > not want to run x+1 etc ??
> 
>> Mutatis mutandis, the code could have been written in PHP or C. I 
>> chose C because I am more familar with its way of handling errors. And 
>> it has slightly better tools to deal with things like timeouts on 
>> sockets and so on.
>>
>> In short the two languages are pretty equivalent : PHP has better 
>> screen output tools and HTML specific tools - the ability to spit out 
>> raw HTML without 'printf' -ing it is the one reason I use it.
>>
>> But I hate its sloppy typing. Its a hacker's language.
> 
> OK. I think I know which website you're updating with this scheme :-) 

:-)
> and I'd agree that your approach is the best possible in the circumstance.
> 
> But I disagree about PHP's typing. I find the relaxed typing saves me a 
> lot of trouble. Same in JavaScript, where the only place I've been 
> caught out recently by types is as follows:
> 
> i = 3;                         // i is a nice integer
> elmntPtr.dataset.i = i;        // Now save this for later use
> 
> ...
> 
> i = elmntPtr.dataset.i;        // Get my i value back
> 
> switch (i)                     // Doesn't effing work, i is a string
> 
> switch (parseInt(i))           // OTOH, this works
> 
> 
> So the only place I've been fooled is by the fact that the HTML5 dataset 
> attribute is always a string, which I discovered by trial & error and 
> reading the spec. Very irritating.
> 
> Otherwise the loose typing rules make for a relaxing life.
> 
You try writing a parser for a data packet which has headers  many of 
whose content TYPES depend on what the header was, in a loosely typed 
language.

Javascript is even worse as I found one instance that simply isn't 
catered for by any spec, and IE and Firefox did the opposite things with it.


That cost me more time than any loose typing might have saved..


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7139

Tim Streater wrote:
> In article <k3s5u9$9hl$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
> 
>> > No checking of result codes required or error handling needed?
> 
>> Yes. If they fail. they fail gracefully. and they leave errors in 
>> their logfiles.
> 
> Are they independent of each other then, such that they could be run in 
> parallel? Or are there failure modes for program x that would mean you'd 
> not want to run x+1 etc ??
> 

The are quasi autonomous.

The data gathering parts stuff semi real time data in a database,. which
if it fails simply uses the previous value and copies it into 'latest'

i.e. it's of the form.

get last from database
If new data, overwrite it, else leave it
put it back in new database entry.

That was written first to get the data into the database way before
other code was written to summarise it and graph it

I kept it separate because I did not want to risk the data gathering
operation whilst I wrote the analysis and presentation stuff. Bugs in
that that acuse carshes do not corrupt


>> And because C has better tools, they can be deigned to fail gracefully.
> 
> What tools are you referring to?
>> > In your case you have 4 lines of code and run 4 executables. In my 
>> app I > have some 11,500 lines of PHP and still run just the 4 
>> executables.
>> >
>> I rest my case :-)
> 
> <smack> :-)
> 


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7140

Tim Streater wrote:
> In article <k3s5u9$9hl$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Tim Streater wrote:
> 
>> > No checking of result codes required or error handling needed?
> 
>> Yes. If they fail. they fail gracefully. and they leave errors in 
>> their logfiles.
> 
> Are they independent of each other then, such that they could be run in 
> parallel? Or are there failure modes for program x that would mean you'd 
> not want to run x+1 etc ??
> 

The are quasi autonomous.

The data gathering parts stuff semi real time data in a database,. which
if it fails simply uses the previous value and copies it into 'latest'

i.e. it's of the form.

get last from database
If new data, overwrite it, else leave it
put it back in new database entry.

That was written first to get the data into the database way before
other code was written to summarise it and graph it

I kept it separate because I did not want to risk the data gathering
operation whilst I wrote the analysis and presentation stuff. Bugs in
that, that cause crashes, do not corrupt the data.

It was a context specific decision. The sort of thing Jerry simply
doesn't understand. Its not 'The Right Way' but in this case I felt it
was the optimal way.

Mutatis mutandis, the code could have been written in PHP or C. I chose
C because I am more familar with its way of handling errors. And it has
slightly better tools to deal with things like timeouts on sockets and
so on.

In short the two languages are pretty equivalent : PHP has better screen
output tools and HTML specific tools - the ability to spit out raw HTML
without 'printf' -ing it is the one reason I use it.

But I hate its sloppy typing.





>> And because C has better tools, they can be deigned to fail gracefully.
> 
> What tools are you referring to?
>> > In your case you have 4 lines of code and run 4 executables. In my 
>> app I > have some 11,500 lines of PHP and still run just the 4 
>> executables.
>> >
>> I rest my case :-)
> 
> <smack> :-)
> 


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#7152

On 09/25/2012 07:23 AM, Tim Streater wrote:
> In article <k3s5u9$9hl$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Tim Streater wrote:
>
>> > No checking of result codes required or error handling needed?
>
>> Yes. If they fail. they fail gracefully. and they leave errors in
>> their logfiles.
>
> Are they independent of each other then, such that they could be run in
> parallel? Or are there failure modes for program x that would mean you'd
> not want to run x+1 etc ??
>
>> And because C has better tools, they can be deigned to fail gracefully.
>
> What tools are you referring to?
>> > In your case you have 4 lines of code and run 4 executables. In my
>> app I > have some 11,500 lines of PHP and still run just the 4
>> executables.
>> >
>> I rest my case :-)
>
> <smack> :-)

I have a superstitious belief that it's bad luck to argue with morons.

[toc] | [prev] | [next] | [standalone]

#7130

On 9/25/2012 7:41 AM, Tim Streater wrote:
> In article <k3s4f8$6ni$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Mo. I still have to write all the exec() calls.
>>
>> Consider the case. I have 4 programs I want to run serially  under a
>> cron script
>>
>> I set up the script like this
>>
>> #!/bin/sh
>> program1
>> program2
>> program3
>> program4
>>
>> Now tell me what else I have to add to make that run under php.
>>
>> Or why on earth I would want to.
>
> If it's as simple as that there's prolly no point. Mind you, I'd prolly
> still do it in PHP because I wouldn't be aware that you can run an
> executable in a script just by giving its name; I avoid all knowledge of
> shell scripting.
>
> And, are you saying that programs 1, 2, 3, and 4 always run successfully
> and don't have any failure modes? No checking of result codes required
> or error handling needed?
>
> In your case you have 4 lines of code and run 4 executables. In my app I
> have some 11,500 lines of PHP and still run just the 4 executables.
>

Tim, haven't you learned yet?  TNP's not a programmer (or the EE he 
claims to be).  He doesn't know how to write programs.  All he can do is 
copy other people's code.  He has no idea why you might want all that code.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7128

On 9/25/2012 7:27 AM, The Natural Philosopher wrote:
> crankypuss wrote:
>> On 09/25/2012 04:00 AM, The Natural Philosopher wrote:
>>> crankypuss wrote:
>>>> On 09/24/2012 06:54 AM, The Natural Philosopher wrote:
>>>>> Tim Streater wrote:
>>>>>> In article <k3ph16$7ur$5@news.albasani.net>,
>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>
>>>>>>> M. Strobel wrote:
>>>>>>> > Am 24.09.2012 01:14, schrieb cph:
>>>>>>> >> For security I am looking to add exec() and similar commands to
>>>>>>> the >> disable functions >> setting in php.ini but I do have a need
>>>>>>> to execute command line commands >> within a cron job I am
>>>>>>> writing in
>>>>>>> PHP.
>>>>>>> > > The answer is highly dependent on your system setup, as has been
>>>>>>> said > already. I would start with a check to see if different .ini
>>>>>>> files
>>>>>>> > for web server and CLI are in place already.
>>>>>>
>>>>>>> I cant imagine why anyone would put PHP in a cron job to start with.
>>>>>>>
>>>>>>> Shell script or C, or both...
>>>>>>
>>>>>> Neither. PHP is a lot easier to write and I can't see that there's
>>>>>> going to be a great deal that you can't do in PHP that you can with
>>>>>> the others. Unless you need every last CPU cycle of course.
>>>>>>
>>>>> Actually there is a very great deal you can do in C that you cant
>>>>> do in
>>>>> PHP.
>>>>>
>>>>> Multitasking for one thing.
>>>>
>>>> I find PHP to be an order of magnitude more capable than shell
>>>> scripting.
>>>>
>>>>     http://php.net/manual/en/function.pcntl-fork.php
>>>>
>>>
>>> yebbut when you have 5 C programs you want to run one after another,
>>> creating a php wrapper is overkill.
>>
>> If all the arguments are constants, a shell script might do the job as
>> long as you don't bother checking results.  It seems that "modern"
>> programmers don't need to check for unusual conditions because of
>> their godlike programming prowess, but being an old-school geezer it's
>> a longstanding habit I'm unable to discard as a result of lacking the
>> godlike wisdom of newbies.
>>
>> The minute you start attempting to parse arguments or do anything else
>> in shell scripts you are resorting to sed or awk or whatever and just
>> doing a simple strpos() becomes a nightmare.
>>
>> Do whatever suits you, I find that in general shell scripts are for
>> "ineptocrats" who don't care about error checking and the associated
>> logic.
>>
>> The overhead for a php "script" is trivial:
>>
>>     #!/usr/bin/php
>>     <?php
>>         // ini_set('include_path', '/usr/lib/php-local');
>>         // include_once 'includes_cli-app.php';
>>     ?>
>>
>> Of course the ini_set and include_once lines are optional for use by
>> those of us who practice code reuse in addition to other practices
>> like error checking (and most systems don't have a
>> /usr/lib/php-local).  Many of the subroutines I use in PHP "scripts"
>> are also used by PHP page-generation code, and most will operate under
>> Windows or Linux.
>>
>> That means the "wrapper" addition for PHP over and above what would be
>> needed for a "shell script" amounts to the "<?php" and "?>" lines.
>> For that you get to use a programming language instead of a script
>> abomination; mileage varies, obviously.
>>
> Mo. I still have to write all the exec() calls.
>
> Consider the case. I have 4 programs I want to run serially  under a
> cron script
>
> I set up the script like this
>
> #!/bin/sh
> program1
> program2
> program3
> program4
>
>
> Now tell me what else I have to add to make that run under php.
>
>
> Or why on earth I would want to.
>
>
>

Why would you even set up a shell script to run the four programs from 
cron?  Why not just set cron up to run them itself?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7131

Jerry Stuckle <jstucklex@attglobal.net> writes:

> Why would you even set up a shell script to run the four programs
> from cron?  Why not just set cron up to run them itself?

 Can you answer that question yourself? I can think of several
situations where it makes sense. If you cannot see any of those, you
shouldn't comment on this subject.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#7132

On 9/25/2012 8:57 AM, Anders Wegge Keller wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> Why would you even set up a shell script to run the four programs
>> from cron?  Why not just set cron up to run them itself?
>
>   Can you answer that question yourself? I can think of several
> situations where it makes sense. If you cannot see any of those, you
> shouldn't comment on this subject.
>

I don't see any reason to write a script like TNP suggests, when cron 
can do it all by itself.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7136

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 9/25/2012 8:57 AM, Anders Wegge Keller wrote:
> > Jerry Stuckle <jstucklex@attglobal.net> writes:
> >
> >> Why would you even set up a shell script to run the four programs
> >> from cron?  Why not just set cron up to run them itself?
> >
> >   Can you answer that question yourself? I can think of several
> > situations where it makes sense. If you cannot see any of those, you
> > shouldn't comment on this subject.
> >
> 
> I don't see any reason to write a script like TNP suggests, when cron
> can do it all by itself.

 How about:

 * Ensuring that command a isn't started until command @ has completed
 * Limiting the number of concurrent processes.
 * Grouping the output from several processes into the same cron status mail.

 As I said: refrain from discussing a subject where you are so
woefully inadequate, that you cannot even see those simple reasons.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#7145

On 9/25/2012 9:37 AM, Anders Wegge Keller wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 9/25/2012 8:57 AM, Anders Wegge Keller wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> Why would you even set up a shell script to run the four programs
>>>> from cron?  Why not just set cron up to run them itself?
>>>
>>>    Can you answer that question yourself? I can think of several
>>> situations where it makes sense. If you cannot see any of those, you
>>> shouldn't comment on this subject.
>>>
>>
>> I don't see any reason to write a script like TNP suggests, when cron
>> can do it all by itself.
>
>   How about:
>
>   * Ensuring that command a isn't started until command @ has completed
>   * Limiting the number of concurrent processes.
>   * Grouping the output from several processes into the same cron status mail.
>
>   As I said: refrain from discussing a subject where you are so
> woefully inadequate, that you cannot even see those simple reasons.
>


cron job:

script1; script2; script3; script4

As you (paraphrased) said: refrain from discussing a subject where you 
are so woefully inadequate, that you cannot even see this simple example.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7146

Jerry Stuckle <jstucklex@attglobal.net> writes:

> script1; script2; script3; script4

 Said the guy who're too afraid to use the php classloader, because he
is afraid someone will make a mess of it.

 
> As you (paraphrased) said: refrain from discussing a subject where you
> are so woefully inadequate, that you cannot even see this simple
> example.

 My examples are still valid, even if you are determined to make an
ass out of yourself.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

[toc] | [prev] | [next] | [standalone]

#7156

On 9/25/2012 12:25 PM, Anders Wegge Keller wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> script1; script2; script3; script4
>
>   Said the guy who're too afraid to use the php classloader, because he
> is afraid someone will make a mess of it.
>

Ah, trolling again?  What's the difference between calling script1 in 
the cron job - or in a script which is called by the cron job?  Answer: 
nothing.


>
>> As you (paraphrased) said: refrain from discussing a subject where you
>> are so woefully inadequate, that you cannot even see this simple
>> example.
>
>   My examples are still valid, even if you are determined to make an
> ass out of yourself.
>

You said you had to use a script to:

  How about:

 > * Ensuring that command a isn't started until command @ has completed
 > * Limiting the number of concurrent processes.
 > * Grouping the output from several processes into the same cron
 > status mail.

I just showed you you're wrong.  And you can't stand that.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#7160

On 09/25/2012 12:24 PM, Jerry Stuckle wrote:
> On 9/25/2012 12:25 PM, Anders Wegge Keller wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> script1; script2; script3; script4
>>
>>   Said the guy who're too afraid to use the php classloader, because he
>> is afraid someone will make a mess of it.
>>
>
> Ah, trolling again?  What's the difference between calling script1 in
> the cron job - or in a script which is called by the cron job?  Answer:
> nothing.

Actually there'd be a tiny bit of added overhead due to the nested 
script processor if you called it in a script called by the cron job, so 
not /exactly/ nothing (but real close).

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web