I've been troubleshooting this for sometime now. I'm getting some quite unexpected behaviour. I've place a job in /etc/crontab to be run bihourly. It's an R script that produces a png graphic displayed on my server's webpage. It's called in the form:
0,30 * * * * my_user Rscript /path/to/file
What's odd is that it works for an hour or so before the graphic stops updating. If I ssh into the machine and then edit /etc/crontab without even changing anything, it'll start running again. Anyone know what might cause such an issue?
EDIT: I messed around with it a bit more, and it's getting even weirder. I'm running a PHP file from cron that scrapes some text and writes it to file. The PHP continues to work even when R has ceased to run.
If you want something to run once every two hours, you will have to use the slash, "/", character in your field. The slash character is the "step" character. In the case of a two hourly schedule, your time component of your cron file will read:
0 */2 * * *
The second field, "*/2", means every alternate hour.
Similarly, if you want something to run every 3 hours, you can change that field to "*/3", and so on.
bihourly: Occurring once every two hours.
Related
Recently, when I load iTerm2 on my mac, it lists out the configuration of my profile (or possibly its something different).
This is what I see:
Last login: Tue Jun 21 19:54:38 on ttys000COLORFGBG='15;0'
COLORTERM=truecolor
COMMAND_MODE=unix2003
HOME=/Users/me
ITERM_PROFILE=Default
ITERM_SESSION_ID=w0t0p0:FD9764B1-4535-4FE2-932A-97AFD9D6C804
LANG=en_GB.UTF-8
LC_TERMINAL=iTerm2
LC_TERMINAL_VERSION=3.4.15
LOGNAME=me
OLDPWD=/Users/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
PWD=/Users/me
SHELL=/bin/zsh
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.u21pRFo1wk/Listeners
TERM=xterm
TERM_PROGRAM=iTerm.app
TERM_PROGRAM_VERSION=3.4.15
TERM_SESSION_ID=w0t0p0:FD9764B1-4535-4FE2-932A-97AFD9D6C804
TMPDIR=/var/folders/dz/wvb1lxq56wg_wk3ppwqw4mdc0000gn/T/
USER=me
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
__CFBundleIdentifier=com.googlecode.iterm2
__CF_USER_TEXT_ENCODING=0x0:0:0
me#my-iMac ~ %
I don't really like this behaviour. I can't find where that has been set to happen. I can't see anything in .zshenv, .zshrc, .bashrc and can't see where in iTerm such a thing might be triggered. I've tried creating a new profile, but that also results in the same output.
Any other suggestions to how I can get back to the way it was a few weeks back where it just told me the last time I logged in?
If you add set -x to ~/.zshenv, the shell will print every line it runs with file names and line numbers. You can then find the offending command and remove or fix it. My best guess would be a call to export without any arguments: something like export $foo, where $foo is empty?
Occasionally, for reasons I can not determine, ess-indent-or-complete sends an input to the R console. In other words, I will be typing something, hit tab to autocomplete (or company autocompletes for me), and the R process will update with a newline (.R file on the left "buffer", R process on the right):
x <- mea█ | >
|
|
... and then I hit tab to complete "mean":
x <- mean█ | >
| > ## note the new line here
|
This can be really annoying for at least two reasons:
It fills up the process buffer with blank lines.
If I am using a browser(), it advances lines which is often undesirable.
I have tried to diagnose this myself to no avail. Restarting emacs fixes it every time, however it seems to start happening at random throughout the day. Once it starts it does not stop until emacs restarts.
I am running emacs 27.1, ess-20210818.843 (though this has been a thing for a long time, so I don't believe it is version-specific), and am in ESS[R] mode.
Calling M-: (ess-command "") from my .R file buffer replicates the undesired behavior once it starts happening in a particular session. I have no insight beyond this.
I think you solved it yourself, with your GH issue suggestion:
https://github.com/emacs-ess/ESS/issues/1198
I've changed things in my own version of ESS, and will commit after a few days of testing it.
Thank you VERY VERY much for persevering and (I think) finding the fault .. a simple typo inside the internal (ess--command-make-restore-function)
I'm trying to loop through the contents of a file in zsh. In my loop I want to get user input. Going off of this answer for Bash, I'm attempting to do:
while read -u 10 line; do
echo $line;
# TODO read from stdin here, etc.
done 10<myfile.txt
However I get an error:
zsh: parse error near `10'
Referring to the 10 after the done. Obviously I'm not getting the file descriptor syntax right, but I'm having trouble figuring out the docs.
Use a file descriptor number less than 10. If you want to hard code file descriptor numbers, stick to the range 3-9 (plus 0-2 for stdin,out,err). When zsh needs file descriptors itself, it uses them in the 10+ range.
If you're even getting close to needing more than the 7 available hard coded file descriptors, you should really think about using variables to name them. Syntax like exec {myfd}<myfile.txt will open a file with zsh allocating a file descriptor greater than 10 and assigning it to $myfd.
Bourne shell syntax is not entirely unambiguous given file descriptors numbering 10 and over and even in bash, I'd advise against using them. I'm not entirely sure how bash avoids conflicts if it needs to open any for internal use - I guess it never needs to leave any open. This may look like a zsh limitation at first sight but is actually a sensible feature.
A semi-newbie to UNIX piping, so apologies if I'm asking anything obvious here. I'm using a program called CCExtractor to grab the closed captions from a video file. It has the option to receive a file from stdin, and it works great if I do the following:
./ccextractor -stdin < myvideofile.wtv
However, I want to try using it "live" - as a video is recording, it'll transcribe the subtitles. From my understanding, < won't do that, as it'll stop as soon as it reaches the current end of the file. Following this answer on Stack Overflow, it seems like:
tail -c +1 -f myvideofile.wtv | ./ccextractor -stdin
should work - but it doesn't process any part of the video at all (it should, at least, work as well as the previous command and parse the existing data). I figured I'd take a step back and use a simple cat:
cat myvideofile.wtv | ./ccextractor -stdin
and that doesn't work either. I was of the belief that the first and third commands ought to be roughly equivalent, but that's obviously not the case. What are the differences, and how could I get this to work?
I'm new to zsh and am using the ZSH_THEME="jnrowe", which works great for a little while.
It starts out and I get a prompt that looks like this:
Ξ ~ →
but if I run a command like: ssh it becomes:
↑255 ~ →
I suspect something is messing up the character that was creating the triple bar in the first one, but have no clue really as to what's going on. I could just pick a different theme, but I've noticed most of them with a fancy character in the prompt do the same thing.
Is this a special error code or something? Or is something just borking out?
I don't know the prompt theme "jnrowe" (it's not part of the default zsh distribution afaics), but I suspect this prompt includes the error code of the last command in its output.
Try to run "ls" or "true" and the number will disapper. Run "false" and it will be 1, run ssh without arguments and it will be 255. zsh preserves this value until you run the next command, so pressing ENTER many times will not clear it.
(This will be the same value that is stored in the shell variable "$?")