In article <VlSZa.32119$Rz6.46595@news1.mts.net>, LHradowy wrote:
>
>> >I want to run the cron every 4 weeks is it possible?
>>
>> Run it every week and keep a counter in a file. When it counts up to 4,
>> run the rest of the script and reset it back to 0.
>>
>> --
>That sound like what I want but what do you mean, run it every week, I do
>not want the off line running every week. How do you put in a counter...

Or do arithmetic based on time() and division by 4.

#!/usr/bin/perl -w
$now=time()/86400;
printf("Day mod 4 is %d\n", $now % 4);
exit(1) if ($now % 4);
exit(0);
# Adapt the script or use the exit code to launch the job.


--
<peter30kyari@zwallet.com> AWAIT[S] YOUR URGENT RESPONCE
5% will be use for upsetting all the expenses

On 11 Aug 2003 20:13:47 GMT, all mail refused <elvis@notatla.org.uk> wrote:
>
>
> In article <VlSZa.32119$Rz6.46595@news1.mts.net>, LHradowy wrote:
>>
>>> >I want to run the cron every 4 weeks is it possible?
>>>
>>> Run it every week and keep a counter in a file. When it counts up to 4,
>>> run the rest of the script and reset it back to 0.
>>>
>>> --
>>That sound like what I want but what do you mean, run it every week, I do
>>not want the off line running every week. How do you put in a counter...
>
> Or do arithmetic based on time() and division by 4.
>
> #!/usr/bin/perl -w
> $now=time()/86400;
> printf("Day mod 4 is %d\n", $now % 4);
> exit(1) if ($now % 4);
> exit(0);
> # Adapt the script or use the exit code to launch the job.
>
>

Nice, but it will use many times the system resources of a shell script.

And not everyone HAS perl. (Or wants it.)


Alan




--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.

Alan Connor wrote:
>
> On 11 Aug 2003 20:13:47 GMT, all mail refused <elvis@notatla.org.uk> wrote:
> >
> >
> > In article <VlSZa.32119$Rz6.46595@news1.mts.net>, LHradowy wrote:
> >>
> >>> >I want to run the cron every 4 weeks is it possible?
> >>>
> >
> > Or do arithmetic based on time() and division by 4.
> >
> > #!/usr/bin/perl -w
> > $now=time()/86400;
> > printf("Day mod 4 is %d\n", $now % 4);
> > exit(1) if ($now % 4);
> > exit(0);
> > # Adapt the script or use the exit code to launch the job.
> >
> >
>
> Nice, but it will use many times the system resources of a shell script.

... which in turn will use many times the system resources
of a C program, which will be just a little less efficient than
an assembly program, which might be just a hair less efficient
than a program written in numeric machine language.

The big question: At one program execution per week, how
many centuries will it take for these differences to become
noticeable?

> And not everyone HAS perl. (Or wants it.)

That's a more reasonable criticism.

--
Eric.Sosman@sun.com

On Mon, 11 Aug 2003 17:31:42 -0400, Eric Sosman <Eric.Sosman@sun.com> wrote:
>
>
> Alan Connor wrote:
>>
>> On 11 Aug 2003 20:13:47 GMT, all mail refused <elvis@notatla.org.uk> wrote:
>> >
>> >
>> > In article <VlSZa.32119$Rz6.46595@news1.mts.net>, LHradowy wrote:
>> >>
>> >>> >I want to run the cron every 4 weeks is it possible?
>> >>>
>> >
>> > Or do arithmetic based on time() and division by 4.
>> >
>> > #!/usr/bin/perl -w
>> > $now=time()/86400;
>> > printf("Day mod 4 is %d\n", $now % 4);
>> > exit(1) if ($now % 4);
>> > exit(0);
>> > # Adapt the script or use the exit code to launch the job.
>> >
>> >
>>
>> Nice, but it will use many times the system resources of a shell script.
>
> ... which in turn will use many times the system resources
> of a C program, which will be just a little less efficient than
> an assembly program, which might be just a hair less efficient
> than a program written in numeric machine language.
>
> The big question: At one program execution per week, how
> many centuries will it take for these differences to become
> noticeable?
>






>> And not everyone HAS perl. (Or wants it.)
>
> That's a more reasonable criticism.
>

No. My first observation was quite accurate. No one is going to write a

a C program for a little thing like this, and if they did, they would need
a compiler and a linker which would use rather a lot system resources.

The shell, which would have to be used in order to make use of the compiler
and linker, is already there.


I repeat: Using perl in a situation like this would consume far more
resources than a bash script, and is therefore not wise.

If you don't see the sense of that, then stay away from any computer I own.


Alan



--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.

On Mon, 11 Aug 2003 at 23:09 GMT, Barry Margolin wrote:
> In article <KTUZa.2397$7z1.1660@newsread3.news.pas.earthlink. net>,
> Alan Connor <alanconnor@earthlink.net> wrote:
>>I repeat: Using perl in a situation like this would consume far more
>>resources than a bash script, and is therefore not wise.
>
> You're suffering from premature optimization.

...

> Like he said, if it's only executing once a week, the difference in
> resources is most likely negligible.

Agreed.

> When the performance impact isn't a real problem, optimizing for
> ease of maintenance is often more wise.

Which is one reason I stay away from Perl (and sed).

> BTW, have you actually done a comparison between the resource consumption
> of the shell and perl? Some years ago I rewrote a program from C to Perl,
> and with a little tweaking I was able to make the Perl version as fast as
> the C version.

Speed of execution is not the same thing as resource consumption.
In fact, they may be inversely related. The memory and CPU time
needed to get that speed in Perl will be greater than that for an
equivalent C program.

--
Chris F.A. Johnson http://cfaj.freeshell.org
================================================== =================
My code (if any) in this post is copyright 2003, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

On Mon, 11 Aug 2003 23:09:41 GMT, Barry Margolin <barry.margolin@level3.com> wrote:
>
>
> In article <KTUZa.2397$7z1.1660@newsread3.news.pas.earthlink. net>,
> Alan Connor <alanconnor@earthlink.net> wrote:
>>I repeat: Using perl in a situation like this would consume far more
>>resources than a bash script, and is therefore not wise.
>
> You're suffering from premature optimization.
>
> Like he said, if it's only executing once a week, the difference in
> resources is most likely negligible. When the performance impact isn't a
> real problem, optimizing for ease of maintenance is often more wise.
>

Your ignoring the fact that you have to HAVE perl on your system to do this
at all....you already have the shell, right?

And WHEN that perl program is running, it is using a LOT more resources
than the shell script, right?


> BTW, have you actually done a comparison between the resource consumption
> of the shell and perl? Some years ago I rewrote a program from C to Perl,
> and with a little tweaking I was able to make the Perl version as fast as
> the C version.
>

Interesting.

But how about resource use at the time it is running?

Perl size 1148610

bash size 415338

But the shell is going to be there ANYWAY. (and spare me any of the
"you can use perl as a shell" rhetoric. If it could be, you can bet all
the perl addicts would be doing at.


As near as I can tell, perl is a weird language stuck in limbo: Overkill for
shell jobs and indadequate for C jobs.

Another one of those cases where the easy road turns out to lead nowhere.

I'm thinking of overall sysadmin strategy, and can't conceive of why one
would choose to have perl on the system at all.

All those little "oh it doesn't matter for such a small job"s add up!

I removed perl from my system quite a while back, and don't notice the lack.

A pleasure,


Alan

--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.

In article <r3WZa.3049$Nf3.2310@newsread4.news.pas.earthlink. net>,
Alan Connor wrote:

>As near as I can tell, perl is a weird language stuck in limbo: Overkill for
>shell jobs and indadequate for C jobs.

You can't be doing anything like what I've been doing for the last 10 years.
Perl is almost a life-saver, ranking in importance with gcc and ssh. If
I still had to do it in sh and 2 flavours of awk I'd have gone mad.

From the perspective of the OP simplicity was probably of most importance.

--
<peter30kyari@zwallet.com> AWAIT[S] YOUR URGENT RESPONCE
5% will be use for upsetting all the expenses

On 12 Aug 2003 03:07:33 GMT, all mail refused <elvis@notatla.org.uk> wrote:
>
>
> In article <r3WZa.3049$Nf3.2310@newsread4.news.pas.earthlink. net>,
> Alan Connor wrote:
>
>>As near as I can tell, perl is a weird language stuck in limbo: Overkill for
>>shell jobs and indadequate for C jobs.
>
> You can't be doing anything like what I've been doing for the last 10 years.
> Perl is almost a life-saver, ranking in importance with gcc and ssh. If
> I still had to do it in sh and 2 flavours of awk I'd have gone mad.
>
> From the perspective of the OP simplicity was probably of most importance.
>

Your perl program is no simpler than the script ChrisFAJ polished up.

Which will run with a fraction of the system resources and will run on any
system with an sh-type shell. There's a hell of a lot more of those than
there are systems with perl.

What have you been doing? Bet I know people who could do it with sh and sed.


Alan


--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.

Alan Connor wrote:
> Which will run with a fraction of the system resources and will run on any
> system with an sh-type shell. There's a hell of a lot more of those than
> there are systems with perl.

Don't be too sure. It depends somewhat on your environment. For instance, on
my desktop system, there are currently 2800 processes running, 40 of them are
perl, none of them are bash. So, I ran the following two scripts:

cat b1
#!/bin/bash
ret=1
.. counterfile
counter=$(( ( $counter + 1 ) % 4 ))
if [ $counter -eq 0 ]
then
ret=0
fi
echo "counter=$counter" > counterfile
exit $ret

And

cat b2
#!/bin/perl
$now=time()/86400;
exit(1) if ($now % 4);
exit(0);

The first results in 115 page faults, the second caused 91. The bash example ran
with .013 seconds user time and .020 seconds system time. The perl example ran
in .014 seconds user, and .018 system. The real time for bash was .2 seconds,
the perl was .08 seconds. When running, both programs map in most of the same
libraries. If we assume that all the shared segments are already in memory, then
the writable pages unique to each is as follows:
b1 = 344Kb, b2 = 312Kb. So, the perl script consumes less non-shared storage.

So, I would say that resources-wise there is no clear winner here. They are pretty
much the same. A far cry from bash using "a fraction of the system resources" that
perl does.
--
blu

Never play poker with those whom you show card tricks and never show card
tricks to those with whom you play poker.
--------------------------------------------------------------------------------
Brian Utterback - Solaris Sustaining (NFS/Naming) - Sun Microsystems Inc.,
Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom

On Tue, 12 Aug 2003 11:28:20 -0400, Brian Utterback <Brian.Utterback@Sun.removeme.COM> wrote:
>
>
> Alan Connor wrote:
>> Which will run with a fraction of the system resources and will run on any
>> system with an sh-type shell. There's a hell of a lot more of those than
>> there are systems with perl.
>
> Don't be too sure. It depends somewhat on your environment. For instance, on
> my desktop system, there are currently 2800 processes running, 40 of them are
> perl, none of them are bash. So, I ran the following two scripts:
>
> cat b1
> #!/bin/bash
> ret=1
> . counterfile
> counter=$(( ( $counter + 1 ) % 4 ))
> if [ $counter -eq 0 ]
> then
> ret=0
> fi
> echo "counter=$counter" > counterfile
> exit $ret
>
> And
>
> cat b2
> #!/bin/perl
> $now=time()/86400;
> exit(1) if ($now % 4);
> exit(0);
>
> The first results in 115 page faults, the second caused 91. The bash example ran
> with .013 seconds user time and .020 seconds system time. The perl example ran
> in .014 seconds user, and .018 system. The real time for bash was .2 seconds,
> the perl was .08 seconds. When running, both programs map in most of the same
> libraries. If we assume that all the shared segments are already in memory, then
> the writable pages unique to each is as follows:
> b1 = 344Kb, b2 = 312Kb. So, the perl script consumes less non-shared storage.
>
> So, I would say that resources-wise there is no clear winner here. They are pretty
> much the same. A far cry from bash using "a fraction of the system resources" that
> perl does.


I think a more realistic comparison would involve using bash and various utilities or C programs (which is where sensible people go when bash etc. aren't
enough) instead of perl on that desktop.

All you are saying is that perl is already in memory and therefore using it
oesn't waste any MORE resources.

Considering that you had to invoke bash to run the bashscript, its comparitive
performance is pretty amazing.

Perl addicts are just insufferable.....


:-)


Alan











--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.