-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I was talking about command line PNDs with Cloudef yesterday on IRC, and he pointed out some problems with this to me. But I still wondered whether it could be done and I've an other idea which might work:
How long does mounting a pnd take? Half a second, tops, I think. So shouldn't it be possible to
1)Scan all PNDs for a binary file or folder containing binaries which should go into PATH. This should probably be done with an entry in the PXML file and should happen at the same time when the desktop icons/menu entries are created. 2) Then make little scripts called like the binaries in an own folder in $PATH which do the following: 2.1) If the PND isn't already mounted: Mount the PNDs, for some limited amount of time (10seconds? Maybe more. Should be configurable). If the PND was already mounted by something else: Skip this step If the PND was mounted by this same system before; for use in the terminal: Extend the period of time it stays mounted 2.2) Launch the actual binaries from the PNDs.
This way, you could launch binaries in PNDs from the command line with a little delay, but if you have a script which calls the binary several times in a row, the delays won't sum up. In every case, it would be faster than searching the PND in a GUI and then launching a terminal this way. It would also make it possible to directly combine multiple programs from different PNDs on the command line. And there would probably never be more than a few PNDs mounted at the same time for that (that was one problem Cloudef pointed out to me, that there shouldn't be 500 PNDs mounted at the same time).
I've been told to just install this kind of apps with the opkg package manager, but that isn't really a good way to solve it: To do this with more than a few small utilities, you need to install the OS to an SD card. That isn't perfect because then you can't just change SD cards around like you want. In my opinion that's only a solution if in five to ten years the current Pandoras are mostly replaced with ones which have a really big internal storage.
Maybe there is also an other, better way to do this, but I think something like this should really be made.
On Sun, 3 Jun 2012, Lukas Bürgi wrote:
# 2.2) Launch the actual binaries from the PNDs.
Use pnd_run :)
(which runs an arbitrary item from the PXML from within a pnd; it does the mount, execute, and unmount.)
Extensions that could be useful to it..
-- allow it to run any named binary within the pnd, even those not in PXML?
If you want to magicly wrap them, so they just show up in the path automatically.. ie: akin to how .desktops are autogenerated.. could be done.
We've debated endlessly about shared libraries or general system extensions, though never moved on it .. ie: say you want extra locale's added, or dictionairies, or java runtime, or shared libraries, ... things you want to show up in random places imthe filesystem.. thats a very tricky problem, since it implies dependancies sometimes, or at least implies many mounts so that all these things can be present all the time.
But for just executable command line binaries.. I shoudl think they woudl be mentioned in the PXML and described by some PXML attribute as needing spitting into the system; then pndnotifyd when it does the .desktop generation could perhaps create something like /tmp/bin/ and fill it up full of wrapper scripts that just invoke pnd_run to fire off the given application.
Risk: It'd slow down the bootup/rescan a little for it to spit out all these little scripts .. ie: what if you have 200 command line proggies (not at all unimagable, with 2 or 3 pnds coudl easily be 500 of them..), it'd eat up some ram and boot speed. But certainly doable.
However, the apps can already be run by pnd_run .. the trick is the user doesn't know what apps they have :/
# This way, you could launch binaries in PNDs from the command line with # a little delay, but if you have a script which calls the binary several # times in a row, the delays won't sum up.
Caching, hmm!
# It would also make it possible to directly combine multiple programs # from different PNDs on the command line.
pnd_run.sh to mount them and away you go :)
(pnd_run and pnd_run.sh are different apps, though related)
Roll the discussion on, glad you brought it up again.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Actually, rather than many scripts, I bet a better way would be..
One script for each pnd-file; so 3 pnds offering CLI apps (whereby CLI apps are flagged in the PXML so it knows to do this) would make 3 wrapper scripts.
then in /tmp/bin (say, or whatever), pndnotifyd could create a pile of symlinks to the wrapper scripts; so there could be say 100 symlinks to a single script; when the script gets run, it checks $0 to find out what its called, and then invoke pnd_run for the pnd-file it was created with, and invoke it with the argument of the $0 ..
So therefore it wouldn't take too much RAM (just symlink space), and not _too bad_ to plop out .. but still a bit of a speed hit.
jeff
On Sun, 3 Jun 2012, skeezix wrote:
# On Sun, 3 Jun 2012, Lukas Bürgi wrote: # # # 2.2) Launch the actual binaries from the PNDs. # # Use pnd_run :) # # (which runs an arbitrary item from the PXML from within a pnd; it # does the mount, execute, and unmount.) # # Extensions that could be useful to it.. # # -- allow it to run any named binary within the pnd, even those not # in PXML? # # If you want to magicly wrap them, so they just show up in the path # automatically.. ie: akin to how .desktops are autogenerated.. could be # done. # # We've debated endlessly about shared libraries or general system # extensions, though never moved on it .. ie: say you want extra locale's # added, or dictionairies, or java runtime, or shared libraries, ... things # you want to show up in random places imthe filesystem.. thats a very # tricky problem, since it implies dependancies sometimes, or at least # implies many mounts so that all these things can be present all the time. # # But for just executable command line binaries.. I shoudl think # they woudl be mentioned in the PXML and described by some PXML attribute # as needing spitting into the system; then pndnotifyd when it does the # .desktop generation could perhaps create something like /tmp/bin/ and fill # it up full of wrapper scripts that just invoke pnd_run to fire off the # given application. # # Risk: It'd slow down the bootup/rescan a little for it to spit out # all these little scripts .. ie: what if you have 200 command line proggies # (not at all unimagable, with 2 or 3 pnds coudl easily be 500 of them..), # it'd eat up some ram and boot speed. But certainly doable. # # However, the apps can already be run by pnd_run .. the trick is # the user doesn't know what apps they have :/ # # # This way, you could launch binaries in PNDs from the command line with # # a little delay, but if you have a script which calls the binary several # # times in a row, the delays won't sum up. # # Caching, hmm! # # # # It would also make it possible to directly combine multiple programs # # from different PNDs on the command line. # # pnd_run.sh to mount them and away you go :) # # (pnd_run and pnd_run.sh are different apps, though related) # # Roll the discussion on, glad you brought it up again. # # jeff # # -- # If everyone would put barbecue sauce on their food, there would be no war.
-- If everyone would put barbecue sauce on their food, there would be no war.