shell scripting topic
-
-
@cyperghost as far as I understood @hiulit wants specifically the font used in detailed view. At least that's what that
xmlstarlet
command is getting.@hiulit submitted another PR: https://github.com/hiulit/es-fun-facts-splashscreens/pull/2
-
@meleu Ah okay approved. But I think a generic solution is hard to find - so it's nice to have the fallback option to use Carbon-fonts :)
-
Well, actually, I used the same line @meleu is using in his
generate-launching-images.sh
:P See:xml_path="/theme/view[contains(@name,'detailed')]/textlist/fontPath"
I don't know if we could have a more "standard" search function for fonts, because some themes have different fonts and it would be difficult to know which one is the "primary" font. I'm not into EmulationStation theming so I don't know if there's a predominant font that we could use.
Also, @cyperghost , if I understood you correctly, you though about searching for the font based on the theme's name? (e.g
Pixel theme
->pixel.ttf
)
Because, for what I see, there isn't a "standardized" naming convention on font naming for themes.
The default to Carbon's font it's nice, yeah! ;) -
I would like to try to run Fun Facts Splashscreens on system's shutdown (or startup) but I don't have any clue about where to start looking. Any hint?
I've been looking at this thread https://retropie.org.uk/forum/topic/4836/emulationstation-shutdown-script/ and I've been able to add a line in
/opt/retropie/supplementary/emulationstation/emulationstation.sh
to launches-fun-facts-splashscreens.sh
and it works, but I don't think this is right place to do it nor the way to do it.The place isn't right because, I think, the script should run either on system's startup or shutdown, as @Zigurana mentioned, not when EmulationStation starts, restarts or shutdowns. It doesn't make sense, because the splashscreens shows before EmulationStation starts.
And the way to do it isn't right because I don't like that, for this script to be launched, you have to edit some "core" files.
Is there any way to launch a script either on system's startup or shutdown?
-
@hiulit said in shell scripting topic:
/opt/retropie/supplementary/emulationstation/emulationstation.sh
This file will be overwritten after the next ES update. Then, you're right, it's not the best script to tweak...
Is there any way to launch a script either on system's startup or shutdown?
At shutdown it's a bit tricky. I did this for my trick to gracefully finish ES and save metadata in every system shutdown
At start it's pretty simple:
/etc/rc.local
. And in my opinion your script can safely be placed here but you need to remove that command to show the image in the end.It's a good place because the script can be setted to run in background (add
&
in the end of line that is calling your script). I think the current splashscreen to be displayed will be the previous generated one, but your script would be generating a new splash for the next boot. ;-) -
@meleu I've added the script to
etc/rc.local
but it seems that there's something wrong with the$home
variable. I get this error:sed: cant' read /root/.emulationstation/es_settings.cfg: No such file or directory
Instead of getting
/home/pi
as$home
, it getsroot
, so the script doesn't work. -
@hiulit If I launch the script adding
-H -u pi
it works, but I don't think it's the best way to do it... -
@hiulit said in shell scripting topic:
@hiulit If a launch the script adding
-H -u pi
it works, but I don't think it's the best way to do it...IMHO it's perfectly acceptable and also a really good way to do it. ;-)
Of course if we evolve this method, this config (adding the script call in
rc.local
) won't be made manually, and then we can get the username to use.;)
-
@meleu But then, does it make sense to keep using this?
user="$SUDO_USER" [[ -z "$user" ]] && user="$(id -un)" home="$(eval echo ~$user)"
Because that's what's getting
root
as$home
when the script is launched in/etc/rc.local
.We could then just do
home="/home/pi"
, don't you think?
Because adding the user-H -u pi
like this removes the dynamism of the function (getting the user dynamically), right? -
@hiulit said in shell scripting topic:
@meleu But then, does it make sense to keep using this?
user="$SUDO_USER" [[ -z "$user" ]] && user="$(id -un)" home="$(eval echo ~$user)"
Yes. Keeping this in the script makes sense because the user can use it at any moment, right?
Because that's what's getting
root
as$home
when the script is launched in/etc/rc.local
.Does it happen even when using
sudo -H -u pi ...
???We could then just do
home="/home/pi"
, don't you think?
Because adding the user-H -u pi
like this removes the dynamism of the function (getting the user dynamically), right?Sorry if I misunderstood you, but you want to avoid to remove dynamism by hardcoding
home=/home/pi
? Sounds weird for me.I would consider what we have until now like a proof-of-concept script (kudos to you for working on this). Let's wait what the big boss will say about my proposal and take next steps based on his decision.
If he refuse, we can continue this project extra-officially. I'm just trying to say that what approach to use to launch the script at startup depends on that decision.
-
@hiulit said in shell scripting topic:
Also, @cyperghost , if I understood you correctly, you though about searching for the font based on the theme's name? (e.g Pixel theme -> pixel.ttf)
Because, for what I see, there isn't a "standardized" naming convention on font naming for themes.
The default to Carbon's font it's nice, yeah! ;)No, we misunderstood ;)
If the theme CARBON looks like this
./art/font-1.ttf and ./art/font-2.ttf
you can try to usels *.ttf -R
to find all fonts that are in the theme folder.
Then do a grep search with all fonts and give the most usefull hit the path to your$DEFAULT_FONT
Is it clear now? But maybe @meleu gots a better solution. I know it's bad to use
ls
command for this action ;) -
@meleu Ok, you're right! I didn't explain myself clearly, hehe! It sounds weird not wanting to hardcode
sudo -H -u pi
but wanting to hardcodehome="/home/pi"
instead :P Nonsense!Now, I'm at home and I'm testing the script in an actual Raspberry Pi with RetroPie and I have a couple of things to comment:
-
I've added
sudo ~/es-fun-facts-splashscreens/es-fun-facts-splashscreens.sh &
and it seems to work when I launch/etc/rc.local
from the terminal, but not when the system boots up. -
I've tried adding
-H -u pi
and it doesn't seem to work.
This code worked perfectly! :D I didn't had
imagemagick
installed on this Raspberri Pi and the warning pop up, nice!if ! which convert > /dev/null; then echo "ERROR: The imagemagick package is not installed!" echo "Please, install it with 'sudo apt-get install imagemagick'." exit 1 fi
But I didn't had
feh
installed and the warning didn't pop up :(if [[ -n "$DISPLAY" ]] && ! which feh > /dev/null; then echo "ERROR: The feh package is not installed!" echo "Please, install it with 'sudo apt-get install feh'." exit 1 fi
Maybe instead of
&&
it should be||
?
Or maybe remove[[ -n "$DISPLAY" ]]
and just leaveif ! which feh > /dev/null
?Anyways, the script works perfectly by itself and when launching
/etc/rc.local
from the terminal, but not when it's supposed to be launched in/etc.rc.local
at startup. -
-
@cyperghost Ok, but how would we know which is "the best hit"? Based on what?
-
@hiulit Well the xml in the root of the theme or keywords like "mainfont=font-1.ttf".... That are just suggestions.
Or you write an identifier.txt so you say: theme, font
# Example file Carbon, system.ttf IO, mainfont.ttf
-
@cyperghost don't get me wrong! I really appreciate the feedback :)
I think we can try to find a generic method to get fonts if we squeeze our minds together
-
What do you think about this code?
I want to add a line in/etc/rc.local
to launch a script.
Also, I want to check if that line is already in/etc/rc.local
.
Additionally, I want to check if/etc/rc.local
has the neededexit 0
at the end (in case the user removed it).
The latter is totally optional.# If the user mistakenly removed "exit 0", add it at the end of "/etc/rc.local". function check_safe_exit_boot_script() { if [[ "$(tail -n1 /etc/rc.local)" != "exit 0" ]]; then sed -i -e '$i \exit 0\' "/etc/rc.local" fi } # Get the line that launches script at boot. # $SCRIPT_DIR="/home/pi/es-fun-facts-splashscreens". function check_boot_script() { grep "$SCRIPT_DIR" "/etc/rc.local" } # Add the line to launch script in "/etc/rc.local" function add_boot_script() { sed -i -e '$i \\n'"$home"'/es-fun-facts-splashscreens/es-fun-facts-splashscreens.sh &\n' "/etc/rc.local" check_safe_exit_boot_script } # Check if the line that launches the script is already in "/etc/rc.local" # If it's not, add it. [[ -z "$(check_boot_script)" ]] && add_boot_script
-
@hiulit Well I think as
setup.sh
this is possible. Withwget path/to/your/github/es-funfacts.sh
a (half)automated installation shouldbe possible ;)About the correct font ... there is surly a generic solution. But what about adding just a path to a font via command line parameter?
So you havees-funfacts.sh /path/to/font.ttf
- Find automatically the correct font
- If 1 fails, try to use Carbon font (as default theme)
- If there is a parameter available then 1 and 2 are ignored
-
Hello my fellow nerds! :P
What do you think about this code?
First piece of code is this one:
function is_arm() { uname -m | grep -q "arm" }
I'm trying to detect if the device is
arm
based. If not, I'm gussing it'sx86
based .And then I'm using this other piece of code to get the screen resolution.
arm
based systems andx86
based systems have different methods to get the screen resolution. And that's what I've come up with.function get_screen_resolution_x() { if is_arm; then fbaset -s | cut -dx -f1 else xdpyinfo | awk -F '[ x]+' '/dimensions:/{print $3}' fi } function get_screen_resolution_y() { if is_arm; then fbaset -s | cut -dx -f2 else xdpyinfo | awk -F '[ x]+' '/dimensions:/{print $4}' fi }
-
@hiulit If your intention is to detect whether the user is running under a desktop environment (X) or not, then I wouldn't use the architecture of the kernel to determine that, but something more simple like testing if the DISPLAY env is available or something like this.
Running on an ARM board doesn't mean the user's session is not running under Pixel and vice-versa.
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.