OpenPandora Main OS

AFAIK, this isnm't part of the firmware; someone else wrote this up.. talk to them to get it fixed :)

Alright. A definition of "Firmware" would be in order, then. The script came with my Pandora and is part of the root image I put on an SD card as far as I can see. Where would Firmware begin and where end?

okay, that sounds pretty firmwarey; your'e sure its not part of one the pnds you've run, and installed it? We've always included pnd_run, but I recall someone else was working on a run_pnd.sh that would scan working dirs for pnd files and run them, by name, to make it feel more commandliney; I didn't think they made it into firmware, but I'm not as on top of it as I used to be.. I'll have to check; maybe ED or notaz or sebt3 or someone slipped it in :) But if its part of firmware, we'll check it.. I'll have to find out who wrote it and give them a slap; wasn't me :) jeff

@Jeff the "external" scrip is still external (named pqr, dont ask me why :D). But here I think he is talking about pnd_run.sh (and not run_pnd.sh) I'll test that.

... oh I just realized I wrote run_pnd.sh in my first posting. My bad. Sorry about the mess. I was in fact talking about /usr/pandora/scripts/pnd_run.sh. Timestamp is the same as pnd_hup.sh and pnd_make.sh. I'm rather positive I never knowingly installed it and found it there on both OSes I'm using.

Corrected that filename typo to "pnd_run.sh" in the submission as intended by the submitter "bukkit".

Curious .. so assuming we're talking pnd_run, it works like this.. pnd_run.sh is a convenience wrapper to invoke pnd_run (binary); pnd_run binary in turn pulls up the pnd-file and does a normal 'discovery' on it, and runs it; this is how minimenu used to do it, and should work very well. ie: pnd_run binary includes this bit: if ( app -> appdata_dirname ) { argv [ f++ ] = "-b"; argv [ f++ ] = app -> appdata_dirname; } else { argv [ f++ ] = "-b"; argv [ f++ ] = app -> unique_id; } So it should be supplying the appdata preferred name, unless it is not present. The pnd discovery code in question should be the same code as used by pndnotifyd, and as such is pretty heavily teste.d *hmrf* I've not had time to confirm (screaming babies here :), anyone confirmn pnd_run _binary_ is working/not-working? Could i tbe old versions of the pnds, that in fact _do not_ have appdata's in them? Try opening up the pnd's in question in an editor on your desktop, and jump to the end and back a bit to see the PXML, and see if you can see the 'appdata' reference.. or mail the pnd-files to me (skeezix@skeleton.org) and I'll see :) did you get fresh copies from a repo, or from sebt3's page? jeff

I'll see if I can confirm tomorrow; if someone can confirm earlier, all good :) If theres a problem, I'll fix it for sure, so no need to jump on it.

Tried to attach the respective PXML.xml, Button showed no reaction. So I reproduce the respective contents here: In both cases, a directory /media//pandora/appdata/ gets created and used. (I realized when I changed the run scripts and placed them in the "normal" appdata dirs, and those weren't used.) Both applications are to my knowledge by http://repo.openpandora.org/ resp. apps.openpandora.org. Vlc at some time was updated via the PNDstore to version 1.1.7.1. Your proposal to look at the end of the file however showed something interesting: Both pnds don't seem to have the attached PXML.xml. (My excerpt is from the *included* one.) I tried to verify with freshly downloaded files, however, Dosbox74.pnd wasn't available (could have been from apps.openpandora.org, which is down). I was able to download a fresh copy of this vlc: http://repo.openpandora.org/?page=detail&app=vlc and couldn't find the attached PXML.xml there, either (assuming I could easily identify the xml with a decent text editor). But I also can't open this pnd with a zip program, so it's not identical to the pnd I used last (from PNDstore, see above, but I used several vlc.pnds with different app-ids with the same result.) I'll send both last used pnds to skeezix. So (given I may never have used a correct pnd with attached xml) it *could* be (don't want to jump to conclusions, this is just a preliminary theory) that the app-id directory is used if there is no attached PXML.xml. This would still bear questions, like: Why is the included PXML.xml heeded by the ordinary pnd startup (I verified this), and why does the -d switch bear no result (I used '-d "pandora/appdata/dosbox"' like the docs suggest and '-d "dosbox"' for good measure and equivalence to the xml param).

Bukkit: "Tried to attach a file, but Button showed no reaction". Already reported this half a year ago in  FS#271 . Nothing was done about it! Will write a new comment over there. You can read/join the discussion over there, if you like.

IF there is no PXML, it wont' be an app at all (ie: where woudl it find the app id :) -- recall that the appending order is PXML and then icon; if its a large icon, you may have to scroll back a bit, depending how your editor works. The pnd discovery process looks for files with a certain name (*pnd), then scans back until it finds PXML (or goes too far back .. its not going to scan a 20GB file for an hour looking for the PXML chunk.) Mind you, if the PXML is not appended, but is within, and its an uncompressed archive (you can do this with zip), it may actually find the contained PXML and still work.. but thats a rare case :) I'll check a bit later, tied up much of today

Ah. The failings of a noob. Forgot the icon. Armed with that info, I managed to find the PXML.xml lines in Dosbox74.pnd: With vlc.pnd, no such dice. So the theory about the missing attached PXML.xml seems to be falsified.

I see no problems -- with pnd_run binary (which in turn invokes pnd_run.sh to do the actual run) .. no problem (which makes sense, since it doesnm't really determine anything.) pnd_run.sh is run by pnd_run though, and the directories are created fine .. running Dosbox.pnd creates 'dosbox' and not 'pickle.dosbox'. pnd_run knows how to invoke pnd_run.sh via libpnd. I'm assuming user is forgetting the -b option to specify the data path? It is not -d as in title pnd_run.sh is basiocly the foundation upon which the entire pnd system stands, so hopefully it is working right ;)

Want me to close, or you'll close ticket?

dont close that ticket : there is indeed an issue here : the -d switch is ignored. I dont get why just yet as the code seems good

Ah, libpnd doesn't bother with -d, and the default is to use the provided -b or whatever. Is -d needed? I suppose if you want to redirect the overlay point to somewhere else for testing or the like ..

If Jeff is right, the wiki ( http://pandorawiki.org/Pnd_run.sh ) is wrong. There the -b is described as being for the pnd-id (which should correspond to the app-id from the PXML.xml) and -d is for the overlay directory in appdata. The results imply in fact the pnd-id (which I specified accordingly with the -b switch) is used for the appdata directory. (In this case I'd kind of miss a switch to decide which app (from the multiple apps possible to be present in a pnd) should be run.)

The wiki corresponds with the usage pnd_run.sh claims. -b pndid : name of the (unison) directory mount-point, default is name of the pnd file (this should correspond to the id from PXML.xml) and -d path : Use path as source of the overlay (default: pandora/appdata/pndid) (this should be equivalent to the appdata directive from PXML.xml). Therefore, if the -b input ended up as determining the source of the overlay (which is what happens) that would only be the correct behaviour if neither the PXML.xml would specify an appdata nor command line a directory via -d. If either is true, the behaviour would, if I'm not mistaken, be wrong.

libpnd will only accept an application if it has a unique-id; an appdata is preferred, but in its absence, the unique-id will be used. As such, libpnd will only ever invoke pnd_run.sh with -b and the unique-id or appdata-name, as appropriate. -d is 'new' (since sebt3's took over maintenance of pnd_run.sh), and libpnd's behaviour hasn't been touched to include -d (and shouldn't need to.) So -d looks like a added feature, but that wasn't tested quite right, but works fine for all normal uses. (Sebt3 has a quite extensive test script for pnd_run.sh, but theres a _lot_ of cases :)

That means I should (since the package id is absent in the PXMLxmls I ran into and the application id seems to be used for sth different) use the filename for the -b parameter and leave the other options empty to emulate the normal pnd run... That is ... possible, but then pnd_run.sh would lack the option to specify which app to run in a multi-app-pnd (like Dosbox). This, btw, is the Dosbox pnd I was using: http://apps.openpandora.org/cgi-bin/viewapp.pl?/Emulator/Dosbox.inf This contains two applications, dosbox and dboxfe. When I run it normally, the application id (probably) decides which app I run (and the appdata directory is pandora/appdata/dosbox, like the PXML.xml demands). When I run it with pnd_run.sh, I must somehow specify which application of the two I run, and I did that via specifying the application id with -b. But when I do that, the appdata directory changes. So I'm either unable to specify the app to run (when I use the -b switch to determine the appdata directory) or unable to determine the appdata directory (when I use the -b switch to specify the application to run) via pnd_run.sh ... but the normal run, done via clicking on the app in the menu, must be able to specify both...

I'm confused.. what are you trying to do here? Obviously pnd_run.sh can run apps within a multi-app pnd, since pnd_run.sh is what the entire system uses to do exactly that :) pnd_run.sh is not a convenience layer, it is the actual pnd mount/run system; libpnd (including the daemons and other services) exist to itemize pnds and make .desktops and such, and invoke pnd_run.sh to launch app. If you check the .desktop files, they invoke pnd_run.sh :) So -b is used to specify the desired directory name in /pandora/appdata by libpnd, always has; the use of -b has expanded since its original goal, but thats whats its for. -b _shoudl not_ specify the filename; it should specify the preferred appdata name, or failing that, the unique-id; nothing else. Anything else is incorrect. (it will work, of course, but you end up splitting user data away from the canonicle location; if thats what you want, good :) For Dosbox, theres two subapps; each has a unique-id (different ones), but they list the same preferred appdata name; So -b would be the same for both apps, but the executable selected will be difference; that is how multiple apps are invoked. ... I lack context; is there a forum post or somethign that fills us in whats the real goal, and the problem are? (perhaps I missed it :)

also note.. "package id" is 'new'; the whole package layer is relatively new in PXML terms (added to help with the repo); libpnd's app execution _does not_ care about package at all in fact.. its used outside of the system for the most part. The package-id is not used for appdata naming or the like. Take a look at the .desktop files to get an idea what happens, they will show you exactly what the pnd_run.sh command line looks like for a normal invocation. Also note there are other tricks, like the auto-generated 'info/help' .desktops and such. A pnd_run.sh invocation will look like: .....pnd_run.sh -p "/meda/foo/pandora/menu/Dosbox.pnd" -e "rundosbox.sh" -b "dosbox" -- something like that The -e part will change to select a different subapp; the -b stays the same, since you want it to run _in the same place_. If you wanted 2 subapps to run in different data spaces, they could each have their own appdata which would change the -b, but thats not typical.

Alright, I think I see. Maybe. But I'd claim this confusion is not my fault. I'll summarize: You say: -b is used to specify the desired directory in /pandora/appdata pnd_run.sh says: -d is used to specify the directory in /pandora/appdata (You say: -d isn't evaluated) pnd_run.sh says: -b pndid : name of the (unison) directory mount-point, default is name of the pnd file you say: -b should specify the preferred appdata name, or failing that, the unique-id, and *not* the file name But no other doc, wiki or text states -b should specify the appdata name... and hardly anything says what this unique id is (it's faulty to use the application id, like I did, you say, which is named the uniqueID in the PXML.xml doc and which the wiki (http://pandorawiki.org/Pnd_run.sh) refers to as PND ID, and states should be passed as -b param... just like pnd_run.sh, like so: "-b pndid") ... So maybe this ended up being a very wrong and confusing documentation inside and outside of pnd_run.sh. Possible. I'll give it a try. Tomorrow.

I agree; the pnd_run.sh command line help isn't as ... helpful as it could be. The unique-id and such is more described here: http://pandorawiki.org/Libpnd_hub which leads to http://pandorawiki.org/PXML_specification A user shouldn't generally have to consult such levels of documentation however :) This is all due to history and changes over time, but yeah, the command line args coudl be much better explained. -b is the appdata or unique-id name -d is an override IIRC; without it, -d is implied to be /pandora/appdata/THING (as specified by -b) with -d, you could specify -b as 'foo', but then override it and say -d /pandora/appdata/something-else if you really wanted to. sebt3 -- you want to updat ethe command line docs to be more usable, or you want me to maybe recommend some wording? Is there actually a -d bug, then maybe you can look into it (or we can remove -d, since I imagine few if anyone use it :O) jeff

I actually did consult the PXML specification there, and that contributed to my errors, I'm afraid. Yes, it mentions the unique ID (as a placeholder in package id *and* application id), but in fact first the appdata entry gets extracted and fed as pndid to pnd_run.sh via -b, the unique id only being used if appdata was absent. According to the c source above, this seems to correctly describe the behaviour. I should be able to amend the wiki (about pnd_run.sh) a bit, too. If I do, maybe one of you guys should check if that comes out acceptable.

wording for the help would be welcome. And as it sound like you forgot, the -d option was a request from the case designer you forwarded to me. As I have eard anything from him since a while, I guess nobody use that anyway

I changed the wording at http://pandorawiki.org/Pnd_run.sh#Creating_a_launch_script_for_PND. I'd like you to have a look and amend, if necessary.

Very good :) I hereby put you in charge of reviewing the wikis to audit for usability :)

What have I done to deserve this. :) Thank you. I'll try.