[PR #2164] [MERGED] Used THIS_SCRIPT variable within wget to allow execution from any dir. #3854

Closed
opened 2026-03-14 07:42:37 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/amidaware/tacticalrmm/pull/2164
Author: @nativeit
Created: 3/7/2025
Status: Merged
Merged: 4/11/2025
Merged by: @wh1te909

Base: developHead: develop


📝 Commits (1)

  • b98fe31 Used THIS_SCRIPT variable within wget to allow execution from any directory.

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 update.sh (+1 -1)

📄 Description

This is a very, very small change to the update.sh script that fixes an issue I originally referenced with #2162 where execution of the script from another directory (using a path like ./scripts/update.sh) results in the script getting stuck in a loop when it needs an update. I looked into it, and found that was because the updated script was being saved in the shell's current directory, rather than overwriting the original script in its original location (so when the process starts over, it still has an out-of-date script, thus endless loop).

Since there is a variable used in the next command ($THIS_SCRIPT) that defines the full path and filename of the update script, I replaced the output flag in wget from -o update.sh to -o "${THIS_SCRIPT}" and it makes the update script function more narrowly defined, and safer than it is currently.

I realize it's taken longer to read this than it did to make the change itself, so I'll not waste any more of your time. If you feel this was worthwhile, thanks for accepting my PR. If not, I will presume you have your reasons, no worries. Keep up the great work.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/amidaware/tacticalrmm/pull/2164 **Author:** [@nativeit](https://github.com/nativeit) **Created:** 3/7/2025 **Status:** ✅ Merged **Merged:** 4/11/2025 **Merged by:** [@wh1te909](https://github.com/wh1te909) **Base:** `develop` ← **Head:** `develop` --- ### 📝 Commits (1) - [`b98fe31`](https://github.com/amidaware/tacticalrmm/commit/b98fe31fe795b8de1b54c3e212cb75a20d968b64) Used THIS_SCRIPT variable within wget to allow execution from any directory. ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `update.sh` (+1 -1) </details> ### 📄 Description This is a very, very small change to the `update.sh` script that fixes an issue I originally referenced with #2162 where execution of the script from another directory (using a path like `./scripts/update.sh`) results in the script getting stuck in a loop when it needs an update. I looked into it, and found that was because the updated script was being saved in the shell's current directory, rather than overwriting the original script in its original location (so when the process starts over, it still has an out-of-date script, thus endless loop). Since there is a variable used in the next command (`$THIS_SCRIPT`) that defines the full path and filename of the update script, I replaced the output flag in `wget` from `-o update.sh` to `-o "${THIS_SCRIPT}"` and it makes the update script function more narrowly defined, and safer than it is currently. I realize it's taken longer to read this than it did to make the change itself, so I'll not waste any more of your time. If you feel this was worthwhile, thanks for accepting my PR. If not, I will presume you have your reasons, no worries. Keep up the great work. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-03-14 07:42:37 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#3854
No description provided.