On Wednesday, 29 August 2018 19.10.31 WEST Kornel Benko wrote: > Quick look does not show a problem since we call perl executable explicitly > here.
Just like in python. > I had (erroneously?) the impression, that the use of 'env' is a more > portable way. So it is for me somehow surprising to see these warnings. > > Kornel Sometimes too much choice can be a problem. :-) The man page for env says: env - run a program in a modified environment https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my/29620 As the url that I sent before says: "A minor point: the #!/usr/bin/env trick is arguably an abuse of the env command, which was originally intended (as the name implies) to invoke a command with an altered environment." So we are using a side effect from a command to provide further choice. The general consensus was that the problem that we are trying to solve is not worth all the potential problems that come from that mechanism. There is something similar with rpms. It was possible to specify the root where the rpm would be installed. By default all rpms are installed in the file system root directory /. It is possible to specify another root to be appended to all files paths. Packages that work like this are called relocatable rpms. The Fedora rules are very clear about this: https://fedoraproject.org/wiki/Packaging:Guidelines#Relocatable_packages "The use of RPM's facility for generating relocatable packages is strongly discouraged. It is difficult to make work properly, impossible to use from the installer or from yum, and not generally necessary if other packaging guidelines are followed. However, in the unlikely event that you have a good reason to make a package relocatable, you MUST state this intent and reasoning in the request for package review." Conclusion: I do not remember to ever see a relocatable package in Fedora. There are more modern solutions, like containers, to solve this type of problems. I hope that this summarize what the problems are and why it is discouraged. Something else that should have been said is that gnu/linux has helped to normalize most of this and brought some sanity to the standard file system hierarchy. :-) -- José Abílio
