I got it until I didn’t.
I got it until I didn’t.
I focus on bash only, using just the standard tools present on every Nix system without hesitation. Storing variables in a .sh file in expanded form seems like the best approach from here. The folder layout is dynamic in certain aspects. At its core, it’s a Btrfs subvolume that can be mounted anywhere on the machine. For example, two users could mount the same subvolume in their HOME or /run/media/$USER directories without issues. If I had configured an init.sh and settings.sh system with symlinks, the final init.sh would execute directly, pointing to the correct variables.
If I set up a chain of scripts—init.sh, settings.sh, and finally another init.sh—I’d have a layered structure. The first script would run via a symlink, writing variables into settings.sh, which then echoes the full path. This way, only the last script gets executed directly as a symlink, while the chain descends step by step.
In practice, the settings.sh file would contain the finalized variables. I’m trying to understand how to access these values without errors, especially since syntax highlighting isn’t showing anything and the script doesn’t output empty results. It feels like the logic is working but I’m not sure how to verify it correctly.
You are calling the settings.sh script from within a specific directory, likely a configuration or setup file location.
To be honest there is a lot to unpack here and I'm not confident I understand what you're trying to do but this is likely where the issues lies. A shell script runs in a child shell process, and only children of the child shell would inherit the export. It looks like your end desire is to have paths available from settings.sh yes?? I think this is your desired result??? If you don't need $testing or $_voodoo available after they've run then just change the invocation to ./IWantVars.sh instead of . IWantVars.sh and change the init to be more like below as there would no longer be a need to localize variables since they'd all be dumped after running ./IWantVars.sh regardless: #!/usr/bin/env sh _voodoo="home/notreal/" testing=$_voodoo"bin" I'm still not really sure what you want to do with the vars so clarify what your desired end result is.. hopefully this points you in the right direction though. GLHV.
I cannot access the folder directly, but based on your request, here’s what you should do:
Run the command in the directory containing `init.conf`:
```bash
ls -l init.conf && head -1 init.conf
```
Expected output (example):
```
-rw-r--r-- 1 user user 1234 Jan 1 10:00 init.conf
```
Let me know if you need further assistance.
The script processes the content of an initialized file. It checks for the presence of a specified file and executes it if found. The approach ensures compatibility across different shells by adjusting the shebang and handling paths correctly.
Sh can be sensitive about paths, which might be a concern worth examining. You noted the source remains consistent, though this was true in bash earlier. Source isn’t available in sh, but you can use it if you need compatibility. Manual Bourne Shell V7 $ [ -f /home/lurkandloiter/bin/init.sh ] && echo $? finds init.sh 0. Then check: $ echo $HOME /home/lurkandloiter [ -f $HOME/bin/init.sh ]; echo $? gives 0. Still, it locates init.sh 0. You can run: $ [ -f ~/bin/init.sh ]; echo $? which also returns 0. Source ~/bin/IWantVars.sh is found and runs without issues. Sh won’t use source unless you explicitly call it. $ source ~/bin/IWantVars.sh fails because source isn’t found. Try running it directly instead of sourcing. This should help you understand the behavior better.
not what you expected, I realize I missed adding the x but I meant something about how it runs. The issue with init.conf seems fine, and sourcing shouldn't cause problems. However, I'm unsure what this means for the $(./init) command if it returns permission denied—it won't raise an error, just log the issue in CFG. The rule afterward doesn't matter because the config doesn't store files.