Bug 12866

Summary:	should we be disabling bash executable path caching?
Product:	buildroot	Reporter:	Matt Weber <matthew.weber>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED INVALID
Severity:	normal	CC:	buildroot
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:

Description Matt Weber 2020-05-08 19:12:15 UTC

I'm not sure if there is a use case (yet), maybe with parallel builds if the host folder contents ends up with per package staging?

https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables/218681#218681

We ran into it when we were testing the internal toolchain of buildroot to be relocatable and the "mv" executable was used to rename the host folder.  Then we used "mv" again to rename the host folder back. For the first "mv" it used the Buildroot host/bin/mv and then for the second "mv", bash tried to again use the same instead of continuing to traverse to /bin/mv which was in the path and the output of "which mv" at that point in the script.

Comment 1 Thomas Petazzoni 2020-05-09 09:58:43 UTC

I don't quite follow what Buildroot can do here, i.e how would we disable this bash caching functionnality from the system-provided bash? I'm not even sure it makes sense for us to do this.

Comment 2 Matt Weber 2020-05-11 12:06:35 UTC

Thinking about it a little more, the actual shell script would need to set 'set +h' but my understanding is the executable hash table (for quick lookup after a commend is executed the first time) is just local to the current script's context.  So to cause an issue, you would have to call the same command twice in the same script and move the location of the executable without updating the PATH.  That doesn't sound normal.  I'll close this bug :-)