Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with bin wrappers #295

Open
brendenhoffman opened this issue Jul 2, 2022 · 3 comments
Open

Issues with bin wrappers #295

brendenhoffman opened this issue Jul 2, 2022 · 3 comments

Comments

@brendenhoffman
Copy link

First off, I am typing this on a Steamdeck, so my writing may be a bit crude.

I had trouble getting the wrappers working, I figured it out and it could be zsh or dotfile related, but I figured I should share in case this is a compatibility issue.
export PATH="$PATH:~/.junest/usr/bin_wrappers" this did not work, showed up in path, but the shell couldnt find any commands. I noticed
export PATH=~/.local/share/junest/bin:$PATH converted to the full path when I checked with echo, but the wrappers dir did not. Due to some issue, maybe with the quotes, export PATH="$PATH:$HOME/.junest/usr/bin_wrappers" does work and also shows full path in echo.

Second issue, sort of. Junest works fine, but I dont understand the sandboxing. I noticed that executing /home/deck/.junest/bin/neofetch shows SteamOS and uses the configs in my home dir, but /home/deck/.junest/usr/bin_wrappers/neofetch or executing neofetch shows Arch and uses Junest configs. I guess I know its sandboxed, but is there a builtin way around that? I would like to use my main configs because junest is one of the only ways I can install things like neofetch or my zsh plugins without disabling read only mode.

@fsquillace
Copy link
Owner

Hi,

That's interesting. If I understand you correctly the ~ does not expand to be the actual path to home directory. I've never seen an issue like that. When you have a chance can you try doing that with bash instead of zsh?

Regarding the second issue. Running /home/deck/.junest/bin/neofetch means that you are directly running the executable (in this case neofetch is simply a bash script). So, you effectively are directly running the script from SteamOS (it does not have notion of JuNest environment at all). Obviously, this is not the way you normally would run programs installed inside JuNest.

You'd need to enter inside a JuNest session (simply run junest). In this way you will be able to run neofetch and, since JuNest bind the home directory your program will be able to see all your configs. The reason why neofecth shows Arch info is because it takes the JuNest info located in ~/.junest/etc/.

@brendenhoffman
Copy link
Author

Should files in .junest/bin come up if you run a program you have installed in junest, if it was not found in binwrappers? During my testing of the path variables, I could not run neofetch even though it existed in .junest/bin, unless I typed out the full path. The bin dir is first in my path, and if I understand correctly, this is where junest was first run from.

What would be the simplest way to run programs like neofetch or nvim as if they were a part of steamOS, like I were to run /home/deck/.junest/bin/neofetch?

@nihaals
Copy link

nihaals commented Nov 5, 2022

As far as I'm aware, ~ doesn't expand in double quotes, which is standard behaviour, but you can use $HOME or keep the ~ outside of the quotes:

$ echo ~/foo
/home/.../foo
$ echo "~/foo"
~/foo
$ echo ~/"foo"
/home/.../foo
$ echo "$HOME/foo"
/home/.../foo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants