can't change $PATH variable via script

[KAD]

[recliq]

setting the PATH inside the script works, but it will never get out there, the script can't change the PATH variable in the shell that called the script.
Have a look at the scripts in current WDLXTV, they write the PATH variable to /tmp/sys.path:

That file should be sourced by the shell:

and that's why it's mentioned to source that file after loading apps with app-plugman-web:

[KAD]

[KAD]

[recliq]

[KAD]

of coarse your right again, opt.bin was mounted to /opt

my concearn with that originally, was that there are already binaries the WD requires located at /opt/bin/...

so how does the WD run correctly without access to those binaries, for live, all I see is a few dbus binaries
maybe those are only used at boot

but in the case of SMP there's /opt/bin/... /opt/lib/... and a ton of other stuff
/opt directory on SMP contains the qt web browser and all the plugins, and tons of other libraries and binaries

as I'm writing this maybe the work around, is to include that entire directory tree of binaries and libs in opt.bin , mount bind it to /opt and allow ipkg to install standard directories

[recliq]

Oh if /opt is used on SMP I wouldn't combine the existing tree with optware (with eg. unionfs) chances are high that optware will overwrite something from SMP which might cause troube if different versions get mixed up.
I'm no expert on optware... I'd try to ask b-rad.

[KAD]

yeah it would be nice if b-rad was around

I think something is wrong with the ipkg binary, or at least not compatible, etc ...

I ran a test using mount -o bind

and now have a working version of entware
if your unfamiliar with entware
https://github.com/Entware/entware
and available packages here http://entware.wl500g.info/binaries/entware/Packages.html

but yes, I agree this could be potentially dangerous if entware overwrites some existing binary or library

so far, I've only installed vim, really just to test if it works
and it install the needed binaries and libraries, and they run on the SMP just fine
but yes all dependancies install to /opt/lib and none of them previously existed

[KAD]

in other news app.bin support is done

I'm actually considering putting out a beta firmware
needs more testing before public release, too many changes

but one thing I have yet to decide is if I should enable download of app.bin's from webend, listed as incompatible device

so far I've only found 1 app.bin that works as is, with no changes
although, I've only tested about 4 -5
and then there's another 4 -5 that I know should not be used with SMP

from what I've seen most app.bin's would only require small changes

vim.app.bin - missing libraries
DownloadDaemon.app.bin , assumed /tmp/init.d/ exist but it does not, start scripts should point to /apps/downloadd/etc/init.d/Sxx

but quite a few of the cramfs formatted app.bin's give an input/output error
I'm guessing something to do with the old cramfs16k , which probably does not apply to SMP

[mad_ady]

Great work, KAD.

Regarding the incompatible cramfs - we could convert all the apps to ext3 and that would solve the issue (drop support for cramfs maybe).
Regarding apps that should be marked as incompatible, we could add the maximum firmware version they can run on to 1.06 (so that they would run on the last version for live/plus).