On Sat, Apr 21, 2012 at 3:44 AM, Dan Stromberg <drsali...@gmail.com> wrote:
>
> On Thu, Apr 19, 2012 at 5:14 PM, Chris Angelico <ros...@gmail.com> wrote:
>>
>> The question then is whether to choose or auto-detect. Attempting to
>> auto-detect could be quite inefficient; imagine if you have to call on
>> ssh every couple of seconds, and something in $PATH is on a slow
>> network share (or on a floppy drive, if you still have one of those).
>> Yes, it's a poor choice of executable path, but it's perfectly legal,
>> and the detection could get pathologically expensive. At very least,
>> consider caching the result.
>
> The wrapper class for autodetecting could cache locations to speed things
> up.  bash does this normally (hence the "rehash" command), but probably not
> across distinct shell processes.

Sure, but I wouldn't rely on your shell caching for you, which is why
I suggested caching more locally. But it still means extra lookups.

> I'm not a big fan of hardcoding paths; they have a way of changing.  I
> prefer $PATH, or $PATH search that caches.

Nothing wrong with using $PATH, but when you have to search $PATH for
not one but potentially three or more executables, it multiplies out
your costs unnecessarily.

>> Heh. Point. But the detection technique does depend on 'ssh' being the
>> secure shell client and accepting parameters exactly like you're
>> looking for - imagine if the Haiku (or whatever) ssh client takes
>> slightly different params. How do you handle that with autodetection?
>
> True, that gets more complicated.
>
> For commands that look faintly similar but aren't really very similar, you'd
> probably have a less-generic wrapper class that gets a usage message from
> the ssh binary or something.  The generic one is just for the simple case.

This is sounding very much like a ./configure script and *not*
something you want to do every startup. Suddenly you need a reliable
detection method for your dependencies. I think it would be far
simpler to record a table of commands, one per platform, and have the
platform easily selectable. Which gets us right back to the
aforementioned dictionary.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to