feat: Bash script to setup automatically by PonyLucky · Pull Request #244 · DeckCheatz/wemod-launcher

PonyLucky · 2026-02-24T00:14:33Z

Supports:

Arch-based OS (pacman only)
Fedora-based OS (rpm-ostree and dnf)
Debian-based OS (apt only)

Note:
In the readme.md, the url for the script is directly for the main branch. Less work for the approver.

P.S.: For Fedora-based OS, rpm-ostree takes priority over dnf, this safeguard shouldn't be needed as Bazzite shouldn't have dnf. Still future-proof.

Related to: #243

PonyLucky · 2026-02-24T00:16:58Z

If running the script inside the current already cloned directory, the WEMOD_DIR variable is wrong (L108).

Example:

Instead of $HOME/Documents/wemod-launcher.
It is $HOME/Documents/wemod-launcher/wemod-launcher.

shymega

Only one nit so far!

PonyLucky · 2026-02-24T00:53:20Z

marvin1099 · 2026-02-24T03:20:35Z

+# Make wemod python script executable
+chmod +x "$WEMOD_DIR/wemod"
+# Add a txt file to always have the launch command at hand
+"$WEMOD_DIR %command%" > $WEMOD_DIR/launch-command.txt


Since this is based on where the laucher is located, this i probaly not that benifical.
If we where to have something like this that probaly just have a seperate bash script that allways gives you the current and therefore up to date command based on the folder.

At least tgat is what i think right now.

That's an interesting standpoint.

We can also probably update (fetch, hard reset, pull) the repo (new script?), the real question is how to not make it ugly on the repo's files (too much scripts is not clear).

We can have all scripts in:

root like now, or.

A scripts folder

For example in the scripts we can have:

setup.bash → install.bash, to git clone and check/install dependencies.

update.bash to clean update (warning to user if unstashed diff with confirmation before action, then chmod wemod python script).

launch-command.bash to give only the current launch command.

wemod.bat I guess it makes sense to move all scripts in this folder. Maybe not.

Anyway, there are some questions here so I'll wait for an answer before changing things.

@marvin1099 ping ^^

I'm not comfortable with multiple scripts. It also shouldn't really be .bash, as that's not very conventional in Linux scripting.

If we're going to do multiple things, we should use getopt to parse the arguments to one script.

I am however OK with creating a folder of sourceable files for modularising functionality.

Ok.

I am however OK with creating a folder of sourceable files for modularising functionality.

I am not sure to follow, what do you mean by sourceable files ?

Removed the .bash extension:
d625508

@PonyLucky By sourceable files, I mean including shell files into the main script from a hidden directory.

Something like this: https://linuxcommand.org/lc3_man_pages/sourceh.html

I think it makes sense to make this PR a minimally viable product (MVP) implementation, and we can iterate upon it in future. Too much in one PR is hard to review.

We can, let me think of something

I tried this:
f30d99b

What do you think?

The only downside I see is that if the user doesn't have git installed it will fail right away if the repo already locally present.

shymega · 2026-02-24T23:29:45Z

This PR is currently a draft, but before being moved to ready, the commits should be squashed to two or less.

shymega · 2026-02-24T23:31:44Z

+# 1. Detects when `### Setup Automatically` starts
+# 2. Stops when `### Setup Manually` is reached
+# 3. Begins printing only after `#### Next`:
+awk '
+/^### Setup Automatically/ {in_auto=1; next}
+/^### Setup Manually/ {in_auto=0}
+in_auto && /^#### Next:/ {in_next=1}
+in_auto && in_next
+' readme.md
+


I think this isn't clear what the purpose of it is.

Do we need to do this? Why are we doing this?

Did this commit:
284b674

Does it fix it ?

I'm just not clear on why we need to extract content from the README.

It limits future edits of the README, and would likely be quite fragile due to the way Awk works.

Can we not hardcode this into the script, or an external file if we need to?

The idea was to have only one file to have all the info one would need. But I understand what you mean, later it could break easily.

As you said we can hardcode in the bash script or move in a separate .md file.

What are you the most confortable with for future use ?

I think maybe a USAGE.md file would be OK.

Done:
f723a30

shymega · 2026-02-24T23:32:53Z

+    read -rp "Enter installation path (leave empty to clone here): " install_path
+    if [ -z "$install_path" ]; then
+        echo "Cloning repository into current directory..."
+        git clone "$REPO_URL"


I think we should first clone into $XDG_CACHE_HOME, check everything's there, then move to the home directory. We could also use mktemp -d.

Network failures could happen, or disk I/O failures, meaning we want to do this in an ephemeral directory.

I didn't know you could do that this way. It's a first to me.

Does it work this way ?

create the tmp directory mkdir -p "$XDG_CACHE_HOME/wemod-launcher" ;

update the clone command to point this directory ;

verify the hash of the local repo with GitHub (i don't know how to do it if this is the right way) ;

if successful, move to intended path and cleanup cache ;

continue the rest of the script.

Yes, but you should use something like ${XDG_CACHE_HOME:-$HOME/.cache/wemod-launcher} to fallback if the XDG vars aren't defined.

But otherwise, yes.

shymega · 2026-03-03T00:41:50Z

@PonyLucky A significant change has been made to the codebase in terms of structure, so I rebased your branch against upstream.

Please run git pull origin dev --rebase on your dev branch, and you'll get my changes.

PonyLucky · 2026-03-03T00:44:59Z

@PonyLucky A significant change has been made to the codebase in terms of structure, so I rebased your branch against upstream.

Please run git pull origin dev --rebase on your dev branch, and you'll get my changes.

Thanks, I'll likely do that in 2 days, tomorrow I need to go to the capital for work.

Supports: - Arch-based OS (`pacman` only) - Fedora-based OS (`rpm-ostree` and `dnf`) - Debian-based OS (`apt` only)

Ask kindly the user to review the script before running instead of directly running something from internet.

`setup.bash` will now extract the content directly from the readme.

To follow convention

shymega · 2026-03-06T00:26:11Z

@PonyLucky I've mentioned your script in the Wand Discord, and there is some interest in a simpler way to setup this launcher. Just thought I'd let you know your efforts are appreciated! Thanks :D

PonyLucky · 2026-03-06T05:46:36Z

@PonyLucky I've mentioned your script in the Wand Discord, and there is some interest in a simpler way to setup this launcher. Just thought I'd let you know your efforts are appreciated! Thanks :D

Thank you for this message (and tool), this week I didn't have much time to spend. For personal reasons I had to take a lawyer, it's been quite tense...

I'll continue likely this weekend.

marvin1099 · 2026-03-07T23:01:23Z

Since we use the subfolder struture now this will have to move into a folder, may be just a folder called scripts or helpers.
Not fully shure on that one.
@shymega what would you say where we may move this to.

shymega · 2026-03-10T00:57:09Z

Since we use the subfolder struture now this will have to move into a folder, may be just a folder called scripts or helpers. Not fully shure on that one. @shymega what would you say where we may move this to.

A $REPO/.scripts folder probably works quite well.

marvin1099 · 2026-03-10T08:04:50Z

A $REPO/.scripts folder probably works quite well.

You prefer a hidden folder?
I would actually prefer a regular folder.
It not like the scripts should be hidden.
Why do you perfer a invisible folder?

There may be some usefull scripts later in the scripts folder.
Than i would rather not have it hidden.

setup script is now in the 'scripts' directory. The next steps are now in the USAGE.md instead of inside the readme.md, thus preventing potential extract fail.

shymega · 2026-03-15T21:16:56Z

A $REPO/.scripts folder probably works quite well.

You prefer a hidden folder? I would actually prefer a regular folder. It not like the scripts should be hidden. Why do you perfer a invisible folder?

There may be some usefull scripts later in the scripts folder. Than i would rather not have it hidden.

For sourcing installation scripts, I don't think it should be a visible folder.

PonyLucky · 2026-03-15T21:26:42Z

A $REPO/.scripts folder probably works quite well.

You prefer a hidden folder? I would actually prefer a regular folder. It not like the scripts should be hidden. Why do you perfer a invisible folder?

There may be some usefull scripts later in the scripts folder. Than i would rather not have it hidden.

For sourcing installation scripts, I don't think it should be a visible folder.

I pushed commits with a visible directory. Because you might want to run launch-command script more than once if you forget the actual command I think a visible directory is the best choice.

What I mean is that those scripts are sourcable but also meaningful as standalone. Thus justifying the visibility of the directory.

That is my point of view, I won't fight over it. I invite you both to debate and find what's the best for the project, I will do the change if needed.

Then there is the temporary directory side and I think we will have a strong feature ready to be squashed into one commit to the official repo.

shymega · 2026-03-15T21:40:59Z

A $REPO/.scripts folder probably works quite well.

You prefer a hidden folder? I would actually prefer a regular folder. It not like the scripts should be hidden. Why do you perfer a invisible folder?
There may be some usefull scripts later in the scripts folder. Than i would rather not have it hidden.

For sourcing installation scripts, I don't think it should be a visible folder.

I pushed commits with a visible directory. Because you might want to run launch-command script more than once if you forget the actual command I think a visible directory is the best choice.

What I mean is that those scripts are sourcable but also meaningful as standalone. Thus justifying the visibility of the directory.

That is my point of view, I won't fight over it. I invite you both to debate and find what's the best for the project, I will do the change if needed.

Then there is the temporary directory side and I think we will have a strong feature ready to be squashed into one commit to the official repo.

The reason I don't want the install scripts to be visible is because I can see users running them by mistake.

An alternative is that I create a new repo specifically for hosting scripts to install, and people download from there. That solution solves a lot of problems.

marvin1099 · 2026-03-15T21:59:38Z

The reason I don't want the install scripts to be visible is because I can see users running them by mistake.

An alternative is that I create a new repo specifically for hosting scripts to install, and people download from there. That solution solves a lot of problems.

Mabey print x allready istalled.
So theuser knows there is nothing to do with that file when it has already installed all the things, the script has checks for "if installed" already so adding that should should be minimal.

users running them by mistake is not realy that problematic, in that case (if script correctly checks for install).
It may waste some of thier time but since there are checks if stuff is installed the script should basicly finish in under a second and do nothing.

The thing is i do not mind if this script was to be hidden (via hidden folder) but if i (or others) ever add more scripts some of wich user may find usefull i would like the folder it to be visible. And a rename of that folder in the future, it just would not be that consistent, that is mostly why i prefer the visible folder aproach.

shymega · 2026-03-15T22:41:50Z

We could have a hidden folder called .install_scripts, and another visible folder called scripts. That sounds like a good compromise to me.

marvin1099 · 2026-03-15T22:51:56Z

We could have a hidden folder called .install_scripts, and another visible folder called scripts. That sounds like a good compromise to me.

Or just hide the script by renaming the install script to ".setup", then only that one file is hidden.
Plus that way we dont have as many root placed folders in the project and the file wont be run by acident, how about that?

shymega · 2026-03-15T22:53:58Z

Right, it's just that we're splitting the install script into sourceable modular files, so having it its own hidden directory is logical.

I'd just rather the sourceable files weren't visible to the user post-installation. I'm happy for the main entrypoint script however, to be visible.

marvin1099 · 2026-03-15T23:10:03Z

Right, it's just that we're splitting the install script into sourceable modular files, so having it its own hidden directory is logical.

I'd just rather the sourceable files weren't visible to the user post-installation. I'm happy for the main entrypoint script however, to be visible.

Now i think i get it, what you mean the subscripts (so basicly the install dependecys file).
The command generator file is actually usefull, the setup file for installing as well.
But the install-dependecy file is not supoced to be visible, is this what your thinking?

So you think place it in a hidden folder.

This commit only add 3 files, so i assume this is the gist, or did you mean it in a other way.

marvin1099 · 2026-03-31T20:50:52Z

@shymega would you explain what you have in mind, for sourceble files, just the one did i understand correctly or not?

marvin1099 · 2026-03-31T23:37:34Z

How do you feel about something like this then:

├── scripts/                          ← visible, user-facing
│   ├── setup                         ← entrypoint, users run this to install
│   └── launch-command                ← users can run this to get their launch command
└── .scripts/                         ← hidden, internal library files
    └── install-dependencies          ← sourced by setup

Or what do you have in mind.
I do see that launch-command is sourced but it can also be run.
That's why i thought it should be in scripts.
Might need some rethinking, depending on what you say.
We cold totaly link them as well have launch-command live in .scripts but link to scripts for the user.

Would also work to have a single script in scripts that runs what is requested via arguments, just a possibility, i like to know what you say

PonyLucky · 2026-04-01T08:25:00Z

How do you feel about something like this then:
├── scripts/                          ← visible, user-facing
│   ├── setup                         ← entrypoint, users run this to install
│   └── launch-command                ← users can run this to get their launch command
└── .scripts/                         ← hidden, internal library files
    └── install-dependencies          ← sourced by setup
Or what do you have in mind.
I do see that launch-command is sourced but it can also be run.
That's why i thought it should be in scripts.
Might need some rethinking, depending on what you say.
We cold totaly link them as well have launch-command live in .scripts but link to scripts for the user.

Would also work to have a single script in scripts that runs what is requested via arguments, just a possibility, i like to know what you say

I like this concept, plus the idea of a "main script" with arguments (optionally TUI) is good too.

As depending on the answer I would have to do different things, I'll wait until the debate result to one solution.

marvin1099 · 2026-04-10T21:46:47Z

@PonyLucky could you move your bash scripts to ".hidden-scripts" and lets have one new script in the "scripts" folder, will call it sothing like "w-script" that will just be a general script that can call the 2 main hidden scripts users may want to run.
Skip the tui for now, will get sothing basik for now.
Here is what im thinking, no arguments print steam command; -h for help; -i for auto-install (your script; the help should note that this is used only when you dont jet have the launcher).
Help shuld say "use no arguments to print the steam command".
Then we have in the readme that new script for autoinstall with argument -i.
Something like that.
I think that sounds pretty good and looks clean.
You can of course supest to do sothing a other way, same with @shymega .

shymega requested changes Feb 24, 2026

View reviewed changes

Comment thread readme.md Outdated

shymega requested review from marvin1099 and shymega February 24, 2026 00:22

marvin1099 reviewed Feb 24, 2026

View reviewed changes

Comment thread setup.bash Outdated

marvin1099 reviewed Feb 24, 2026

View reviewed changes

Comment thread setup.bash Outdated

shymega reviewed Feb 24, 2026

View reviewed changes

shymega force-pushed the dev branch from d625508 to 9ee0ff3 Compare March 3, 2026 00:40

louis added 8 commits March 6, 2026 00:25

feat: Bash script to setup automatically

68cf277

Supports: - Arch-based OS (`pacman` only) - Fedora-based OS (`rpm-ostree` and `dnf`) - Debian-based OS (`apt` only)

fix: WEMOD_DIR if we are already inside the project directory

9c9c3bb

fix: security risk in readme.md

db97c51

Ask kindly the user to review the script before running instead of directly running something from internet.

chore: TODO next text is now in readme.md

68fbe64

`setup.bash` will now extract the content directly from the readme.

fix: paths in script and readme.md

6db9990

chore: clearer comments

aca63b2

fix: path to overwrite launcher command

462596c

chore: removed extension of setup.bash file

96b9bdd

To follow convention

shymega force-pushed the dev branch from 9ee0ff3 to 96b9bdd Compare March 6, 2026 00:25

PonyLucky added 2 commits March 14, 2026 19:16

chore: move setup script + move 'next steps' to USAGE.md

f723a30

setup script is now in the 'scripts' directory. The next steps are now in the USAGE.md instead of inside the readme.md, thus preventing potential extract fail.

chore: sourceable scripts instead of one big script

f30d99b

marvin1099 added the final details PR mostly done, but awaiting final decisions for some minor details label Mar 31, 2026

marvin1099 added under development This feature/issue is under development right now and removed final details PR mostly done, but awaiting final decisions for some minor details labels Apr 30, 2026

marvin1099 added the pickup for v2 pickup or re-examine task or change in v2 label Jul 3, 2026

Uh oh!

Uh oh!

Conversation

PonyLucky commented Feb 24, 2026

Uh oh!

PonyLucky commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shymega left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

PonyLucky commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PonyLucky Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PonyLucky Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PonyLucky Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

shymega commented Feb 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PonyLucky Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shymega commented Mar 3, 2026

Uh oh!

PonyLucky commented Mar 3, 2026

Uh oh!

shymega commented Mar 6, 2026

Uh oh!

PonyLucky commented Mar 6, 2026

Uh oh!

marvin1099 commented Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shymega commented Mar 10, 2026

Uh oh!

marvin1099 commented Mar 10, 2026

Uh oh!

PonyLucky commented Feb 24, 2026 •

edited

Loading

PonyLucky commented Feb 24, 2026 •

edited

Loading

PonyLucky Feb 24, 2026 •

edited

Loading

PonyLucky Mar 14, 2026 •

edited

Loading

PonyLucky Mar 14, 2026 •

edited

Loading

PonyLucky Feb 25, 2026 •

edited

Loading

marvin1099 commented Mar 7, 2026 •

edited

Loading

marvin1099 commented Mar 15, 2026 •

edited

Loading

marvin1099 commented Mar 31, 2026 •

edited

Loading

PonyLucky commented Apr 1, 2026 •

edited

Loading

marvin1099 commented Apr 10, 2026 •

edited

Loading