On Wed, 2017-03-29 at 12:26 +0000, Nikolai Kondrashov wrote: > I would say using env in the shebang line is useful. Particularly for > portability. As a developer, I wouldn't like removing it from my programs. Portability is not an issue at all here in this exact discussed case because distribution resources as long as they are packaged into binary packages they are ALL *already ported resources*. You can provide 100% functional source code not depending on env and still able to produce resources to install with fixed location of <interpreter>. This is not the rocket science. > Moreover, if your PATH is compromised, you're most likely screwed. Still .. if $PATH will be compromised removing using env decreases risk here because removing using env attaches script to some fixed <interpreter> path. > I understand, that env use in scripts makes is inconvenient in some cases, > but I think that RPM build procedure and Fedora practices need to be fixed > instead. So instead decreasing generally entropy you are proposing increase it .. by introduce kind of JFDI :) > The number of packages using env in scripts alone shows that it is a > widespread and useful practice. This is not about practice. Generally using env comes from the time when when installing additional version of the <interpreter> was only civilised way fulfilling some needs without changing distribution resources. Second typical past scenario was when distribution not been providing <interpreter> and users have been installing it manually on top of distribution in non arbitrary locations. In other words always evn was more workaround than RightSolution(tm) and now it is part of the legacy which can be removed cleanly. Using env it is more *legacy badge* which needs to be dropped best in source code trees. Producing patches and submitting them to source code maintainers will help get rid those issues. If you will have look on those packages affected by env you will find that ~97-98% of all cases is related to prl and python. Committing today in source trees paths to those two interpreters as located in /usr/bin will not hurt portability of such code on other Unixes as they already provides exactly the same versions of those interpreters in the same locations as on typical Linux distributions. Getting rid of using env is much more legacy related things. Most of them comes from the the time when Solaris and other flavours of the Unixes where the dominant Unix on the market. There is much more such legacies still embedded in source trees which now can be dropped, Example: # dnf repoquery --whatrequires 'libnsl.so.1()(64bit)' \*.x86_64 | wc -l Last metadata expiration check: 1:19:13 ago on Wed Mar 29 12:36:31 2017 BST. 294 ATM in glibc libnsl provides almost only ABI/API used by NIS/YP/NIS+ NSS maps related binaries. On Solaris the same library contains some base network sockets functions. Of cource today using on Linux libnsl by some packages does not means that there are so many software is related to NIS/YP/NIS+ :) Many source trees maintainers which started own projects even recently coped base set of system detections where adding -lnsl to LIBS was present. All such issues should be not fixed by something similar to plastering .. kloczek PS. Just added first env fixing patch in proposed slang changes removing build and use (by test suite) slang static libraries https://bugzilla.redhat.com/show_bug.cgi?id=1436909 -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
