====== Batocera scripts ====== If you are looking for how scripts behaved in **v37** and below, refer to the [[:launch_a_script_legacy|legacy scripts page]]. You can opt to have scripts launched at various points in Batocera. This will change the location you save the script to and how it opens. ===== Scripts during boot/shutdown ===== When booting and shutting down, Batocera checks for scripts three times at different stages in the boot/shutdown process: * [[#boot-custom: First during startup, last after shutdown|/boot/boot-custom.sh]], a special case if you need scripts executed very early in the boot process * [[#postshare: First after mounting userdata mount, last before userdata gets unmounted|/boot/postshare.sh]], to launch scripts right after userdata is mounted * [[#custom: Last during startup, first after shutdown|/userdata/system/custom.sh]], after EmulationStation has loaded, the preferred method for most use-cases When these scripts are executed, Batocera sends the first argument to the script as ''start'' when Batocera is booting and ''stop'' when Batocera is shutting down. Putting code into cases or other checks for these argument values will cause that code to only be executed when booting or shutting down, otherwise code will be executed on both boot and shutdown. ==== boot-custom: First during startup, last after shutdown ==== In Batocera **v32** and higher, scripts can be launched early in the boot process, before much of Batocera has even begun loading. This is done by storing the script in the boot partition at ''/boot/boot-custom.sh''. Keep in mind that this script will be limited to more basic commands/modules, as most things have not loaded yet. The filename must be ''boot-custom.sh'' otherwise it will not be checked. Precisely, this is the first thing executed once //init.d// has begun. This is before the //network/share// population/IR remote daemon have even loaded so capabilities are limited. Check ''/etc/init.d'' to see the exact order of all the modules have been loaded in (''S00bootcustom'' is when the ''/boot/boot-custom.sh'' is executed). This can be used to effectively patch and/or override the modules loaded by Batocera. Here are some examples that are only possible with this method: * Customize or disable ''S33disablealtfn'' to allow a certain text mode console on a particular TTY session. * Tinker with hwclock to [[:troubleshooting#changing_batocera_to_use_windows_local_time_instead|save local time instead of universal time to RTC]]. * Run ''fsck -a'' or ''e2fsck -p'' to harden the file system against data corruption in the case of a power cut/disconnection. ==== postshare: First after mounting userdata mount, last before userdata gets unmounted ==== In Batocera **v35** and higher, scripts can also be launched after ''/userdata'' is mounted in the boot process, before the splash video plays (and before Emulationstation has begun loading). It has to be placed to ''/boot/postshare.sh'' and is executed directly by the bash interpreter (no executable flag required). This is the only init.d scripts that doesn't execute in background. So if you use a sleep timer for example, the script will halt till the time from sleep command is up! Be aware of endless do-while loops! Get familiar with shell commands and the usage of the ampersand m( **&** ==== custom: Last during startup, first after shutdown ==== While [[#custom.sh (deprecated)|custom.sh]] still works in **v40**, it's deprecated since **v38** and and may be removed in a later version. (See [[https://batocera.org/changelog|changelog]].) The recommended way to do custom scripting in Batocera now is the [[#services|services]] method detailed below. === custom.sh (deprecated) === Sometimes you just want to fire up one script after successfully booting, for example when you want [[:vpn_client|to start up a VPN]] or other after-boot tasks. In order to do this, create a script text file at ''/userdata/system/custom.sh''. Be aware that the script will be executed independently of the executable (''x'') attribute being set to the script file or not! This script is the very last one that will be invoked by Batocera at boot time after EmulationStation has launched (check ''/etc/init.d/'' to see all the modules that are loaded before then, ''S99userservices'' (previously ''S99custom'' in Batocera **v38** and below) is when the user script is launched). The filename must be ''custom.sh'' otherwise it will not be checked. Make sure your script ends with Unix line terminators (LF), not Windows-style line terminators (CR/LF) otherwise the script will not launch. Use a real text editor to edit your scripts, especially if you edit them under Windows. == A simple custom script as an example == #!/bin/bash # Code here will be executed on every boot and shutdown. # Check if security is enabled and store that setting to a variable. securityenabled="$(/usr/bin/batocera-settings-get system.security.enabled)" case "$1" in start) # Code in here will only be executed on boot. enabled="$(/usr/bin/batocera-settings-get system.samba.enabled)" if [ "$enabled" = "0" ]; then echo "SMB services: disabled" exit 0 fi ;; stop) # Code in here will only be executed on shutdown. echo -n "Shutting down SMB services: " kill -9 `pidof smbd` RETVAL=$? rm -f /var/run/samba/smbd.pid echo "done" ;; restart|reload) # Code in here will executed (when?). echo "SMB services: reloaded" ;; *) # Code in here will be executed in all other conditions. echo "Usage: $0 {start|stop|restart}" ;; esac exit $? === services === You should replace ''/userdata/system/custom.sh'' with ''/userdata/system/services/myservice''. Important notes: * Make sure that the filename is without the ''.sh'' extension. * To debug your services, use: ''bash -x batocera-services list'' Additional benefits of this system over ''custom.sh'': * You can now have more than one service running. * You can enable and disable them individually, from the command line (''batocera-services'') or through the UI in EmulationStation (System settings -> Services). **Disabling** services (with ''batocera-services disable'') doesn't **stop** them. That needs to be done manually with ''batocera-services stop''. Disabling them only means that they wil not be automatically started after the next system startup. **Enabling** them (with ''batocera-services enable'') works the same. To actually **start** a service, enable it first, then restart Batocera or use ''batocera-services start''. Enabling or disabling the service in the EmulationStation user interface will also start or stop the service immediately. == Sample service == #!/bin/bash case "$1" in start) echo "I've started." ;; stop) echo "I've stopped." ;; status) echo "This is my status." ;; esac ===== Watch for a game start/stop event ===== Batocera **5.23** and higher supports running a script right before a game launches and/or after a game is exited. Here are some examples: * Automatic controller setup * Automatic scraping for new games * Change screen resolution (though it might be better to use switchres for this) * Sync savestates to an external/network device * ... give me your idea here Place an executable script (can have any filename) with the correct [[https://en.wikipedia.org/wiki/Shebang_(Unix)|setted shebang]] (first line!) or an executable binary into directory ''/userdata/system/scripts/''. Game start/stop event scripts must be marked as executable with the ''chmod +x'' command. For example: # Open up a text editor to create your script: nano /userdata/system/scripts/first_script.sh # Write in your script, save and exit. # Then to add the executable bit to it: chmod +x /userdata/system/scripts/first_script.sh This means that if your userdata partition is of the NTFS, exFAT or older file system that are missing the executable bit functionality, it will fail to execute. You can add as many subfolders as you want, every script placed there will be executed. To distinguish between **START** or **STOP** condition the first argument parsed in the script have either of these flags: * ''gameStart'' is passed to your scripts if you select a game from EmulationStation (Game Starts!) * ''gameStop'' is passed to your scripts if you are going back from a game to EmulationStation (Game Stops!) **If you do not set cases for first argument, then the script is executed on every start and on every end of a game.** ==== What is parsed ==== Table of parsed arguments in correct order and their functions: ^ Arg no. ^ Parsed Parameter ^ Usage ^ | 1 | ''gameStart'' or ''gameStop'' | To distinguish between START or STOP condition | | 2 | ''systemName'' | The system shortname as is in ''es_system.cfg'', eg. **atari2600** | | 3 | ''system.config['emulator']'' | The emulator settings, eg. **libretro** | | 4 | ''system.config['core']'' | The emulator core you have chosen, eg. **stella** | | 5 | ''args.rom'' | The full rom path, eg. **/userdata/roms/atari2600/Mysterious Thief, A (USA).zip** | ==== Simple game start/stop script as an example ==== At first create the directory where the scripts need to be set up. [[:access_the_batocera_via_ssh|Connect through SSH]] and type ''mkdir /userdata/system/scripts''. After this we can set up our first script by typing ''nano /userdata/system/scripts/first_script.sh''. The filename can be anything readable by bash. Here's the template script: #!/bin/bash # This is an example file of how gameStart and gameStop events can be used. # It's good practice to set all constants before anything else. logfile=/tmp/scriptlog.txt # Case selection for first parameter parsed, our event. case $1 in gameStart) # Commands in here will be executed on the start of any game. echo "START" > $logfile echo "$@" >> $logfile ;; gameStop) # Commands here will be executed on the stop of every game. echo "END" >> $logfile ;; esac Now you can see a log file created ''/tmp/scriptlog.txt'', that parsed all arguments in this file. This is just a small test of course. You can check out [[:access_the_batocera_via_ssh|the SSH page]] and [[:usage_of_batocera-settings|the usage of batocera-settings]] page for general and Batocera-specific commands. ===== EmulationStation scripting ===== In case Batocera's provided scripting functionality is not sufficient, ES itself also triggers scripts of its own volition. Extra scripts can be created at ''/userdata/system/configs/emulationstation/scripts//