Comments on: How to check for a package/binary in a disk-friendly way? PackageKit — but how?

By: My computer allows the disk check utility to begin but then cancels the scan? | How To fix Registry

Sun, 09 Aug 2009 11:15:23 +0000

[...] How to check for a package/binary in a disk-friendly way … [...]

By: Tollef Fog Heen

Tollef Fog Heen — Sun, 09 Aug 2009 08:27:41 +0000

It sounds suboptimal to check this using packagekit. A user might well have compiled mc locally, or it might be in /usr/local for whatever reason.

By: Calvin Walton

Calvin Walton — Fri, 07 Aug 2009 21:47:55 +0000

One thing to note is that your shell has had in-memory caching of executables which are installed and where they are located for ages.
The first time you run “mc” in a shell, it’ll do the full synchronous PATH lookup, but every following time it will just immediately run the executable from the cached location.
There’s problems with the shell implementation – if you delete or move a program, you have to run “hash -r” (in bash) to reset the cache.
But still, it wouldn’t be that hard to make a simple shared path-lookup cache. Make it add monitors on the executables it finds, and it can invalidate itself.

By: How to check for a package/binary in a disk-friendly way … | paydayloan

Fri, 07 Aug 2009 19:42:58 +0000

[...] here to see the original: How to check for a package/binary in a disk-friendly way … Leave a [...]

By: Josh Stone

Josh Stone — Fri, 07 Aug 2009 15:56:51 +0000

> On the other hand, the $PATHs are not cached and monitored.

The kernel’s page cache will almost surely have the PATH contents in memory. Are you sure that g_find_program_in_path is your culprit? I would try hard-coding just that line to the mc on your system, to see if the spin-up delays go away.

By: djcb

djcb — Fri, 07 Aug 2009 15:19:53 +0000

it might also be side to have the program still in the menu (maybe greyed-out), and upon selection offer to install it.

but, the easiest solution may be to simply trigger a spin-up when you’re returning from suspend; at least easy enough to use before implementing something really smart. anything but checking for the binary in path is rather fragile, as are caches.

By: foo

foo — Fri, 07 Aug 2009 13:22:36 +0000

Obviously caching the return is a good idea, you should also listen for inotify and or PackageKit removal events in case mc gets uninstalled/reinstalled etc so that the UI is consistent with the filesystem state.

By: foo

foo — Fri, 07 Aug 2009 13:14:10 +0000

Package names are not standardised, but there is an effort to map between distros (see the Gentoo PackageMap Google Summer of Code project).

Anyway, just run the above method in a thread and add the mc menu item when the thread returns instead of blocking the UI. You can have mc installed, but not in your path in strange situations. Or have mc in your path but not installed (built from source) What matters is whether or not mc is in the path, not that an mc package is installed.

By: M Welinder

M Welinder — Fri, 07 Aug 2009 13:13:30 +0000

I don’t get it. Nautilus wants to know if it can execute the “mc” command.
(And, perhaps, if that “mc” is really midnight commander.) That is not a
question that packagekit can answer. If I install mc from a tarball then
packagekit won’t even know it.

g_find_program_in_path, on the other hand, can answer the question.

By: hron84

hron84 — Fri, 07 Aug 2009 12:21:25 +0000

@oliver:
mc is a console-based app, and i don’t think it has a desktop entry. But this is totally unrelated. The main question IMHO how can you find any binary in system.