More script-dev questions. How to log errors in external scripts?
-
My background music setup calls an external bash script to control playback volume from the menu with a
gui_
function in the module. How can I log errors reported by this external script? When I justecho
them they come up on the screen over the GUI. I tried directing them to STDERR with1>&2
but that gave the same result:Is there a way to log these errors quietly? Right now I have them redirected to
>/dev/null
just to keep the code in without polluting the screen but I imagine that's pretty pointless in the big picture.I suppose I could just redirect them to a file somewhere. Is there one already I should use somewhere? Or, a better way to do this (quietly log errors reported by external scripts called from a module's
gui_
function)? -
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I tried directing them to STDERR with 1>&2 but that gave the same result:
Did you redirect STDERR (2) also ?
-
@mitu said in More script-dev questions. How to log errors in external scripts?:
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I tried directing them to STDERR with 1>&2 but that gave the same result:
Did you redirect STDERR (2) also ?
I was trying to redirect the actual
echo
command inside the external script. I've just now realized maybe I should be redirecting the script itself when it's called from thegui_
function? If I do:su $user -c "$md_inst/script.sh >&2 &"
...would that work?
Come to think of it, I'm not exactly sure where I do expect to see these messages. Is this stuff even logged anywhere (if I don't do it myself)? I'm not seeing it in
es_log.txt
nor inRetroPie-Setup/logs
. Maybe I don't need to echo anything at all... -
Error messages are not logged anywhere by default. RetroPie-Setup has
runCmd
(inhelpers.sh
) to capture STDERR and check the exit code for errors.Btw, I wouldn't use the
_gui
function for regular operation process (Play/Next), they should have a separate UI that doesn't involve calling RetroPie-Setup. -
@mitu said in More script-dev questions. How to log errors in external scripts?:
Btw, I wouldn't use the
_gui
function for regular operation process (Play/Next), they should have a separate UI that doesn't involve calling RetroPie-Setup.So I'd place a
.sh
script in the retropiemenu dir instead of the empty.rp
file. And then in this.sh
should essentially be the same GUI I have now, but by itself? Does this inherit vars and functions like$configdir
andprintMsgs
or would I need to hard-code those? Is$configdir
always just a shortcut to/opt/retropie/configs
or is it possible to be somewhere else and how might I account for that? -
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
Does this inherit vars and functions like $configdir and printMsgs or would I need to hard-code those?
No.
Is $configdir always just a shortcut to /opt/retropie/configs or is it possible to be somewhere else and how might I account for that?
Right now it's always
/opt/retropie/configs
, but the reason it's a variable accounts for a future update where it can change. -
@mitu I also need to reference
$datadir
which I believe could be anywhere. I suppose I could write the script file with the module at time of install (as inecho > "$file" < _EOF_
), or perhaps just write a user-config this way that's loaded by the script, with those values coded in to it. -
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I also need to reference $datadir which I believe could be anywhere.
I think
$datadir
is only setretropie_packages.sh
and it's used directly only by a few scripts to look for the install dir ($HOME/RetroPie
).$biosdir
and$romdir
depend on it and they're more often used by packages.There are a few emulator start scripts which use
$datadir
(and they don't sourceretropie_packages.sh
) and they assume that$datadir
is always$HOME/RetroPie
. -
@mitu said in More script-dev questions. How to log errors in external scripts?:
and they assume that
$datadir
is always$HOME/RetroPie
.Oh you know what, I was thinking of how the setup dir can be anywhere you clone it. But yeah I do see
$datadir
is always in$home
, and how that is set by$(eval echo ~$user)
. That last bit I don't actually understand, but it does seem to work. I guess~foo
is just the home dir of user foo, but why theeval
?So I can safely write both
/opt/retropie/configs/all
and$HOME/RetroPie
into my script and they should still always work (for now).Or if I wanted to be extra-super-future-proof, I can use the install module to write a config that defines the vars and then
source
that config in the script, yeah?And then, if I do incorporate a config, it could open up all sorts of new stuff like alternate playlists, modes, etc.
But I'm getting ahead of myself. I still need to make the script work.
Can I essentially just "lift" the
gui_
function from my module, fix up the vars and helper functions, and dump it in a script in the retropiemenu dir? That's what I've done here, but it's not detecting "enabled":[Edit: nevermind, I see the typo now that I've posted it in public view :-/ . It's working now :) ]
#!/bin/bash # Menu GUI for bgm123 background music in RetroPie. rootdir="/opt/retropie" confirdir="$rootdir/configs" user="$USER" datadir="$HOME/RetroPie" __backtitle="retropie.org.uk - RetroPie Setup. Installation folder: $rootdir for user $user" scriptdir="$HOME/RetroPie-Setup" md_inst="$rootdir/supplementary/bgm123" function playPause() { if pgrep mpg123 >/dev/null; then "$md_inst/bgm_vol_fade.sh" & else ((vcgencmd force_audio hdmi 1) >/dev/null; sleep 1; mpg123 -Z "$datadir/bgm/"*.[mM][pP]3 >/dev/null 2>&1) & fi } function nextTrack() { pkill mpg123 ((vcgencmd force_audio hdmi 1) >/dev/null; sleep 1; mpg123 -Z "$datadir/bgm/"*.[mM][pP]3 >/dev/null 2>&1) & } function showMenu() { local cmd=(dialog --backtitle "$__backtitle" --cancel-label "Back" --menu "Configuration menu for bgm123. Please choose an option." 22 86 16) while true; do local enabled=0 grep '#bgm123' "$configdir/all/autostart.sh" >/dev/null && enabled=1 local options=() if [[ "$enabled" -eq 1 ]]; then options+=( E "Enable or disable background music (currently: Enabled)" ) if pgrep emulationstatio >/dev/null; then options+=( P "Play / pause" N "Next track" ) fi else options+=( E "Enable or disable background music (currently: Disabled)" ) fi local choice=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty) if [[ -n "$choice" ]]; then case "$choice" in E) if [[ "$enabled" -eq 1 ]]; then sudo "$scriptdir/retropie_packages.sh" bgm123 disable dialog --backtitle "$__backtitle" --cr-wrap --no-collapse --msgbox "Background music disabled." 20 60 >/dev/tty else sudo "$scriptdir/retropie_packages.sh" bgm123 enable dialog --backtitle "$__backtitle" --cr-wrap --no-collapse --msgbox "Background music enabled." 20 60 >/dev/tty fi ;; P) playPause ;; N) nextTrack ;; esac else break fi done } showMenu
When I launch this from the RetroPie system menu in ES or from command-line, it always shows as "Disabled," even when it's not. It will properly enable if it wasn't already, when that option (the only one it shows) is selected, but it still doesn't detect that it actually is, and just gives the option to enable it again instead of showing playback controls and offering to disable.
It works fine when it's in the GUI function: https://github.com/s1eve-mcdichae1/RetroPie-Extra/blob/bgm123/scriptmodules/supplementary/bgm123.sh
Is there something I overlooked, or am I taking a wrong approach?
-
@mitu said in More script-dev questions. How to log errors in external scripts?:
Btw, I wouldn't use the
_gui
function for regular operation process (Play/Next), they should have a separate UI that doesn't involve calling RetroPie-Setup.Is this about like what you had in mind, or am I way off base?
https://github.com/s1eve-mcdichae1/RetroPie-Extra/blob/bgm123/scriptmodules/supplementary/bgm123.sh
If I'm on the right track, could you explain a little more your reasons for suggesting this?
After doing some weird stuff with sudo so that it doesn't ask me for a password when skipping tracks or enable/disabling the music...
...because I have to bash the menu script which runs it as root, because
su "$user" -c "bash $md_inst/$md_id.sh"
broke it......and doing it without the
sudo su sudo
made it write "/root/bgm" in theautostart.sh
instead of "/home/pi/bgm"......after I got all that worked out, the only difference I can see is that now it takes five or six "Mississippi's" to execute the enable/disable option in the GUI whereas in the old version it was near instant.
Loading the "background music" item from the gamelist menu seems to take about the same time either way, whether it's the
.rp
or the.sh
.And sometimes the track doesn't start up the first time you hit "play" after re-enabling it. Or, I think it might start "stopped" and be fading in when I hit it the second time? It was hard to tell I'll need to turn the volume up and maybe set a slower fade to test that later.
-
@sleve_mcdichael I suppose I could duplicate the enable function in both places. I do want it available from both interfaces but the playback controls don't need to be in RPSetup.
The delay, I'm sure, is from how long it takes to load retropie_packages.sh when I call it for enable. So if I don't do that, and just write enable/disable functions into the script, it should be fast again (?). And then RPSetup doesn't need playback controls so there's no need to call the script in its gui_, I can just have a simpler dialog that only calls the enable/disable functions that are already in the module functions.
-
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
Is this about like what you had in mind, or am I way off base?
I've taken a look at it and it a bit more complex than it can be:
- enable/disable can be moved to the
_gui
function and you don't need to have separate functions for your global variables. - use
moveConfigFile
to copy the configuration files, this preserves the user configuration and sets the correct permissions on the file. Don't overwrite existing config files. - use
configure_
to install/remove the configuration, notinstall_
,install_
should be used mainly for providing the installed files. - don't re-enable the script on each
configure
, if the user disables the script, it will be re-enabled on an update.
- enable/disable can be moved to the
-
@mitu said in More script-dev questions. How to log errors in external scripts?:
- enable/disable can be moved to the
_gui
function
I wanted to have these available from the RPMenu item, without having to wade through RPSetup > configuration/tools to get there.
I, also, do want them available in RPSetup, though, if that's where we happen to be at, but I don't want to have to go in there as the only way to do it.
Play controls don't need to be in RPSetup, but they also don't need to not be in there, either, I think.
Was your initial suggestion, about using a separate menu script for play/pause, to mean "don't have playback controls in the GUI function," or "don't call the GUI function for RPMenu"? In either case, can you explain why? I have resolved the delay on enable/disable and also no longer need the
sudo su sudo
parts, by completely divorcing the GUI_ function and RPMenu items and just writing everything twice, but I'm still not sure what the benefit of it all is, and I'm about ready to just say "hang it" and go back to using the one GUI for everything, unless there's good reason not to.and you don't need to have separate functions for your global variables.
I'm not sure what you mean here, could you give an example? As I understand it, I can't just put:
function _global_vars_bgm123() { local autostart="$configdir/all/autostart.sh" local bashrc="$home/.bashrc" (etc.) }
...because the "local" values won't propagate to the parent function that calls them, right? Or do I misunderstand the whole point of
local
?Can I just make them global vars, (without
local
, but still inside a function), and then call that function once in every other function that needs them? Or, that's going to pollute the whole "shell space" if I do, and that's why we uselocal
in the first place?- use
moveConfigFile
to copy the configuration files, this preserves the user configuration and sets the correct permissions on the file. Don't overwrite existing config files.
I've already considered/begun to implement this for a different config file I am considering (...or, wait.
moveConfigFile
makes a symlink, just likemoveConfigDir
. Did you meancopyDefaultConfig
which makes the .rp-dist version when the target file already exists? That's the one I meant to use for this other (actual "user config") file I'm considering), that might allow for customized settings in the future. But this config file (you're referring to the$configfile
for the menu script right?) is not a "user config", it only has the variables' definitions in it, and if they have changed since last it was written, they need to be updated/overwritten with current values, or the menu that relies on them won't work.If that's not what you mean, can you explain? I'm not seeing any other files that are problematically overwritten. Fade and menu scripts are copied to the install directory, which has either just been wiped clean if we have installed before, or has just been created anew if not. The menu icon does overwrite, but I wouldn't think that's an issue? The initial backup is skipped if the
$file.old.$md_id
versions exist already, and the immediate backups are meant to be overwritten (only the most-recent is preserved.) What did I miss?- use
configure_
to install/remove the configuration, notinstall_
,install_
should be used mainly for providing the installed files.
Yeah, I could see a lot of this going in configure.
- don't re-enable the script on each
configure
, if the user disables the script, it will be re-enabled on an update.
I've implemented a test so that it's enabled automatically on first install, and only then. I create the user config file with
installed="0"
; then at configure_, it's enabled only if it's still 0, then sets the value to 1 so it won't be re-enabled on future updates. Is that a good way to handle this? I do want it enabled somewhere, automatically after install, so they don't have to do it manually the first time, but if configure is called on updates then you're right, we wouldn't want it to re-enable every time if they have already manually disabled it.Here's where I am at after this morning. It can still be improved, I am sure, but I think everything "works." You can even choose the fade profile by setting "mapped_volume" or not in the config (no GUI option to set it, yet, you still have to edit the file manually at this time) to use either a linear (mapped) scale in 20 steps, or curved (natural) scale with step-size based on current position. Here is the module script:
...and the supplementary files are in:
- enable/disable can be moved to the
-
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I, also, do want them available in RPSetup, though, if that's where we happen to be at, but I don't want to have to go in there as the only way to do it.
The thing is, if you defined your
gui_
function then you have both options working automatically. If you create amodule.rp
file in retropiemenu, RetroPie will call thegui_module
function for that menu entry... I'm not sure what you mean here, could you give an example? ..
I meant that you're only using the "global" vars in your "enable/disable" functions, so if you have just one function for enable/disable then you can do
local globalish_var ... # show a select dialog for enable/disable cmd=(dialog --backtitle "$__backtitle" --cancel-label "Exit" --default-item "$default" --menu "Choose an option." 22 86 16) options=() # add options and show choice local choice=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty) [[ -z "$choice" ]] && break default="$choice" case "$choice" in 1) # run disable code, using $globalish_var ;; 2) # run enable code, using $globalish_var ;;
moveConfigFile makes a symlink, just like moveConfigDir. Did you mean copyDefaultConfig ..
Yes, I meant
copyDefaultConfig
.I've implemented a test so that it's enabled automatically on first install, and only then. I create the user config file with installed="0"; then at configure_, it's enabled only if it's still 0, then sets the value to 1 so it won't be re-enabled on future updates. Is that a good way to handle this? I do want it enabled somewhere, automatically after install, so they don't have to do it manually the first time, but if configure is called on updates then you're right, we wouldn't want it to re-enable every time if they have already manually disabled it.
When you create the default config, it should be created with the enabled settings. Subsequent
configure
will generate the same default config, but don't overwrite the user config file (this is wherecopyDefaultConfig
comes into play). This way, if the user has disabled the functionality, updating will not change their choice. -
@mitu said in More script-dev questions. How to log errors in external scripts?:
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I, also, do want them available in RPSetup, though, if that's where we happen to be at, but I don't want to have to go in there as the only way to do it.
The thing is, if you defined your
gui_
function then you have both options working automatically. If you create amodule.rp
file in retropiemenu, RetroPie will call thegui_module
function for that menu entry.That's what I'd done initially. That's what I thought you were suggesting I change.
@mitu said in More script-dev questions. How to log errors in external scripts?:
Btw, I wouldn't use the
_gui
function for regular operation process (Play/Next), they should have a separate UI that doesn't involve calling RetroPie-Setup.So if I use an
.rp
file in the menu, to call the gui function, but play/pause aren't in the gui function, then where are they, and how do I get there? Do you mean you'd have both an.rp
(to run the gui function with configuration options) and an.sh
with a separate UI for the play controls? I don't really want two separate menu options, though. So how else? An option in the gui function that calls the external playback UI? I don't see a benefit in that either.Sorry for being dense. I'm really not trying to be combative, I'm just struggling to understand what you are actually suggesting, and why.
.. I'm not sure what you mean here, could you give an example? ..
I meant that you're only using the "global" vars in your "enable/disable" functions,
Well, they're also in configure (or install or wherever we end up making that first initial backup. Right now that's in configure.)
so if you have just one function for enable/disable then you can do
local globalish_var ... # show a select dialog for enable/disable cmd=(dialog --backtitle "$__backtitle" --cancel-label "Exit" --default-item "$default" --menu "Choose an option." 22 86 16) options=() # add options and show choice local choice=$("${cmd[@]}" "${options[@]}" 2>&1 >/dev/tty) [[ -z "$choice" ]] && break default="$choice" case "$choice" in 1) # run disable code, using $globalish_var ;; 2) # run enable code, using $globalish_var ;;
...then there's no enable function that can be called to enable the music on first install. They'll need to manually enable it after installing, or else we'll need to duplicate the "enable" code somewhere else (in configure, probably) to do that.
This way, if the user has disabled the functionality, updating will not change their choice.
How I have now does that, too:
1: initial config is created, with "installed" (as in, "has it been installed already once before?") set to 0 ("false.")
2: configure checks the config, sees that it has not been installed before, runs enable. Sets "installed" to 1 ("true.")
3: user disables music.
4: user runs update or reinstall. Config already exists, default with installed 0 is created at.rp-dist
; working file with installed 1 is retained; configure checks the working file, sees that it has been installed before, does not re-enable.
∴: if the user has disabled the functionality, updating will not change this. -
So if I use an .rp file in the menu, to call the gui function, but play/pause aren't in the gui function, then where are they, and how do I get there? Do you mean you'd have both an .rp (to run the gui function with configuration options) and an .sh with a separate UI for the play controls? I don't really want two separate menu options, though. So how else? An option in the gui function that calls the external playback UI? I don't see a benefit in that either.
Then leave the configuration (
gui_
) just in RetroPie-Setup and in the RetroPie menu just have a.sh
script for normal operations (play/next/pause/stop/shuffle/etc.) that doesn't need any of the RetroPie-Setup functions....then there's no enable function that can be called to enable the music on first install.
Installation is a non-interactive operation, so there's no user input at this stage. If the user installs the package, then just assume they want it working and enable it - why require an extra step after installation ?
1: initial config is created, with "installed" (as in, "has it been installed already once before?") set to 0 ("false.")
2: configure checks the config, sees that it has not been installed before, runs enable. Sets "installed" to 1 ("true.")
3: user disables music.
4: user runs update or reinstall. Config already exists, default with installed 0 is created at .rp-dist; working file with installed 1 is retained; configure checks the working file, sees that it has been installed before, does not re-enable.
∴: if the user has disabled the functionality, updating will not change this.I don't see why any checks would be necessary if you don't overwrite the user's configuration file. Configure just installs a default configuration file and that's it - just call
copyDefaultConfig
and no checks are necessary. -
@mitu said in More script-dev questions. How to log errors in external scripts?:
Then leave the configuration (
gui_
) just in RetroPie-Setup and in the RetroPie menu just have a.sh
script for normal operations (play/next/pause/stop/shuffle/etc.) that doesn't need any of the RetroPie-Setup functions.So, we're back at where we started. I want the play/pause/next functions and the setup options (enable/disable, there's already a mapped volume setting, I hope to make others) all available from the same place. You don't want to go in one menu (gui_ using RPSetup) to select your playlist, and then have to back out of that and enter the BGM UI menu to play it.
At least, I don't. I want to go in one menu, from the ES RPMenu (as its own menu item, with the icon, without going into RPSetup first) and do it all in one place. Enable the music, start the music, stop the music, change the settings.
But, if I happen to be at a terminal, instead of a gamepad, when I decide to change my settings, I do still want the option to go into RPSetup if I want to and do it all from there, as well. I don't want to have to use RPSetup, but I want to be able to.
So, I'm either doing the same thing twice by duplicating it all in RPSetup and RPMenu, or I'm just using the same gui_ for everything.
I'm leaning heavily towards "everything."
You keep saying not to put play/pause in the gui_ and I keep asking why not, and you keep not saying why not, and I did it anyway and it's working fine, as far as I can tell.
Installation is a non-interactive operation, so there's no user input at this stage. If the user installs the package, then just assume they want it working and enable it - why require an extra step after installation ?
(The "extra step" is performed automatically, after all. You're not under the impression that the users need take any action besides install it, drop some songs in the network share, and restart, are you?)
So that I can use the same piece of code two times, to enable it both automatically on initial install, and then again later when the user enables it manually after previously disabling.
Otherwise, I'm writing it out twice; first I write one piece of code to do it non-interactively at install, and then another piece of, near-identical code, to do it interactively in the gui. Why? Why not just call the same function to do it at both times? Like, literally, why not? That's not rhetorical I'm asking the actual reason.
I suppose, if I wrack my brain for an upside, I guess if we put the "enable" code once in
configure* to do it automatically, and then again in gui_ for manual operation, it would only need two blocks of the "local autostart, autostart=, local bashrc, bashrc=, etc." instead of three (configure needs it, already has it; enable and disable both need it, or it could be done once in gui, if they were both rolled into there). But that's just trading one duplicate (the enable code itself) for another (the global vars.) The enable code is half as many lines as the variables block, but it's more than twice the bytes, so I'm not sure if that's a win or not...*(actually it would be in install, since we can't do it in configure, in case it's not the first run , and you don't want to check the .cfg to find out. So now we need the global vars in there again too...if we did the backup and the enable in the install function, then the vars could come back out of configure and we're back at three uses of them.)
I don't see why any checks would be necessary if you don't overwrite the user's configuration file. Configure just installs a default configuration file and that's it - just call
copyDefaultConfig
and no checks are necessary.I do not overwrite the configuration.
pi@retropie:/opt/retropie/configs/all $ cat bgm123.cfg # Configuration file for bgm123 installed="1" mapped_volume="1" music_player="mpg123" pi@retropie:/opt/retropie/configs/all $ cat bgm123.cfg.rp-dist # Configuration file for bgm123 installed="0" music_player="mpg123" mapped_volume="1"
-
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
You keep saying not to put play/pause in the gui_ and I keep asking why not, and you keep not saying why not, and I did it anyway and it's working fine, as far as I can tell.
I think you already said why - because it's faster and it shouldn't need to load RP's existing helpers.
Otherwise, I'm writing it out twice; first I write one piece of code to do it non-interactively at install, and then another piece of, near-identical code, to do it interactively in the gui. Why? Why not just call the same function to do it at both times? Like, literally, why not? That's not rhetorical I'm asking the actual reason.
Sure, just use the same function (so vars are only needed once) and have the 1st param of the function
on
oroff
.I do not overwrite the configuration.
That was not about overwriting the config, but about the extra checks done during configure - if there is already a config file, why do all the other checks in steps 2 / 4 ?
-
@mitu said in More script-dev questions. How to log errors in external scripts?:
Sure, just use the same function (so vars are only needed once) and have the 1st param of the function
on
oroff
.Okay, that's something I can work with. Enable/disable are (will be) one function, with something like if $1 == "on" then [enable code] else [disable code], and then I'll call the function with
enable_bgm123 on
to enable andenable_bgm123 [anything else]
to disable. That saves some repetition and still allows non-interactive operation when needed.###
if there is already a config file, why do all the other checks in steps 2 / 4 ?
I've been thinking more about this, and perhaps our disconnect stems at least partly from the fact that the "enabled" status is not actually read from or written to the user config. If this is new information to you, then I think we're up to speed; if you already understood this, then I'm unfortunately still in the dark:
To check if it's enabled, I just grep
autostart
for the actual code that plays the music on startup (well, I check for the#bgm123
tag that I paste on the end of that code.) If that code is there, then the music will play and if it's not, then it won't.And then to perform the enable/disable, I just add or remove those lines. Never does the config actually come into it. So that is why I can't just write the config with enabled or disabled status and then leave that status alone on updates if the user changes it. The only way the module knows whether it is enabled or not, is if the
#bgm123
code is there or not, and if it isn't there, it needs another way to determine whether that is because 1) it has never been installed before and should be added now, or 2) the user has disabled it, and it should not be added.###
I think you already said why - because it's faster
That was only an issue briefly when gui_ just said "bash $menuscript" and menu script then called back to
retropie_packages.sh
to call the enable and disable functions from the module. Only then, there was a long delay while _packages.sh loaded to run the enable or disable function. I abandoned that method pretty quickly, because of it.Both this version (menu script is completely divorced from gui_ and everything is written twice) and the current one (everything done in gui_, called with .rp file and does not use a menu script -- does all the same things but I only have to write them once) do not have that issue. Both take about the same 5-6 Mississippi's to load the GUI from ES, and both respond promptly to all choices once they do load.
If it's any faster to get in with the
.sh
than it is with the.rp
, it's not by much. I didn't break out a stopwatch to really test it down to the second, but I didn't notice any difference. Except the first one, 93940be. That was bad. I did notice that. And I'm not doing that anymore, because.Actually I did break out the stopwatch just now. In 48ffd1f with the .sh file it took, from button to blue screen, 6.9, 6.6, and 6.9 seconds on three trials.
In 19f7d67 with the .rp file it took 6.9, 13.5, and 7.0. That middle one threw me so I did three more and got 6.9, 6.8, 6.9. Three more: 6.9, 7.8, 7.3. Again: 8.8, 7.7, 6.8. Okay last time: 6.8, 6.8, 7.0.
So it seems like that "13.5" looks like an anomaly; maybe I selected it again too soon after exiting from the previous time or something. But ignoring that one outlier, it takes "about seven or eight seconds, " regardless (I guess my Mississippi's are a little slow since I estimated "five or six"), with maybe a slight edge to the
.sh
version, at the expense of duplicating all of the code for any function I want in both menus (which doesn't have to include play/pause but does have to include enable/disable and any -- or at least probably most -- additional configurations that are added in the future.)and it shouldn't need to load RP's existing helpers.
Doesn't that already happen when ES launches the item from retropiemenu with:
<command>sudo /home/pi/RetroPie-Setup/retropie_packages.sh retropiemenu launch %ROM% </dev/tty >/dev/tty</command>
...? And then function
launch_retropiemenu
looks at it and decides whether torp_callModule gui
orbash
the item depending on whether it's been given an .rp or an .sh file to work with. But it's already in _packages.sh so if it chooses to use rp_callModule, it just has to run the helper, it's all already been loaded in that first ~7 second pause. Right? -
@sleve_mcdichael said in More script-dev questions. How to log errors in external scripts?:
I've been thinking more about this, and perhaps our disconnect stems at least partly from the fact that the "enabled" status is not actually read from or written to the user config. If this is new information to you, then I think we're up to speed; if you already understood this, then I'm unfortunately still in the dark:
OK, so if you're not storing the status in the config, then the external checks are needed. Wouldn't it be easier to read it from the config though ? - the enable/disable operations will go through your menu/gui, so you can easily control this.
If it's any faster to get in with the .sh than it is with the .rp, it's not by much. I didn't break out a stopwatch to really test it down to the second, but I didn't notice any difference.
...I was thinking that for normal operation loading the RetroPie
packages
functions wouldn't be needed, this involves additional function executions (i.e. evaluate the system platform, read packages, find thegui_
function, etc.) that shouldn't be needed just for running Next/Prev/etc. But if you think it's not a big difference (as benchmarked), you can have them in thegui_
function. Just have in mind that on other systems (rpi0/rpi3, slower sdcard) this time may increase.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.