Open Stack

I think it will become more fragile because (despite over a decade of
trying to standardize these things), not all the distros put their binaries
in the same places -- for example, I have seen brctl live in /sbin,
/usr/sbin, and /usr/bin. It is much easier to sanity-check (or allow for
customization of) $PATH in one place (hi there Oslo devs!) and rely on
having a sane path everywhere else than to hardcode all the exernal binary
calls and have to deal with the inevitable bugs that will arise from
utilities living in different directories in different distros.  Of
os.execvp and friends randomly decide to stop using PATH (and only PATH) to
find executables we are in much deeper trouble anyways.


On Tue, May 14, 2013 at 8:04 AM, Stanislav Pugachev <
spugachev at griddynamics.com> wrote:

> Why do you think code will become more fragile? It will be more defended.
> How $PATH checking will help if someone will change the binary?
> And it is not so much work to do here.
>
>
> On Tue, May 14, 2013 at 3:36 PM, Victor Lowther <victor.lowther at gmail.com>wrote:
>
>> Err, sounds like a lot of work to make the code more fragile.  If you
>> want to be paranoid about launching the right command, do it by
>> sanity-checking $PATH, not by hardcoding the path of all the executables
>> you call.
>>
>>
>> On Tue, May 14, 2013 at 5:56 AM, Stanislav Pugachev <
>> spugachev at griddynamics.com> wrote:
>>
>>> Hi,
>>> I've added a blueprint
>>> https://blueprints.launchpad.net/hacking/+spec/absolute-paths-of-os-binaries
>>> Please, take a look and let's discuss it if it makes sense.
>>> Thank you
>>> Stas.
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130514/4c511609/attachment.html>