Unable to pass windows paths to custom commands #1072
Comments
|
What about a double backslash? I'll check when I'm back on my PC as well. For example, |
|
I don't know about this specific case, but sometimes Wine can handle forward-slashes (ModOrganizer 2 I think has some |
|
Double backslash appears to work for me, but has this problem:
Essentially when you save you go from
In the short-term though for a workaround, double-escaping each time you go to the Game Menu should work. Alternatively, forward-slashes may also work, it just depends on each program I think. It might be worth testing Proton 9.0 Beta, Proton Experimental, GE-Proton9, or anything else based on Wine 9 just to see. In the longer-term, we have some considerations about how better to handle custom command paths, such as those with spaces. |
yup that writes out the path correctly like you said above. though I having trouble getting it to atchually run , but don't know if that's just with reloded II.... |
|
Ah, there's a missing backslash in my example after If this still doesn't work, you can try pasting it manually into the game config file, and loading without touching the Game Menu, so STL will read it directly from the config file and there should be no risk of Yad mangling it. Hopefully if I can figure out some parameter expansion/sed to replace single backslashes, Yad will hopefully not mangle the path anymore, so this should be temporary and just for testing. I'm sure there's some sed -E regex for it if all else fails, but as they say, once you start using regex to solve a problem, you now have two problems. 😅 If this still doesn't work, you can try quadruple-escapes! Same again, just paste this into your game config and launch without touching the Game Menu: If both of these still don't work, you can once again try these in your config file, once again avoiding the Game Menu (Yad will always mangle these because it hates quotes for some reason):
If none of these work, it will be very sad times. Perhaps if they all fail you can try manually from terminal with Wine and see if passing the same command fails, that would help narrow down if it's an STL problem or not. I am foolishly optimistic that one of these will yield a result though 😉 |
|
Ah interesting, it seems like using Because this is a bug, I created a new branch to test the fix. For some reason, using You can check out the branch here and see if it fixes your backslash woes over at I don't know if Reloaded II will work, but this should at least fix the issue of the paths going from This won't fix paths with spaces, though, that one's another beast... |
|
Oh cool Ill give that a try when I get the chance rn I'm trying to troubleshoot why nothing loads when I try to run Reloaded II with P3R exe as a arg. for testing purposes I was able to get this to work as a separate steam shortcut by adding Reloaded II as a custom steam game then in the launch options adding this launches P3R with mods but I can't get this to work on the P3R steam entry with STL for some reason... BTW: I tried using forward slashes in the above steam launch option and it didn't work it need to be backslashes apparently looking at my log I see its running |
|
If you use quotes for the STL option, in the game config, does that work? If not, if you change your non-STL command to these, does it work?
This will help work out the following:
My guess is that 1 and 3 will work though. |
|
Did a bit of hardcoded logging in With this I can see each element in the I'm not sure why Reloaded II would be having troubles picking up the path. I may have to get it set up over the weekend for troubleshooting if we can't figure it out! |
|
hmm, intresting when adding those commands to my R2 steam shortcut (that's what I'm going to call the mod loader now lol) the following happens
quotes and everything because that's how it knows what mod profile to use (because that mod profile has or .... I'm tired I don't want to see another f*ck |
|
So if it's looking specifically for a mod profile with quotes in the name, does editing the Then try launching the game without touching the game menu (because Yad will mangle it), that is, just let the wait requester time out when you launch P3R. That should hopefully then show in your log that the launch args are
Mood, I will probably be heading to bed shortly and will pick this up tomorrow (probably gonna explore R2 myself because I am quite interested!)) Parsing with Yad is fun 🥴 |
Good idea don't want to add yad shanagiens into the mix lol
same lol. this prob isn't really even a stl bug per se (well other than yad stuff) so no worries if you want to prioritize something else. I prob be trying this a bit on my end to just cuz I'm ocd like that (prob would just be easier to use the r2 shortcut and then add stl as a compat tool for that or something) anyway if you do want to check r2 out I recommend using this guide https://gamebanana.com/tuts/17166 its written for the deck but can be adapted to desktop Linux fairly easily |
|
The escaped quotes (
This should be handy. Thanks! Let me know if you find anything out in the meantime. I'll keep this open as it is interesting, I wonder what is going wrong with the path being sent to R2. |
|
Random thought before falling asleep: What if you set the following as your launch options for Persona 3 Reload (not R2), still using STL as the compatibility tool: After doing this, go to the STL main menu and then check your log to see if it logs anything interesting for incoming commands from Steam. Likewise it might be interesting to check the Game Menu as this may be read in and displayed somewhere (although the Game Menu may mangle quotes). The purpose of this is: STL I believe has a facility to read launch commands coming in from Steam. So, this might give us some insight into what Steam "sees". Then again, this might be a sleep-deprived nonsense idea. Only one way to find out :-) I would experiment but my PC is off now. |
EDIT: to answer your question it appears like this so no hmm that gave me an idea to run my R2 shortcut in steamtinkerlaunch and see what happens... well it crashes but the log is somewhat interesting in that it seems STL is receiving the arguments mangled as you can see here |
|
Huh now that is interesting, because coincidentally, I just tried as well. I tried with regular P3R (don't have R2 installed) but the principle should be the same, even though the launch options of course won't do anything here, it's just to see what they look like. For P3R I set the launch command as exactly this: And in SteamTinkerLaunch, I can see:
So, I tried a Non-Steam Game just to see if the results were different, and they were not. I did a Ctrl+F for If the launch option is given without quotes, such as As an aside: There is a part of the SteamTinkerLaunch Game Menu UI that I thought was supposed to display the incoming launch options from Steam, that is, the ones we're passing here. I thought this was the "Game command arguments (Steam Launch Option) I am going to do some tests to see what Steam sees when it launches a game with launch options, to get some insight into any escaping it might do. |
|
Steam doesn't do any wrapping, its launch command is just this: Which is what, ideally, SteamTinkerLaunch would also pass. Let me see what it'll pass if I give some escaped quotes in the config file and launch without going to the game menu... If the launch command can use quotes and if that can resolve the problem, then probably we need a way to internally wrap paths from the Game Menu. Or, as another simpler solutiion, an option to pass a game's launch options to custom commands. Then we don't have to worry about Yad destroying the string. |
|
Oh interesting also, on the Main Menu, the launch option path not displayed properly.
This could probably be fixed with |
|
Hmm, I just discovered For now, maybe using this solely for display purposes is fine. It still won't display quotes for some reason, though. It will escape it internally, though: |
|
I'm going to look into this The path will probably have to be entered with a double-escape on the Game Menu, pending a branch that fixes this. I'll give example data if I get anywhere with this investigation path, no worries :-) |
|
nice!! I been trying to see exactly how steam sees the launch options for r2 shortcut. gets written out on the proton log as so that's what its supposed to look like when it gets launched correctly at least according to the proton log... running steam in a terminal and then running the R2 shortcut also gives this EDIT: interesting without the steam apparently passes which is why I need the actually works 👀 |
|
So the double escaping is required! Very interesting! That probably won't work with spaces though. Could you do the following?
With that branch, the custom command args passed looks like this:
Yup, this is what I suspected was causing for me, the path had backslashes in my STL log but for you was removing backslashes. This confirms it then :-) |
|
I GOT IT WORKING in the menu this wrote out to the config which I could of sworn I tried but it works!!! |
|
That is awesome news! Can you try the branch here and see if it also works? Change your CUSTOMCMD_ARGS to only use single backslashes before testing: https://github.com/sonic2kk/steamtinkerlaunch/tree/extProtonRun-printf-q
The config file will only store single backslashes, but when generating the custom command argument array, backslashes should be double-escaped. This should do the same as what you're doing manually. Also, the caveat to what you're doing is that going to the Game Menu and saving will result in the double-backslashes being removed, meaning they'd have to be re-entered each time. If the branch above works, then this won't be an issue :-) Finally, if all of this works, then the final bit we need is this branch: https://github.com/sonic2kk/steamtinkerlaunch/tree/customcmd-args-backslash-fix (be sure to remove This branch fixes the issue of the path becoming So with both of those branches together, assuming they work, we'll end up with this behaviour:
Which should allow you to get an out-of-box experience with R2 profile commands by just passing |
|
I just realised that's kinda a lot and you probably want to get stuck into actually playing, but I hope it makes sense 😅 Both in terms of what the branches do and why I want them tested. The ideal is that both of these branches will allow what you're doing manually to "just work" |
just tested this part seems to work fine (intrestingly it still mangles
no worries I want to see this through the whole way lol. I already know I'm prob not playing to much today (ah well so is the life of an eternal tinkerer 😅 ) |
Hell yeah! So it can be merged then.
Yup, plus it looks like Proton doesn't take this anyway (#1072 (comment)) from the Proton log arguments you provided. So assuming the branch that should contain the launch fix works, I think we are good! That branch should double-escape the single-backslashes in
If it's any consolation, your troubleshooting is super appreciated (and putting up with my rambly explanations 😅) |
|
PRs are up for each branch:
If both branches work for you, I will merge both of these PRs tonight. |
haha no worries it was your rambling that made me think "maybe I should look at how to command is supposed to look once its passed" lol #1074 works for me so that is all good I belive #1073 however only loads the mod manager without the game so looks like its not passing something correctly to R2 (but still better than before where it would just hang and do nothing) my guess from comparing my log from the successful run and this one is its the EDIT for reference this log had and this one had |
|
Hmm! Good catch. Yeah, I could see this being a problem. Maybe using |
|
There's a workaround with sed ( |
|
Okay, dear god, I came up with a bit of an abomination to handle spaces, and in the end we can stick with Basically, We have to break this into an array of strings to pass it to an executable. This is equivalent to the Proton log's The problem is, we use Steam doesn't have a problem with this, because it can handle quotes. Over here in STL, Even if you escape the paths yourself, So our problem is that paths with spaces are treated as separate arguments, meaning they can't be read. I think I have come up with a solution for this though, with a couple of caveats. If we assume
So, we can use a for loop to check the current and track the previous elements to see if the previous element has a backslash. If the previous element ended in a backslash, we can update the current array element to be This has the problem of the existing array that is being modified containing null strings, but we can workaround this by generating a new array based on this modified one, with null strings filtered out. We can do this in mapfile by The reason we can't have paths ending in a backslash, is that anything after the path would be assumed to be part of the path, since the previous element ended in a backlash. For example, The final caveat, and one that I would like to fix, is that this does not work for paths using forward slashes, so traditional unix paths will still be split. Anyway, here's the code snippet I've been testing with. It's a bit of a Pepsi-fuelled sleep-deprived nightmare, so bear with me: # Play around with this one, I've commented some other test strings
PROGARGS="--launch Z:\home\zany130 spaced\.local\share\Steam\steamapps\common\P3R\P3R\Binaries\Win64\P3R.exe" # Expected length: 2
#PROGARGS="--launch Z:\home\zany130\.local\share\Steam\steamapps\common\P3R\P3R\Binaries\Win64\P3R.exe" # Expected length: 2
# PROGARGS="--launch Z:\\home\\zany130\\ is\\ spaced\\.local\\share\\Steam\\steamapps\\common\\P3R\\P3R\\Binaries\\Win64\\P3R.exe MYVAR=1" # Expected length: 3
# Create initial args array
mapfile -d " " -t -O "${#RUNPROGARGS[@]}" RUNPROGARGS < <( printf "%q" "$PROGARGS" )
FINAL_RUNPROGARGS=()
for i in "${!RUNPROGARGS[@]}"; do
# Remove trailing backslash, i.e. turn `--launch\` into `--launch`
RUNPROGARGS[i]="${RUNPROGARGS[i]%\\}"
# If the last seen element in the array ended with a backslash, assume
# this is an incomplete path and join them
#
# This is not perfect as valid paths that just end with backslashes will not work,
# but we can document this on the wiki
#
# i.e. "Z:\this\is\a\path\ MY_VAR=2" will not work, but "Z:\this\is\a\path MY_VAR=2" will work
if [[ $LASTRUNPROGARG = *"\\" ]]; then
# Remove 'i-1' (previous element), because 'i' (current element) will contain 'i-1'
unset RUNPROGARGS[i-1]
RUNPROGARGS[i]="${LASTRUNPROGARG} ${RUNPROGARGS[i]}"
fi
LASTRUNPROGARG="${RUNPROGARGS[i]}"
done
# Generate new array with null strings removed.
mapfile -t -O "${#FINAL_RUNPROGARGS[@]}" FINAL_RUNPROGARGS < <( printf "%s\n" "${RUNPROGARGS[@]}" | grep -v "^$" )
# Print verification
echo "${FINAL_RUNPROGARGS[0]}"
echo "${FINAL_RUNPROGARGS[1]}"
# Print length to verify it is correct, i.e. a flag and a path with spaces should only have 2 elements
# since the path with spaces will only count as one element
echo "${#FINAL_RUNPROGARGS[@]}"I'm going to push this up to the branch but I will probably only minimally test this against STL tonight and will give it another looking over tomorrow. Wow, that was a journey lol. |
|
Sorry, I totally missed your note that #1074 seems to work. It works for me too, so I'll merge it as-is. That means I can rebase #1073 on it which will make testing a little easier. If issues come up we'll deal with them then :-) On that note, #1073 has the changes pushed. In my tests, the launch command looks good: With the newly pushed changes, hopefully #1073 now works for you. I've verified that the argument array should be correct, looking like this: If that above use-case works for you, then awesome! I will focus after that on taking a look at fixing spaced paths for paths with forward slashes. I may not get anywhere and if not, and the rest of the PR works, I will just merge it as-is. There is already a TODO to note that paths with forward slashes don't work yet. |
|
Okay, #1073 has been rebased. It is now ready for testing whenever you're able (could just No major hurry on testing or anything, just letting you know the changes are ready now. |
|
Yup it boots with just setting it seems if I save If I hit save when it comes back, it still renders correctly (before a save would overwrite the good path with a mangled one). However,if I make So it seems like the "fix" only prevents an already correctly saved path with Which is still an improvement 😅 |
|
Well this is still good news! The path saving issue is probably more related to #1074. Did you try with |
|
Hmm! Okay, I can reproduce the problem. Double-escaping on initial save will work, but when saving a path with single backslashes, it gets saved to the config like this: It seems something is wrong with saving elements which have backslashes still, but only the first time. |
|
So I have a suspicion that, wherever we're saving the updated elements into the config file, we're using CUSTOMCMD_ARGS="--launch Z:\home\zany130\testpath"
echo "${CUSTOMCMD_ARGS}" # Prints Z:\home\zany130 estpath
printf "%s\n" "${CUSTOMCMD_ARGS}" # Prints Z:\home\zany130\testpathI'll have to figure out where the saving magic happens, but I think this is a safe assumption to make that this is the problem. Changing to using EDIT: The part we're looking for is |
|
We may be able to edit the # Old command, expands escape sequences
sed -i "/^${CFGCAT}=/c$CFGCAT=\"$CFGVALUE\"" "$CFGFILE"
# Updated command, surrounds the variables in double quotes
# but keeps the sed syntax in single quotes.
sed -i '/^'"${CFGCAT}"'=/c\'"${CFGCAT}=\"$CFGVALUE\"" "$CFGFILE"This is changing a VERY core part of STL, though, and will need tested thoroughly. I also haven't ran this past ShellCheck yet, As this will need a lot of testing, as a workaround in the interim, double-escaping new strings before saving should resolve the problem. You shouldn't need to double-escape after that. After investigation, it sems the |
Related to #1072. Stop sed from expanding escape sequences in strings. This function is used to save config entry items, and sed is expanding any backslashes in these options. There should never really be a case where we want config entry values to be expanded in this way, and also this is causing problems in #1072 where Windows paths using backslashes are mangled on initial save. Modify the sed command to use single-quotes for sed-specific syntax, and double quotes for variables, so they won't get expanded. This modifies an EXTREMELY core part of STL, so it will need extensive testing before it can be merged.
|
Actually, I'm dumb, that doesn't work. The testing example I was using in my Bash shell spelled There may be an alternative solution though, if we just escape CFGVALUE="$( echo "$2" | sed 's/\\/\\\\/g' )"And then just use our existing sed command. This probably isn't fool-proof per-se, since this is all escaping, but should prevent problems if the user only enters valid paths. I.e. paths with single or double backslashes should work fine. If a user deliberately tries to break things, it'll probably be possible to make it fall apart. But the only thing they have to gain there is their own config file getting messed up 😅 |
|
There is a WIP PR up at #1076, it's still WIP though (it may be very broken so I don't recommend testing yet). I'll ping when there's more work done on it. Also, based on #1072 (comment), do you think #1073 can be merged? If so, I'll get that in and rebase #1076 against it so it gets the spaced launch option fix. EDIT: Yeah, #1076 does not work. It saves checkbox values as |
|
Okay, #1076 should be in a working state now. It should allow you to go from a blank However, before testing, please either:
I mangled mine by accident during testing 😅 With #1073 and #1076, if they both work, we should be out of the woods with this issue. #1076 in particular if it works should be good at more widely fixing issues saving values with backslashes. So this has been a very helpful issue, the scope of what it fixes extends beyond just custom commands! |
|
Yeah, I think #1073 can be merged. I have been using it since yesterday, and I have been able to boot P3R with my mods by first setting can you merge #1073 and then rebase #1076 on that? I'll then test #1076 if I can set the
no worries there I always backup my |
|
Testing #1076 now everything seems like its working as it should. I decided to delete (after backing up ofc) the P3R config file and see if I could set it all up from scratch... everything worked. I was able to set the custom command to the mod loader and then pass the arguments to launch P3R, and everything worked. I didn't have to escape or do anything like that. so seems like its working perfectly and I even haven't been able to find any regressions in writing the config file out so that's also good |
|
Awesome, thank you so much for testing that branch and all the others :-) I will do a bit more testing and if there are no issues I will merge it. If I encounter any problems from then on running on master we can revert the merge and re-visit this issue. Once #1076 is merged I will close this issue. I'll link the PR to this issue now so it can be done automatically on merge. |
System Information
Issue Description
Sometimes you may need to pass a windows path(meaning using
\instead of/) to a custom command (For example to load Persona 3 reloaded with mods from Reloaded II you would use--launch "Z:\home\zany130\.local\share\Steam\steamapps\common\P3R\P3R\Binaries\Win64\P3R.exe)however STL seems to store these paths incorrectly (For example
CUSTOMCMD_ARGS="--launch "Z:homezany130.localshareSteamsteamapps�mmonP3RP3RBinariesWin64P3R.exe""in my case)Logs
31337.log
The text was updated successfully, but these errors were encountered: