shell scripting topic
-
@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. -
@hiulit said in shell scripting topic:
First of all, we would be able to be more helpful if you say what exactly you want to do. Anyways, here are some thoughts about what you asked...
I'm trying to detect if the device is
arm
based. If not, I'm gussing it'sx86
based .I would use the
system.sh
scriptmodule for this or at least get some inspiration from its code.Example using the existent code:
. $HOME/RetroPie-Setup/scriptmodules/helpers.sh . $HOME/RetroPie-Setup/scriptmodules/system.sh get_platform echo "$__platform"
Or get inspiration from the function starting on this line of code to write your own function.
The
$__platform
variable is one of these:
rpi1
rpi2
rpi3
odroid-c1
odroid-c2
imx6
odroid-xu
tinker
x86
(...) get the screen resolution.
I agree with @mitu above.
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.
-
probably a useless one but might come in helpful if people dont know use -- in a command line if it has special characters and bash will ignore the special characters.
pi@retropie:~ $ touch -- +1.txt
pi@retropie:~ $ less -- +1.txt
pi@retropie:~ $ less +1.txt
Missing filename ("less --help" for help) -
Thanks to all! You were very useful :)
Sorry @meleu (and @mitu ) if I wasn't more precise.
The problem I'm facing is that I want to get the screen resolution to create launching images accordingly to that size, but the way I found to get it differs from, for example, my Raspberry Pi (
arm
) and my VM running Pixel (x86
).I think I like @meleu 's idea of using
$__platform
. -
I'm intrested in developing a script that will generate a custom list for my GameEx High Scoring Competition. GameEx is a frontend I use on my PC, and our forums have created a competition for it's users. I'm actually the primary moderator for that forum. We have a utility for keeping track of scores and generating forum tables. It's all nice and good. I came up with an idea to generate a map file, which allows you to create a "custom list" menu inside GameEx, so you can instantly get into a game that is available for posting high scores with. It works great. I was looking to do something like that for RetroPie too. My PC's keyboard no longer works, and the only way I can use that PC is through RemoteDesktop. However, I have all the games on my Pi, so why can't I just use that?
Here's a breakdown of what I need to accomplish:
- Upon turning on the system, as part of the boot process, have a script go out and download the updated list of games from a server. The utility we use to track scores already generates this list and uploads it somewhere, so I just need something to grab it.
wget
perhaps?- This may not need to be done during EVERY bootup.. in fact it might not even work if there is no internet available.
- Maybe the script should just be available for manual launching? We only add new games every 2 months now.
- After getting the list, it needs edited to work with EmulationStation's custom list features, as by default the list is probably not directly usable.
- Save the edited list as a custom list file, in the appropriate folder for EmulationStation to pick it up.
For reservation, here is the map file:
http://gameinfo.hfc-essentials.com/hiscore/HiScore.mapAnd here is a MAME favorites ini file:
http://gameinfo.hfc-essentials.com/hiscore/HiScore.iniI'm not sure which file would be easier to work with. But if you look at them, it should be easy enough to figure out the editing that needs to happen. Can detailed editing of the file be done automatically via a script? I wasn't sure so I thought I'd ask here. I also asked our developer of the tool we use to see if he can update the tool to also spit out a plain text list.. Looking to see what can happen, or happens. I'd just like a bit of hand holding, not really asking somebody to step in and do all the work (would be nice but I can't learn scripting without practice!).
What are your suggestions or recommendations?
- Upon turning on the system, as part of the boot process, have a script go out and download the updated list of games from a server. The utility we use to track scores already generates this list and uploads it somewhere, so I just need something to grab it.
-
@hansolo77 It can be done. This is how I'd do it.
-
Download the .map file (curl/wget) locally. Should be text only. Check for errors or if the file is empty and exit if so.
-
Read the file line by line, split it in
col1
(zip name) andcol2
(game name). For eachcol1
:- Look in the gamelist for the
arcade
system to search forcol1.zip
, either viagrep
orxmlstarlet
. [1]
The idea is to get the path to the ROM zip file as the value intopath
- If you found the
path
, then check ifarcade_folder_path/path
exists and if so, add it to a list (list_rom
). - Repeat steps above if your rom might be in a different system (i.e.
mame2003-libretro
,fba
) and nothing was found in the previous step.
- Look in the gamelist for the
-
At the end, walk over
list_rom
and produce a custom collection file in$HOME/.emulationstation/collections/custom-GameEx.cfg
containing one line for each ROM path in the list. If a previous.cfg
fie exists, back it up.
You should have to create the collection before running the script so you can choose in ES to make it visible, but once ES knows to show it, I think you only need to restart ES after each script run.
The above assumes you only have arcade ROMs, since the naming is standard. Make sure to lowecase the
col1
in step 2 (I've seen that TMNT is uppercase, but the zip name should be lowercase and[1] - get the path of rom using
xmlstarlet
and ROM name.$ xmlstarlet sel -t -v "//game[contains(path,'1943.zip')]/path" .emulationstation/gamelists/arcade/gamelist.xml # outputs: ./1943.zip
-
-
I knew it could be done! :) Now to just decipher all that and make a script lol. I’m on vacation after next week, maybe I’ll try to work on it then!
-
-
@hiulit said in shell scripting topic:
@meleu @mitu What I'd like to achieve is getting the screen resolution of the device that is/will be using Fun Facts! Splashscreens. And I've seen that it differs from different systems.
Uhmmm... maybe what you need is slightly different than just detect whether the user is running your script while in a x11 environment or not.
If you need to discover if the emulators you installed/compiled on your RetroPie were for use on a X11 environment, I suggest you to try the
isPlatform
function. You can do something like this:. $HOME/RetroPie-Setup/scriptmodules/helpers.sh . $HOME/RetroPie-Setup/scriptmodules/system.sh if isPlatform "x11"; then echo "Your emulators runs on a X11 environment" else echo "Your emulators does NOT run on a X11 environment" fi
Regarding resolution discovering techniques, you are surely ahead of me on this subject. :-)
I hope it helps.
-
@meleu My problem was that I had these
xdpyinfo
functions to get the screen resolution and they were working in my VM running Pixel, but when I tried them on the Raspberry Pi I got an error, something like:xdpyinfo: command not found
. I triedsudo apt-get xdpyinfo
but it didn't work, so I manage to found another way to get the screen resolution from a Raspberry pi, and that's where thesefbset -s
functions come from.So now I need to know when do I need to use one function or the other.
What I have right now (and seems to be working) is:
function get_system_platform() { . "$home/RetroPie-Setup/scriptmodules/helpers.sh" . "$home/RetroPie-Setup/scriptmodules/system.sh" get_platform echo "$__platform" } function get_screen_resolution_x() { if [[ "$(get_system_platform)" != "x86" ]]; then local screen_resolution screen_resolution="$(fbset -s | grep -o -P '(?<=").*(?=")')" echo "$screen_resolution" | cut -dx -f1 else xdpyinfo | awk -F '[ x]+' '/dimensions:/{print $3}' fi } function get_screen_resolution_y() { if [[ "$(get_system_platform)" != "x86" ]]; then local screen_resolution screen_resolution="$(fbset -s | grep -o -P '(?<=").*(?=")')" echo "$screen_resolution" | cut -dx -f2 else xdpyinfo | awk -F '[ x]+' '/dimensions:/{print $4}' fi }
-
@hiulit
xdpyinfo
is part of thex11-utils
package (https://packages.debian.org/stretch/x11-utils), so it's not installed if you're not installing an X.org env (like in Raspbian Lite). But even if it is installed, it only works in a X.org session (desktop environment), otherwise it will return an error. -
@mitu So then, would it be save to use something like this?
if [[ $DISPLAY ]]; then xdpyinfo blah, blah... else do_something_for_none_X_org_session fi
-
@hiulit said in shell scripting topic:
@mitu So then, would it be save to use something like this?
if [[ $DISPLAY ]]; then xdpyinfo blah, blah... else do_something_for_none_X_org_session fi
eh... did you read my last post above? I think it answers exactly what you asked on your last post.
-
@meleu Yeah, I read it, but I thought it was a different thing, because you said:
If you need to discover if the emulators you installed/compiled on your RetroPie were for use on a X11 environment
and don't know if I want/need to know if the emulator is compiled for X11 but rather if the machine is running X11. Or at least that's what I think.
I'm really not sure if I'm not explaining myself clearly or if I'm not understanding you, but just in case, I'll try it one more time :P, hehe!
I need to get the screen resolution of the machine running RetroPie. How can I have a cross-platform solution? Because the Raspberry Pi has one method of getting the screen resolution and my VM running Pixel has another one (and maybe another platform will have another method)
Sorry again @meleu and @mitu if I'm not being clear enough. Or if I'm not asking the right questions.
Thanks!
-
@meleu Thanks for your Pull-Request on BashROMManager
It's not just cosmetic ;)
I also resolved a small bug that would prevent us from using the FastForward featureSo version is 0.79 now and I think it's a solid codebase for improvements and for changing coding style... step by step
@hiulit You are also welcome to give your input here
We are talking about here: https://github.com/crcerror/RetroPie-RPM-BashROMManager
;) -
@hiulit Here are some info that looks like you're not aware (and is confused because of it):
-
X is the graphical server for UNIX systems (including Linux).
-
the resolution on a pure command line (the one you're getting with
fbset
) is different than the resolution when you are on a X environment (the one you're getting withxdpyinfo
). -
The emulators installed by RetroPie on a Raspbery Pi do NOT need a X environment.
-
The emulators installed by RetroPie on a Linux-x86 system needs a X environment.
-
If you are on a Raspberry Pi and
startx
(or whatever command you use to start the graphical interface) you'll have the$DISPLAY
variable, but it does NOT mean that you run the emulators on X. Therefore, when you show your launching image (with a fun fact on it) you will NOT necessarily be on the resolution you detected with your current method.
Even after all this stuff being said, I wouldn't bother that much to detect the resolution with this degree of precision. In my opinion you should focus only on keeping the aspect ratio of the image you're using for background, this would be enough.
If you show me exactly where in the fun-fact's code you want/need this and I can try to be more helpful.
-
-
@cyperghost Yeah, thanks! I've been following the thread ;) I'll dig in when I have the time. Good job!
-
@cyperghost I strongly recommend you to take a look at @hiulit 's work on the retropie-shell-script-boilerplate.sh (I believe he would give this input also). I also worked on that template.
I was about to submit a new PR when I realized that you would take some advantage looking at that code. ;-)
@hiulit what do you think about focusing on aspect ratio instead of trying to detect the exact resolution?
-
@meleu Hey sorry, yeah, maybe you're right! But then, should I have a predefined resolution? Like
1080p
,720p
,800x600
and let the user decided which size to use? -
@hiulit said in shell scripting topic:
should I have a predefined resolution?
I'm not confident enough to say what you should do :), but I can say what I do on my launching image generator tool.
I'm currently away from my dev machine to confirm, but IIRC the command below is what you need to resize an image to a height of 576 pixels. The
resulting_image
's width will be the one necessary to keep the same aspect ratio of theoriginal_image
.convert -resize x576 original_image resulting_image
EDIT: confirmed. The command above works exactly as I described.
By the way, I noticed you're commiting experimental stuff (such as this resolution thing you were discussing above) directly on the master branch of the fun-facts repo. This is NOT a good practice. ;-)
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.