Skip to main content
added 318 characters in body
Source Link
Wildcard
  • 37.5k
  • 30
  • 149
  • 284

Without using eval you can still do this via process substitution if you're using bash or similar:

source <(source "/path/to/file" ; printf %s\\n "depends=${depends[*]}" "makedepends=${makedepends[*]}")

This starts a subshell and sources the file, just like your initial example, but then instead of directly printing the value and using command substitution, it prints the value formatted as an assignment and sources the output using process substitution.

This exactly answers the following part of your question:

Is there another way which involves to start just a SINGLE subshell, source the file and get the contents of specified variables of the file assigned to specified variables in the calling shell without polluting the environment of the calling shell?

But of course the dangers of sourcing foreign scripts still apply. Don't source an untrusted script, ever.

If you wrote the dangers of sourcing foreign scripts still applyscript yourself and you are absolutely sure it has no side effects (and produces no output) then you could use the above for your own personal computer. It's not something that should ever be in a production script. Very very big security hole.

Without using eval you can still do this via process substitution if you're using bash or similar:

source <(source "/path/to/file" ; printf %s\\n "depends=${depends[*]}" "makedepends=${makedepends[*]}")

This starts a subshell and sources the file, just like your initial example, but then instead of directly printing the value and using command substitution, it prints the value formatted as an assignment and sources the output using process substitution.

This exactly answers the following part of your question:

Is there another way which involves to start just a SINGLE subshell, source the file and get the contents of specified variables of the file assigned to specified variables in the calling shell without polluting the environment of the calling shell?

But of course the dangers of sourcing foreign scripts still apply.

Without using eval you can still do this via process substitution if you're using bash or similar:

source <(source "/path/to/file" ; printf %s\\n "depends=${depends[*]}" "makedepends=${makedepends[*]}")

This starts a subshell and sources the file, just like your initial example, but then instead of directly printing the value and using command substitution, it prints the value formatted as an assignment and sources the output using process substitution.

This exactly answers the following part of your question:

Is there another way which involves to start just a SINGLE subshell, source the file and get the contents of specified variables of the file assigned to specified variables in the calling shell without polluting the environment of the calling shell?

But of course the dangers of sourcing foreign scripts still apply. Don't source an untrusted script, ever.

If you wrote the script yourself and you are absolutely sure it has no side effects (and produces no output) then you could use the above for your own personal computer. It's not something that should ever be in a production script. Very very big security hole.

Source Link
Wildcard
  • 37.5k
  • 30
  • 149
  • 284

Without using eval you can still do this via process substitution if you're using bash or similar:

source <(source "/path/to/file" ; printf %s\\n "depends=${depends[*]}" "makedepends=${makedepends[*]}")

This starts a subshell and sources the file, just like your initial example, but then instead of directly printing the value and using command substitution, it prints the value formatted as an assignment and sources the output using process substitution.

This exactly answers the following part of your question:

Is there another way which involves to start just a SINGLE subshell, source the file and get the contents of specified variables of the file assigned to specified variables in the calling shell without polluting the environment of the calling shell?

But of course the dangers of sourcing foreign scripts still apply.