Griefed/ServerPackCreator

[Bug]: Linux users have to specify full path to variables.txt

Closed this issue · 5 comments

What happened?

Some Linux users of our packs are reporting this problem recently
LunaPixelStudios/Medieval-MC#707
(Apologies that this specific issue doesn’t have many details - most reports have been on Discord)

The start.sh script isn’t able to locate variables.txt, even after ensuring the script is run from the same folder. Manually specifying the full path fixes the issue.

Oddly this issue has only been cropping up for the past few days separate from any pack updates, so it may be related to the OS or some other external change.

I figured I’d report this just in case it’s something to be fixed on your end, but most likely we will just put a note in our readme about it as the issue seems to be somewhat rare.

What did you expect to happen?

The start script should pull from the variables.txt without needing to specify the path, provided it’s in the same folder as the start script and the script is executed from that folder.

Version

4.2.1 in this report.

Relevant log output

No response

Anything else you would like to add?

No response

If you are using the webservice, in which browers did you encounter this bug?

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Heyoo,

thanks for the report. This does indeed sound like an OS-related thing and hopefully I'll be able to remedy the situation.

Could you provide the OS' on which the scripts fail to operate as expected? That would greatly help with testing things from my end.

Cheers
Griefed

The issue linked does have the OS listed - if I get more reports in the future I'll make sure to get that info and update you.

I've asked them to try the script using ./start.sh as well as bash start.sh as the scripts are bash-scripts, so running them with sh start.sh is likely to result in unexpected behavior.

The recent non-github reports have more specifically given the error message source: variables.txt not found, the issue I linked has a different error message.

However, checking back on those reports, it seems like in either case source not working is due to the user explicitly running the script with sh. So we probably just need to make a note about that in our readme.

Sorry for wasting your time with this one!

No worries 😄
All that matters is that we got this resolved.

Stay safe and stay awesome.
Cheers,
Griefed