Use the full path of the binary when invoking scripts

[nishakm]

trafficstars

Describe the Feature Currently, tern will invoke exactly the commands in the base.yml file:

436 go:
437   pkg_format: 'go'
438   os_guess:
439     - 'None'
440   path:
441     - 'usr/local/go/bin'
442   names:
443     invoke:
444       1:
445         container:
446           - "go list -m all | tail -n +2 | cut -d ' ' -f 1"
447     delimiter: "\n"
448   versions:
449     invoke:
450       1:
451         container:
452           - "go list -m all | tail -n +2 | cut -d ' ' -f 2"

This assumes the path to the binary is available in the $PATH environment variable. If this is not set then the command will fail. To avoid this, how about using usr/local/go/bin/go rather than just go i.e., provide the full path to the binary.

Use Cases This issue usually comes up when building containers with no environment variables set or analyzing containers where environment variables may be set by an orchestrator.

Implementation Changes I think this can be implemented by just using os.path.join(command_lib['base']['binary']['path'], binary) when invoking the commands.

[nishakm]

@rnjudge what do you think?

[sayantani11]

@nishakm I was going through this issue, but will changing usr/local/go/bin/go have much of impact, because usually go and the former usually works same in my terminal🤔 Do you mean changing line 441 or (446 & 452)? For 446 & 452, guess the change will have some impact.

[nishakm]

@nishakm I was going through this issue, but will changing usr/local/go/bin/go have much of impact, because usually go and the former usually works same in my terminal🤔 Do you mean changing line 441 or (446 & 452)? For 446 & 452, guess the change will have some impact.

The general problem is that we have situations where we cannot set environment variables, so even if we can find go at usr/local/go/bin/go we can't just call go. I think the place to implement this is not in the yaml file but in the code. If @rnjudge is OK with this change I can show you where to make it.

[sayantani11]

@nishakm Oh super! That'll be best

[nishakm]

@rnjudge We spoke about this at length and I don't remember what issue we had hit upon regarding implementing this. Do you remember?