shell scripting topic

meleu

@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?

hiulit

@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?

meleu

@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 the original_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. ;-)

cyperghost

This post is deleted!

cyperghost

@meleu Yes I used your function call. Works nice.
Is there anything against the return $value method?
Or am I abusing the being of $? as method to check if a function/command gave return code =0 for okay and !=0 for errors?

So thx... pushed BashROMManager to v080 now.
Do you have any suggestion in the use of xmlstarlet or better use grep?

Maybe the script can be extended to clean also image-files and videos related to it - version 2.x?

hiulit

@meleu Yeah! I know! I should've created a new branch for this new feature.. :P But It is safe to use master because I made the code backwards compatible, so nothing that was already there is broken and the new things aren't even documented yet. When using git for yourself (at least for me) you tend to use bad practices because it's easier, hehe!

A part from that, I see you point of just using height to maintain the aspect ratio, but I don't know how can I can create images for different resolutions that will look good on every device. I mean, if I use, let's say, the 576px you said, it will look too small on a 1920x1080 screen, I think. I'll give it a try anyway to see how "bad" (or good!) it looks. Thanks, as always! ;)

meleu

@hiulit said in shell scripting topic:

I don't know how can I can create images for different resolutions that will look good on every device. I mean, if I use, let's say, the 576px you said, it will look too small on a 1920x1080 screen, I think

My tool generate launching images with 576 pixels height and keep the aspect ratio of the image being used as background, Rokkervik's pixel-themed launching images are 480x272. All of them looks just fine on my 1920x1080 TVs...

If you create launching images 1920x1080 the resulting file can be very big and the raspberry pi can delay to display a big image

hiulit

@meleu Yeah, you're right. Pixel theme images look fine on my 1920x1080 monitor. I'll try it! ;)

hiulit

I've created this little script to format all theme.xml from a given EmulationStation theme with 4 spaces. It's really unnecessary, but I'm that kind of person :P

Here it goes:

#!/usr/bin/env bash

THEME="pixel"

for folder in "/etc/emulationstation/themes/$THEME/"*; do
    if [[ -d "$folder" ]]; then
        if [[ -f "$folder/theme.xml" ]]; then
            cp "$folder/theme.xml" "$folder/theme-backup.xml"
            xmlstarlet fo -s 4 "$folder/theme.xml" > "$folder/theme-indent.xml"
            sed -i '/\?xml/d' "$folder/theme-indent.xml"
            cp "$folder/theme-indent.xml" "$folder/theme.xml"
            rm "$folder/theme-indent.xml" "$folder/theme-backup.xml"
        fi
    fi
done

hiulit

When you have a dialog inside a dialog inside a dialog (and so on...), can the "Cancel" button act as a "Back" button? I know the label can be changed, but when you click it it goes back to the first dialog :(

meleu

@hiulit there's no "dialog inside a dialog". You execute a dialog and when you choose the "OK" or "Cancel" button the dialog finishes.

What causes that impression of a "dialog inside a dialog" is usually a dialog being called one right after another, each one inside its own while loop structure.

The example I have to show is one of my codes that I am least proud of when it comes to well-written code, but well, let's try...

Check the rpie-art code here: https://github.com/meleu/rpie-art/blob/master/rpie-art.sh

This while loop in main_menu() contains the first dialog. Depending on the option, the script calls another function which has another dialog. Let's follow the uninstall_art_menu() flow.

When the user choose X on the main_menu(), the script calls the uninstall_art_menu() function which has another dialog where you can:

Choose Cancel: the logic flow returns to main_menu() and that loop calls the main_menu()'s dialog again.
Choose a valid option. Which calls another function which has another dialog and the chain-of-dialogs goes on...

Eh... I'm not sure if I explained well. 😅

Read, check the code and reread. If you still don't understand feel free to ask. ;-)

hiulit

@meleu Thanks! That's what I thought. I'll create some functions then, as you did ;)

hiulit

Hi there!
Can somebody help me figure this out?

I have an argument passed to a shell script fun-facts-splashscreens.sh --create-fun-fact that can have:

no options
1 option [system]
2 options [system rom]

How can I write a help message? --create -fun-fact [] [system] [system rom]?

Thanks!

mitu

@hiulit Add a -h option and display the help when this option is passed to the script.

hiulit

@mitu I'm sorry, I didn't explain myself clearly enough.

I already have a -h option that shows all the options available. What I meant is, how should I tell the user that the option --create-fun-fact can have:

no options
1 option [system]
2 options [system rom]

That's what I've come up with: --create-fun-fact [] [system] [system rom]
Is that correct?

Did I explain myself better this time? :P

mitu

@hiulit said in shell scripting topic:

--create-fun-fact [] [system] [system rom]

Ah, ok. I think the correct syntax would be

--create-fun-fact [SYSTEM] [ROM]

Usually an argument in brackets ([arg]) means the argument is optional.

hiulit

@mitu I see! And if an argument is NOT optional? I have some of those around :P

mitu

@hiulit If it's not optional, just remove the brackets.

--create-fun-fact system [rom]

meleu

@hiulit can you explain the use case and provide some examples?

I'm sure we can find ways to make an option have zero, one or two options, but from a user point of view I think it's a bit confusing.

EDIT:
I can't see what would be the use for --create-fun-fact system rom, but if it's intended to be used on RetroPie, you can detect the system by looking the directory where the rom is located.

hiulit

@meleu I'll try to explain myself even better than the last time :P Here we go!

This all comes from the fun-facts-splashscreens-runcommand-onend.sh that has these lines:

SYSTEM="$1"
ROM_PATH="$3"
sudo "$SCRIPT_DIR/fun-facts-splashscreens.sh" --create-fun-fact "$SYSTEM" "ROM_PATH"

This is what creates the launching images when stoping the game. This is something the user doesn't need to care about. But then I already had --create-fun-fact in the help message so I wanted to let the user use it, like this:

--create-fun-fact with no options passed creates a boot splashscreen.
--create-fun-fact [SYSTEM] (SYSTEM can be all or any RetroPie system) creates launching images for all the systems, or the given system with the system's logo (and console if it exists).
--create-fun-fact [SYSTEM] [ROM] (ROM can be an absolute path or just the ROM's name + ext, and then it takes the given system to look for the path) creates a launching image for the game.

Examples:

--create-fun-fact
--create-fun-fact all
--create-fun-fact megadrive
--create-fun-fact megadrive "/home/RetroPie/megadrive/Sonic the Hedgehog.zip"
--create-fun-fact megadrive "Sonic the Hedgehog.zip"

I can see that from the user's perspective it could be a little confusing... Maybe it's better to split --create-fun-fact into two separate functions --create-fun-fact-boot-splashscreen and --create-fun-fact-launching-images.

Maybe I should remove this option from the help message? Just have it for myself to test?
That's something that can be done via the GUI, btw: