 Only Allow exec in CLI [message #179174] |
Sun, 23 September 2012 23:14  |
cph
Messages: 10
Registered: September 2012
Karma: 0
|
Junior Member |
|
|
|
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. I believe I heard this is possible but I would just like to confirm this or find a workaround.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179180 is a reply to message #179179] |
Mon, 24 September 2012 12:08  |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/24/2012 1:43 PM, The Natural Philosopher 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.
>>
>> /Str.
>
> I cant imagine why anyone would put PHP in a cron job to start with.
>
> Shell script or C, or both...
>
Hi TNP,
When I have written a lot of functionality in PHP, and only need to run
some small part of it, then a cronjob is the fastest way to implement that.
I have a bunch of scripts that run both as webpage or cronjob, depending
on a single param in the querystring.
eg:
sendDailyEmails.php?cronjob=Y
If the cronjob=Y is there, the script won't produce any output.
If it isn't there, It will be very verbose. The output I used to inspect
and debug.
The same script can be called from the admin-pages, and as a cronjob.
So, sometimes it is easy to make PHP run as a cronjob.
To stay remotely relevant to this thread, let me add this:
On my install I had 2 different php.ini's: one for apache for normal
webrequests, one for the cronjob.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179186 is a reply to message #179185] |
Mon, 24 September 2012 14:14 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 9/24/2012 2:54 PM, The Natural Philosopher wrote:
>> Tim Streater wrote:
>>> In article <k3ph16$7ur$5(at)news(dot)albasani(dot)net>,
>>> The Natural Philosopher <tnp(at)invalid(dot)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.
>>
>
> Of course there are many things you can do in C and not in PHP.
> Like writing drivers for your graphics card.
>
> But realistically, what multitasking cronjobs do you exactly envision
> here? I cannot think of one.
>
Multitasking *for one thing*. Not the only difference. ONE difference.
There are dozens more libraries doing custom stuff better than PHP .
Else why would the OP NEED to 'exec'?
> Regards,
> Erwin Moller
>
>
--
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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179187 is a reply to message #179185] |
Mon, 24 September 2012 15:09 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 9/24/2012 2:54 PM, The Natural Philosopher wrote:
>> Tim Streater wrote:
>>> In article <k3ph16$7ur$5(at)news(dot)albasani(dot)net>,
>>> The Natural Philosopher <tnp(at)invalid(dot)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.
>>
>
> Of course there are many things you can do in C and not in PHP.
> Like writing drivers for your graphics card.
>
> But realistically, what multitasking cronjobs do you exactly envision
> here? I cannot think of one.
>
Multitasking *for one thing*. Not the only difference. ONE difference.
There are dozens more libraries doing custom stuff better than PHP .
Else why would the OP NEED to 'exec'?
SNMP support is gruesome in PHP, though its not a lot better in 'C',
admittedly. :-)
> Regards,
> Erwin Moller
>
>
--
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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179188 is a reply to message #179180] |
Mon, 24 September 2012 17:45 |
Michael Vilain
Messages: 88
Registered: September 2010
Karma: 0
|
Member |
|
|
In article <50604d45$0$6941$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
Erwin Moller <erwinmollerusenet(at)xs4all(dot)nl> wrote:
> On 9/24/2012 1:43 PM, The Natural Philosopher 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.
>>>
>>> /Str.
>>
>> I cant imagine why anyone would put PHP in a cron job to start with.
>>
>> Shell script or C, or both...
>>
>
> Hi TNP,
>
> When I have written a lot of functionality in PHP, and only need to run
> some small part of it, then a cronjob is the fastest way to implement that.
>
> I have a bunch of scripts that run both as webpage or cronjob, depending
> on a single param in the querystring.
> eg:
>
> sendDailyEmails.php?cronjob=Y
>
> If the cronjob=Y is there, the script won't produce any output.
> If it isn't there, It will be very verbose. The output I used to inspect
> and debug.
> The same script can be called from the admin-pages, and as a cronjob.
>
> So, sometimes it is easy to make PHP run as a cronjob.
>
> To stay remotely relevant to this thread, let me add this:
> On my install I had 2 different php.ini's: one for apache for normal
> webrequests, one for the cronjob.
>
> Regards,
> Erwin Moller
Actually, Drupal has a specific script that runs as a cron to check for
updates. And when stuff runs as a cron, the parameter passing uses the
CLI p1 p2 p3 arguments rather than the web-style "?cronjob=Y". There
must be an environment variable you can query in php that will tell you
it's being run as a CLI or CGI script.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
|
|
|
|
| Re: Only Allow exec in CLI [message #179189 is a reply to message #179187] |
Mon, 24 September 2012 18:07 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <k3pt3a$44d$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Erwin Moller wrote:
>> On 9/24/2012 2:54 PM, The Natural Philosopher wrote:
>>> Tim Streater wrote:
>>>> In article <k3ph16$7ur$5(at)news(dot)albasani(dot)net>,
>>>> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>>>> > 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.
>>>
>>
>> Of course there are many things you can do in C and not in PHP.
>> Like writing drivers for your graphics card.
>>
>> But realistically, what multitasking cronjobs do you exactly envision
>> here? I cannot think of one.
> Multitasking *for one thing*. Not the only difference. ONE difference.
>
> There are dozens more libraries doing custom stuff better than PHP .
>
> Else why would the OP NEED to 'exec'?
Prolly to do specific things that you can't do in PHP. Hmmm, furtle,
furtle:
Looks like I do it:
1) to open a file using the designated app for the file, in a window on
the user's screen. So I do:
$cmd = "/usr/bin/open \"" . $filename . "\" 2>&1";
exec ($cmd, $results, $result);
or possibly:
exec ("/usr/bin/open -a Safari.app 'http://...");
2) Starting and stopping apache, as in:
$cmd = "/usr/sbin/httpd -f \"" . $fno . "\" 2>&1";
exec ($cmd, $results, $result);
or the same with -k stop.
But I agree, these are not in cron jobs. Although if I had a cron job to
run I'd prolly do it in PHP if at all possible.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179194 is a reply to message #179193] |
Tue, 25 September 2012 10:35 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
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(at)news(dot)albasani(dot)net>,
>>>> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179196 is a reply to message #179194] |
Tue, 25 September 2012 11:27 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)news(dot)albasani(dot)net>,
>>>> > The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179198 is a reply to message #179196] |
Tue, 25 September 2012 11:41 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <k3s4f8$6ni$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)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
|
|
|
|
| Re: Only Allow exec in CLI [message #179199 is a reply to message #179196] |
Tue, 25 September 2012 11:45 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)news(dot)albasani(dot)net>,
>>>> >> The Natural Philosopher <tnp(at)invalid(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Only Allow exec in CLI [message #179200 is a reply to message #179198] |
Tue, 25 September 2012 11:52 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <k3s4f8$6ni$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179201 is a reply to message #179198] |
Tue, 25 September 2012 12:10 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 9/25/2012 7:41 AM, Tim Streater wrote:
> In article <k3s4f8$6ni$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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(at)attglobal(dot)net
==================
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Only Allow exec in CLI [message #179209 is a reply to message #179205] |
Tue, 25 September 2012 13:46 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <k3s5u9$9hl$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179210 is a reply to message #179205] |
Tue, 25 September 2012 14:05 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <k3s5u9$9hl$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179211 is a reply to message #179205] |
Tue, 25 September 2012 14:05 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <k3s5u9$9hl$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: Only Allow exec in CLI [message #179212 is a reply to message #179209] |
Tue, 25 September 2012 14:55 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <k3sciu$oup$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Tim Streater wrote:
>> In article <k3s5u9$9hl$1(at)news(dot)albasani(dot)net>,
>> The Natural Philosopher <tnp(at)invalid(dot)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
|
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]