I had a computer crash after several years and installed Linux Mint
20.

Previously I had the system set to run a computer test scene every
third day that the computer was turned on. Using crun (I think).

However with the /etc/cruntab of the version 20 I'm not having much
luck. Is it possible to schedule a printer test on every 3rd day the
computer is turned on with the newer crontab and if so can someone
post the actual coding necessary to do it?
--
Cheers,

John B.

On Mon, 30 Oct 2023 09:57:50 +0700, John B. <slocombjb@gmail.com>
wrote:

>
>I had a computer crash after several years and installed Linux Mint
>20.
>
>Previously I had the system set to run a computer test scene every
>third day that the computer was turned on. Using crun (I think).
>
>However with the /etc/cruntab of the version 20 I'm not having much
>luck. Is it possible to schedule a printer test on every 3rd day the
>computer is turned on with the newer crontab and if so can someone
>post the actual coding necessary to do it?

Sorry for the misspelling - it is actually "cron".
--
Cheers,

John B.

On 10/29/2023 11:00 PM, John B. wrote:
> On Mon, 30 Oct 2023 09:57:50 +0700, John B. <slocombjb@gmail.com>
> wrote:
>
>>
>> I had a computer crash after several years and installed Linux Mint
>> 20.
>>
>> Previously I had the system set to run a computer test scene every
>> third day that the computer was turned on. Using crun (I think).
>>
>> However with the /etc/cruntab of the version 20 I'm not having much
>> luck. Is it possible to schedule a printer test on every 3rd day the
>> computer is turned on with the newer crontab and if so can someone
>> post the actual coding necessary to do it?
>
>
> Sorry for the misspelling - it is actually "cron".
>

You asked about this eighteen years ago ? Plus or minus on the ID.

https://www.linuxquestions.org/questions/linux-software-2/regular-print-job-using-cron-or-something-308167/

Some of these articles can have so much advertising, they rail the browser
and prevented using the scroll bar. There is nothing like the whir of fans
as a greeting to a web site. The person fitting the advertising to this
site, deserves a smack (had to kill browser).

https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm

This version of that site, isn't hitting the machine quite as hard.
You can actually scroll down in here.

https://web.archive.org/web/20230529174744/https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm

There are actually whole books on using cron, but they're thin books
and the fan doesn't whir quite as loudly. Cron might be a lightweight
book like the Termcap book was.

You can see an example here, where someone puts a "gate" in their script,
to abort the "driving the printer part", if the day spacing is wrong.

https://stackoverflow.com/questions/4549542/cron-job-every-three-days

0 0 */3 * * # Only approximate, due to month length. The 3 day spacing is not honoured.

You could set the cron to run daily at a particular hour,
then inside the script, check whether the date is the right value or not.
Someones first attempt, was this on that web page.

if (((date('j') - 1) % 3))
exit();

The people in that thread keep working on it.

"If you want it to be every 3 days from a specific date, use the following format:"

0 0 * * * bash -c '(( $(date +\%s -d "2019-01-01") / 86400 \% 3 == 0 )) && runmyjob.sh'

When I work with dangerous materials like that, inside the runmyjob.sh to begin
with, I might "touch" a file somewhere, which provides evidence of what date and time
the script ran. And not actually put the print command in there.

This page will give you some ideas as to how to make "evidence" files in your script.
By making unique filenames, the files will not collide and there should be an
evidence trail. Now, a guy could foul this up, but this should give you the
idea. You could do /bin/touch "$now" once you have crafted a format of
$now with minutes and seconds perhaps.

https://www.cyberciti.biz/faq/unix-linux-appleosx-bsd-shell-appending-date-to-filename/

################################################################################

Any time you do things like this, you want to be aware of the level of
elevation the thing runs at, and whether something bad could happen in there.
For example, if your script contents were

/bin/rm -Rf * # Don't do this in a cron job

then you'd want to know exactly what part of the machine that could wipe
out, based on whether it ran as you or it ran as root or it ran as a
cron-specific account (with certain group memberships). You can have an
account, with group memberships that allow the script to do certain things.

Mixing commands like "rm" in a script, must be done with utmost care.
You haven't lived as root, until one of your commands start erasing
other peoples files :-/ (Yes, I've done that. They gave me a very tiny Tshirt.)

Sending a print job is relatively safe, compared to issuing an "rm",
but a cron job could still create mounds of cruft if poorly crafted.

We came into a computer room one day and the floor was covered to a
depth of three feet, in output device paper :-) That's when you
realize unattended operation is a mistake, when working with yoyos.
Don't be that guy. The paper for the device, is like $200.00 a roll.
It's at times like that, you're glad the rolls are of limited size.

Defensive programming is the name of the game. the hardest part, is
likely getting anything at all to run. Once your thingy is running,
you can move on up to adding content to it. Something other than
touch somefilename

Paul

On 10/29/2023 11:00 PM, John B. wrote:
> On Mon, 30 Oct 2023 09:57:50 +0700, John B. <slocombjb@gmail.com>
> wrote:
>
>>
>> I had a computer crash after several years and installed Linux Mint
>> 20.
>>
>> Previously I had the system set to run a computer test scene every
>> third day that the computer was turned on. Using crun (I think).
>>
>> However with the /etc/cruntab of the version 20 I'm not having much
>> luck. Is it possible to schedule a printer test on every 3rd day the
>> computer is turned on with the newer crontab and if so can someone
>> post the actual coding necessary to do it?
>
>
> Sorry for the misspelling - it is actually "cron".
>

You asked about this eighteen years ago ? Plus or minus on the ID.

https://www.linuxquestions.org/questions/linux-software-2/regular-print-job-using-cron-or-something-308167/

Some of these articles can have so much advertising, they rail the browser
and prevented using the scroll bar. There is nothing like the whir of fans
as a greeting to a web site. The person fitting the advertising to this
site, deserves a smack (had to kill browser).

https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm

This version of that site, isn't hitting the machine quite as hard.
You can actually scroll down in here.

https://web.archive.org/web/20230529174744/https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm

There are actually whole books on using cron, but they're thin books
and the fan doesn't whir quite as loudly. Cron might be a lightweight
book like the Termcap book was.

You can see an example here, where someone puts a "gate" in their script,
to abort the "driving the printer part", if the day spacing is wrong.

https://stackoverflow.com/questions/4549542/cron-job-every-three-days

0 0 */3 * * # Only approximate, due to month length. The 3 day spacing is not honoured.

You could set the cron to run daily at a particular hour,
then inside the script, check whether the date is the right value or not.
Someones first attempt, was this on that web page.

if (((date('j') - 1) % 3))
exit();

The people in that thread keep working on it.

"If you want it to be every 3 days from a specific date, use the following format:"

0 0 * * * bash -c '(( $(date +\%s -d "2019-01-01") / 86400 \% 3 == 0 )) && runmyjob.sh'

When I work with dangerous materials like that, inside the runmyjob.sh to begin
with, I might "touch" a file somewhere, which provides evidence of what date and time
the script ran. And not actually put the print command in there.

This page will give you some ideas as to how to make "evidence" files in your script.
By making unique filenames, the files will not collide and there should be an
evidence trail. Now, a guy could foul this up, but this should give you the
idea. You could do /bin/touch "$now" once you have crafted a format of
$now with minutes and seconds perhaps.

https://www.cyberciti.biz/faq/unix-linux-appleosx-bsd-shell-appending-date-to-filename/

################################################################################

Any time you do things like this, you want to be aware of the level of
elevation the thing runs at, and whether something bad could happen in there.
For example, if your script contents were

/bin/rm -Rf * # Don't do this in a cron job

then you'd want to know exactly what part of the machine that could wipe
out, based on whether it ran as you or it ran as root or it ran as a
cron-specific account (with certain group memberships). You can have an
account, with group memberships that allow the script to do certain things.

Mixing commands like "rm" in a script, must be done with utmost care.
You haven't lived as root, until one of your commands start erasing
other peoples files :-/ (Yes, I've done that. They gave me a very tiny Tshirt.)

Sending a print job is relatively safe, compared to issuing an "rm",
but a cron job could still create mounds of cruft if poorly crafted.

We came into a computer room one day and the floor was covered to a
depth of three feet, in output device paper :-) That's when you
realize unattended operation is a mistake, when working with yoyos.
Don't be that guy. The paper for the device, is like $200.00 a roll.
It's at times like that, you're glad the rolls are of limited size.

Defensive programming is the name of the game. the hardest part, is
likely getting anything at all to run. Once your thingy is running,
you can move on up to adding content to it. Something other than
touch somefilename

Paul

On Mon, 30 Oct 2023 02:57:19 -0400, Paul <nospam@needed.invalid>
wrote:

>On 10/29/2023 11:00 PM, John B. wrote:
>> On Mon, 30 Oct 2023 09:57:50 +0700, John B. <slocombjb@gmail.com>
>> wrote:
>>
>>>
>>> I had a computer crash after several years and installed Linux Mint
>>> 20.
>>>
>>> Previously I had the system set to run a computer test scene every
>>> third day that the computer was turned on. Using crun (I think).
>>>
>>> However with the /etc/cruntab of the version 20 I'm not having much
>>> luck. Is it possible to schedule a printer test on every 3rd day the
>>> computer is turned on with the newer crontab and if so can someone
>>> post the actual coding necessary to do it?
>>
>>
>> Sorry for the misspelling - it is actually "cron".
>>
>
>You asked about this eighteen years ago ? Plus or minus on the ID.
>
> https://www.linuxquestions.org/questions/linux-software-2/regular-print-job-using-cron-or-something-308167/
>
Nope, wasn't me. "Bigjohn" is, from his post in the U.K. and I'm in
Thailand (:-)

>Some of these articles can have so much advertising, they rail the browser
>and prevented using the scroll bar. There is nothing like the whir of fans
>as a greeting to a web site. The person fitting the advertising to this
>site, deserves a smack (had to kill browser).
>
> https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm
>
>This version of that site, isn't hitting the machine quite as hard.
>You can actually scroll down in here.
>
> https://web.archive.org/web/20230529174744/https://www.fosslinux.com/106902/the-guide-to-mastering-cron-jobs-in-linux-mint.htm
>
>There are actually whole books on using cron, but they're thin books
>and the fan doesn't whir quite as loudly. Cron might be a lightweight
>book like the Termcap book was.
>
>You can see an example here, where someone puts a "gate" in their script,
>to abort the "driving the printer part", if the day spacing is wrong.
>
>https://stackoverflow.com/questions/4549542/cron-job-every-three-days
>
> 0 0 */3 * * # Only approximate, due to month length. The 3 day spacing is not honoured.
>
>You could set the cron to run daily at a particular hour,
>then inside the script, check whether the date is the right value or not.
>Someones first attempt, was this on that web page.
>
>if (((date('j') - 1) % 3))
> exit();
>
>The people in that thread keep working on it.
>
>"If you want it to be every 3 days from a specific date, use the following format:"
>
>0 0 * * * bash -c '(( $(date +\%s -d "2019-01-01") / 86400 \% 3 == 0 )) && runmyjob.sh'
>
>When I work with dangerous materials like that, inside the runmyjob.sh to begin
>with, I might "touch" a file somewhere, which provides evidence of what date and time
>the script ran. And not actually put the print command in there.
>
>This page will give you some ideas as to how to make "evidence" files in your script.
>By making unique filenames, the files will not collide and there should be an
>evidence trail. Now, a guy could foul this up, but this should give you the
>idea. You could do /bin/touch "$now" once you have crafted a format of
>$now with minutes and seconds perhaps.
>
>https://www.cyberciti.biz/faq/unix-linux-appleosx-bsd-shell-appending-date-to-filename/
>
>################################################################################
>
>Any time you do things like this, you want to be aware of the level of
>elevation the thing runs at, and whether something bad could happen in there.
>For example, if your script contents were
>
> /bin/rm -Rf * # Don't do this in a cron job
>
>then you'd want to know exactly what part of the machine that could wipe
>out, based on whether it ran as you or it ran as root or it ran as a
>cron-specific account (with certain group memberships). You can have an
>account, with group memberships that allow the script to do certain things.
>
>Mixing commands like "rm" in a script, must be done with utmost care.
>You haven't lived as root, until one of your commands start erasing
>other peoples files :-/ (Yes, I've done that. They gave me a very tiny Tshirt.)
>
>Sending a print job is relatively safe, compared to issuing an "rm",
>but a cron job could still create mounds of cruft if poorly crafted.
>
>We came into a computer room one day and the floor was covered to a
>depth of three feet, in output device paper :-) That's when you
>realize unattended operation is a mistake, when working with yoyos.
>Don't be that guy. The paper for the device, is like $200.00 a roll.
>It's at times like that, you're glad the rolls are of limited size.
>
>Defensive programming is the name of the game. the hardest part, is
>likely getting anything at all to run. Once your thingy is running,
>you can move on up to adding content to it. Something other than
>touch somefilename
>
> Paul
--
Cheers,

John B.