default PATH values doesn't include /usr/local prefix
We're running FusionInventory using cron, but as cron doesn't have any PATH variable by default, there's a line when running FusionInventory-Agent:
[debug] PATH is not set, using /sbin:/usr/sbin:/bin:/usr/bin as default
As FreeBSD is installing the software to /usr/local/bin & /usr/local/sbin by default, dmidecode doesn't work :-/
Probably there're two ways to fix the problem:
1) change the PATH variable to include same dirs in local
2) locate the binary before executing the command
#1 Updated by Guillaume Rousse about 5 years ago
- Assignee set to Guillaume Rousse
That's neither FreeBSD nor dmidecode specific: if you have binaries outside of PATH, they won't be usable by the agent.
The actual question is how much should the software be able to auto-configure itself when its execution environement is unproperly configured. I'd rather make the error message in the logs more explicit and more visible to allow concerned people to adapt their own environnement, rather than extending hardcoded minimal and affecting every users.
#5 Updated by Gonéri Le Bouder about 5 years ago
I disagree, there is no way to guess the correct PATH. For example, on a Solaris box, the PATH can be very complexe and will strongly depend on the sysadmin (e.g: GNU or Solaris tools).
Regarding your bug report, I agree /usr/local/bin and /usr/local/sbin should be add in this case.
#6 Updated by Guillaume Rousse about 5 years ago
I disagree extending those default hardcoded values just because it makes sense for some specific case. Sure, it doesn't realy hurt. But if tomorrow someone else uses the argument "my specific distribution uses /opt prefix by default, please add it to your minimal PATH value", what should we do ? This kind of issues should be handled either by final user, or by a environnement-specific distribution maintainer (for instance, the port maintainer), not at software level.
#8 Updated by Egor Morozov about 5 years ago
Actually, this is default FreeBSD environment. The problem FreeBSD port is outdated, my patches were approved several months ago, but still not commited. As it takes lots of time, probably that's simpler to include this to mainstream (as Linux also may have software installed software to /usr/local/).
#9 Updated by Gonéri Le Bouder about 5 years ago
The /bin, /usr/bin, and /usr/local/bin directories are typically included in most users' $PATH setting (although this varies from implementation to implementation). http://en.wikipedia.org/wiki/PATH_(variable)
If we push /bin and /usr/bin, I can hardly understand we exclude /usr/local/bin.
#10 Updated by Guillaume Rousse about 5 years ago
Using different prefix is also sometimes a way to distinguish between different version of the same software: development version of yet unpackaged software in /usr/local, for instance. That's purely an hypothesis, as denoted by sometimes adverb. But as a software developer, I don't think that's our job to make this kind of hypothesis, whereas we're targetting end users (sysadmins) supposedly able to take this kind of decision...
Come on, this minimal value exists for years. If that was really such a problem, why would be notified only now ?
#13 Updated by David Durieux about 5 years ago
All softwares installed by user in *BSD systems are installed in /usr/local/ to be separated with softwares installed by default when install the operating system.
If you use only /usr/, you say you use only Linux specification, so why not use only *BSD specification :p
That's why, is not found in /usr, try in /usr/local