LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   ARRGGG! Frikkin Crontab >:- (( (https://www.linuxquestions.org/questions/linux-newbie-8/arrggg-frikkin-crontab-633672/)

hashbangbinbash 04-07-2008 09:21 AM

ARRGGG! Frikkin Crontab >:- ((
 
I'm trying to have crontab open a file on my desktop, so I did "crontab -e" and wrote in this line

Code:

15 15 * * * hashbang kwrite /home/hashbang/file.txt
I made sure file.txt is chmodded to 755, I've been setting a few minutes slater each time to test and it continues to lamentably fail. As of writing this it's 15:18, my attempt quoted above was for 15:15. From what I could google, the spaces between the integers are spaces not tabs, although I've tried with tabs as well.

can anyone suggest anything please?

3rods 04-07-2008 09:27 AM

Quote:

Originally Posted by hashbangbinbash (Post 3113525)
I'm trying to have crontab open a file on my desktop, so I did "crontab -e" and wrote in this line

Code:

15 15 * * * hashbang kwrite /home/hashbang/file.txt
I made sure file.txt is chmodded to 755, I've been setting a few minutes slater each time to test and it continues to lamentably fail. As of writing this it's 15:18, my attempt quoted above was for 15:15. From what I could google, the spaces between the integers are spaces not tabs, although I've tried with tabs as well.

can anyone suggest anything please?

Just a stab in the dark, but when you type "hashbang kwrite /home/hashbang/file.txt" on the command line, does it do anything?

I don't know what hashbang is, but don't you want to "hashbang >> /home/hashbang/file.txt"?? Append output from hashbang to file.txt??

hashbangbinbash 04-07-2008 09:37 AM

yeah, I tested the command first..

version 1: "/home/hashbang/file.txt" didn't work

version 2: "kwrite /home/hashbang/file.txt" did work

then looking at an example I fiound in google I came up with version 3: "hashbang /home/hashbang/file.txt" which also failed to work. That's when I came here, but thinking about it... probably best to go back to version 2, it didn't work from crontab but at least I know it works on the command line. By the way, there are no error messages produced... this is a Debian system I'm using, but I can't find any kind of error log for crontab.

3rods 04-07-2008 09:43 AM

What are you trying to do? I don't know what hashbang is (other than "#!" - hash bang), so I'm kind of lost.

If you're just trying to pipe output from stdout to a file, why not use ">"?

Like: ls -l > file.txt

Touch file.txt or use vim to create it first.

hashbangbinbash 04-07-2008 09:50 AM

hashbang as in me the user (hashbangbinbash, it amused me to call myself that on here, also makes for an effective method of reminding myself how to start a bash script). I was following the format described in some guide I found. So in other words

Code:

15 15 * * * user kwrite /home/user/file.txt
I only want the file to open on my desktop as a kind of reminder. Once I get the above example working, I'll know I can have the file open every monday at 9:30, then add another that emails the file every monday at lunchtime. Babysteps first though.

colucix 04-07-2008 10:06 AM

Take in mind that crontab jobs have a very limited environment, that is a limited PATH and no information about your current shell environment. You're trying to launch an application which uses a graphical user interface, but crontab does not know where to open it (on which screen). You have to explicitly specify the DISPLAY as in
Code:

15 15 * * * env DISPLAY=:0.0 /usr/bin/kwrite $HOME/file.txt > $HOME/cron.log 2>&1
The first part of this command "env DISPLAY=:0.0" set the current display to be used from the subsequent command. Check if your display is set to :0.0 by simply
Code:

echo $DISPLAY
if not, modify it accordingly. Also note that I used the full path for the command "/usr/bin/kwrite". Finally, at the end I added redirection of both standard output and standard error to a file in your home directory "$HOME/cron.log". This is useful for debugging purposes.

If you don't explicitly redirect standard output and/or standard error to a file, any message generated by the cron job will be delivered to the user by mail. Maybe you already have got mails with error messages. You can check with the command
Code:

mail
Also note that the username in the crontab is not really necessary if the crontab belongs to the user himself.

3rods 04-07-2008 10:07 AM

Ah, ok.

I don't think the user is required. If it is, it's in the wrong place. It would be after the kwrite. For instance, in Gnome to launch gedit, I could use "gedit %U" and that would launch gedit for my current user. It should be the same for kwrite, just drag the icon to the top taskbar and click on it's properties to see the command line args use to launch it.

If this worked:
version 2: "kwrite /home/hashbang/file.txt"

I would just stick with that, unless you're having an issue with passing the user value.
If so, change it to "kwrite %U /home/hashbang/file.txt" and see if it works.

matthewg42 04-07-2008 10:07 AM

cron runs jobs in the background. It runs all the time, and cannot be sure that any user will be logged in at a given moment. cron is often used on machines which don't even have a graphical display.

kwrite is a KDE application and can only run when there is a user logged in to an X session.

There is a way to accomplish what you want to do using cron, but it is not the proper approach. It is not the intended purpose of cron to be launching X applications. cron is intended for background processes.

If you want to use kwrite, I guess you are using KDE. KDE has it's own scheduling applications which can be used to run KDE apps like kwrite. I would recommend using kalarm for this purpose. It sits in the systray and can be set up to pop up reminders, or run commands like kwrite.

colucix 04-07-2008 10:11 AM

Quote:

Originally Posted by matthewg42 (Post 3113566)
There is a way to accomplish what you want to do using cron, but it is not the proper approach. It is not the intended purpose of cron to be launching X applications. cron is intended for background processes.

I agree... I should have mentioned that. Thanks, matthew.

hashbangbinbash 04-07-2008 10:16 AM

Thanks guys for the variety of answers, even if crontab is not best suitable for this purpose it's still good to learn about the limits and how to overcome them. Might look for kalarm, but as a point of principal and education I think I shall ram this through with crontab. Teach linux who's boss.

3rods 04-07-2008 10:20 AM

Well then. Shows how much I know... :cry:

hashbangbinbash 04-07-2008 10:22 AM

It worked! w00t! Thanks again. :)

hashbangbinbash 04-14-2008 11:28 AM

A quik question about describing a time with crontab

Code:

* 9 1 * 1 /home/hashbang/my_script.sh
Does this mean my_script will run at 9 o'clock on the first monday of the month or will my_script be run only when the first day of a month is a monday?

Is it possible to describe the 1st Monday of every month in crontab terms?

forrestt 04-14-2008 11:47 AM

No, it means your script will run every Monday AND the first of each month (whether Monday or not). The day fields in cron are backwards in that every other field is combined with AND, but those two are combined with OR. The above translates to:

if ((the minute is any) && (the hour is 9) && (the month is any) && ((the day of month is 1) || (the day of week is 1))) run the command.

HTH

Forrest

hashbangbinbash 04-14-2008 11:55 AM

It does help thanks, it seems to confirm that there is indeed no way of describing the first monday of any month in crontab.

forrestt 04-14-2008 12:05 PM

You are correct. I don't know who decided that those to fields should be combined with an OR, but I'd like to slap them with a herring. If they were combined with an AND what you are wanting would be trivial, and to get an OR would only require two entries (one for the DOM and one for the DOW). The way it was configured results in an impossible situation where a certain numbered weekday (first Tuesday, third Friay, etc.) cannot be described in cron. What you must do is call the script every Monday (for example) and then inside the script determine if the DOM is in the right date range (for example 1-7 for the first or 8-14 for the second week).

HTH

Forrest

matthewg42 04-14-2008 01:54 PM

I think you're right. However, you could get your script to run each Monday using the cron line like this:
Code:

0 9 * * 1 /home/hashbang/my_script.sh
Then you can have this at the start of your script to quit immediately if the day of the month is greater than 7. The effect being that the script will only do what you want it to do on the first Monday of each month:

Code:

#!/bin/bash
[ $(date +%d |sed 's/^0//') -le 7 ] || exit 0

# the rest of your code here

One dis-advantage of this approach (apart from it being a bit ugly) is that the script will not work when invoked manually after the 7th of the month. You can get around this by setting an environment variable in the crontab, and then testing for it when doing the "in the first week" check in the script. Here's how to do the crontab part:
Code:

0 9 * * 1 RUNFROMCRON=yes /home/hashbang/my_script.sh
And the script might look like this:
Code:

#!/bin/bash
if [ "$RUNFROMCRON" = "yes" ]; then
    [ $(date +%d |sed 's/^0//') -le 7 ] || exit 0
fi

# the rest of your code here


colucix 04-14-2008 03:21 PM

Quote:

Originally Posted by matthewg42 (Post 3121088)
One dis-advantage of this approach (apart from it being a bit ugly) is that the script will not work when invoked manually after the 7th of the month.

There are other ways to check if a script is invoked from a terminal or from crontab: for example you can simply check if the standard input is associated with a terminal (script invoked from a terminal) or not (script invoked from crontab)
Code:

tty -s || exit
or
Code:

test -t 0 || exit

matthewg42 04-14-2008 04:10 PM

Quote:

Originally Posted by colucix (Post 3121164)
There are other ways to check if a script is invoked from a terminal or from crontab: for example you can simply check if the standard input is associated with a terminal (script invoked from a terminal) or not (script invoked from crontab)
Code:

tty -s || exit
or
Code:

test -t 0 || exit

...although this might be the case for other reasons, like running with nohup or xargs.

hashbangbinbash 04-15-2008 10:32 AM

Thanks for the responses here, I didn't see them before I settled on this...

Code:

* * * * 1 /home/hasbang/my_script.sh
and my_script.sh being...

Code:

#!/bin/bash
n=$( date +%d );
if [ $n -le 7 ]; then
echo "do the thing";
fi

It is pretty amazing the flexibility of bash, various ways of solving the one problem... really shows up why it's best to learn command line and not just settle for a nice gui.

fatra2 04-15-2008 11:03 AM

Hi there,

Just to add to this discussion.

If you are like me, hashbangbinbash, and can never remember the rules of crontab. I write my cron file, then let "kcron" tell me about the set of rules I applied. Since you are using KDE, you should have access to "kcron" which will give you many details of the cron jobs you have registered.

Cheers


All times are GMT -5. The time now is 10:14 PM.