# What is now the preferred way to execute a notebook on startup?

This question was previously answered in part in earlier post through the use of the command AutoOpenNotebooks. However, as of 10.0 this command is scheduled for potential change or deprecation and this global preference option no longer appears in the global preferences (or at least not at its former location under "File Locations").

What is now the preferred way to do this as of 10.0 so notebooks written to execute on startup do not become broken in the future?

The primary reason for asking is that I would like to execute scheduled tasks that run once every week, once every month, or once every quarter, intervals far too long to expect my PC to be running continuously as a ScheduledTaks[] and I don't want to find out about any deprecation of AutoOpenNOtebooks after the fact should it occur since some data being imported is only transient on various websites and thus would be lost to my application.

I presume one option would be to run these in the Cloud, but I am not yet ready for Cloud computing and prefer to wait a year or so before trying it and thus, am seeking other potential approaches.

Suggestions as to how others are approaching this problem would be appreciated.

• Lethal injection? – Daniel Lichtblau Jan 14 '16 at 21:59
• @Daniel The fluorescent lights are doing strange things to you again. ;-) – Mr.Wizard Jan 14 '16 at 22:16
• @Mr.Wizard They've added UV. Not so bad by day, but I sort of glow in the dark. – Daniel Lichtblau Jan 14 '16 at 22:19

You can put your instructions in a package file (init.m) in the directory interpreted by ToFileName[{$BaseDirectory, "Kernel"}] or ToFileName[{$BaseDirectory, "Kernel", "Autoload"}].

The contents can consist of as little as a Get call to another notebook package.

The use of init.m files is long-established functionality and not likely to change.

• Is it possible to avoid creating .m versions of notebooks that are in active development? Currently I open notebook in front end and execute everything in it. – alancalvitti Jan 5 '16 at 20:12
• Try putting something like this in your init file: UsingFrontEnd[ nb = NotebookOpen["c:\\users\\arnoudb\\run.nb"]; SelectionMove[nb,All,Notebook]; SelectionEvaluate[nb]; NotebookPauseForEvaluation[nb]; ] - ref. link – Chris Degnen Jan 5 '16 at 21:57
• Is there a way that avoids .init? I use M on multiple computers and with constant upgrades and scoping confusions I could never rely on init. – alancalvitti Jan 6 '16 at 17:10

For very long running tasks, running locally on my machine (so not cloud scheduled tasks) I use the Windows task scheduler (on Mac and Linux, cron would be the equivalent I believe). This works well for tasks I want to run over extended periods of time (weeks, months, years) and keep working after reboots, power downs, minor system upgrades, etc. By using the Windows task scheduler I also do not permanently tie up a Wolfram Language license and Wolfram Language process on my machine.

The Windows task scheduler has a GUI, but I prefer to use the command line interface. A sample way to set up a scheduled task is (executed from a file called tasks.bat):

@echo off
schtasks /create /tn %tn% /tr %tr% /sc hourly /st 00:00:00
schtasks /query  /tn %tn% /v /fo list


Running this tasks.bat file deletes the old instance of the task (if it exists), creates a new instance, and shows the task information on the CMD window.

The task that gets run here is wolfram.vbs which is just a visual basic wrapper to call another .bat script:

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run Chr(34) & "D:\windowsscheduledtasks\wolfram.bat" & Chr(34), 0
Set WshShell = Nothing


(This .vbs wrapper script was necessary to solve this problem).

Now the content of wolfram.bat is just calling the Wolfram kernel with the -script option:

"C:\Program Files\Wolfram Research\Mathematica\10.3\wolfram.exe" \

And then finally the wolfram.wl file contains the Wolfram Language code that I need to run on a regular basis.