mysdl-load


Forum: Apps
Topic: mysdl-load
started by: jpeters

Posted by jpeters on Feb. 25 2007,09:03
I added "mydsl-load /mnt/hda3/myapp.uci"  to the /opt/bootlocal.sh file.
The app loaded correctly into the /opt directory, although without a mydsl start button. How do I start the apt?  (starting from the xterm doesn't seem to work).
Thanks

Posted by mikshaw on Feb. 25 2007,14:52
probably depends upon the application itself. If it's not a graphical application it may not have an icon.
The command will probably (but not definitely) be /opt/myapp/bin/myapp, but you may need to refer to the myapp.uci.info file in case there are some special steps to perform.

By the way, there tpically isn't any need to load mydsl apps from a startup script, since DSL is already configured to check for them during the boot process (boot option mydsl=devicename).

Posted by sheldonisaac on Feb. 25 2007,19:16
Folks, I'm very new at using myDSL, and have been struggling.

Here's what just happened today:

I downloaded a new .uci, and at present it's in  /mnt/hda4/temp-dir

I did

mydsl-load   /mnt/hda4/temp-dir/xpdf-3.01pl2.uci

And somehow eventually found out that apparently makes a symlink in
/usr/local/bin , which is on the path:

/usr/local/bin> ls -alt | more
drwxr-xr-x    2 root     root         2880 Feb 25 14:01 .
lrwxrwxrwx    1 root     root           23 Feb 25 14:01 xpdf3 -> /opt/xpdf-3.01pl2/xpdf3
drwxr-xr-x   26 root     root          280 Feb 25 14:00 ..

So if one runs the command   xpdf3

the program opens.

And if one says

xpdf3  path-to/filename.pdf

the file opens

Posted by roberts on Feb. 25 2007,19:34
First you are talking about an extension, i.e., user contributed.
Second, an extension that is currently in the testing area.
Even more important to read the readme.

Compliant extenions usually offer at least a menu option unless they are intended to be used as command line utitlity, usually advanced tools for experienced users.

Now, after reading your post, it sounds to me like this extension is not compliant, as it would require unionfs, or mkwriteable.

uci extensions by definition are self contained.

uci extensions should work and be tested by booting as follows:

boot: dsl base norestore legacy

That is the acid test for an extension to be called uci

When I have time, I will look more into this particular submitted extension.

Posted by WDef on Feb. 25 2007,21:49
It's best if uci binaries get symlinked into /opt/bin to put them in PATH where that's needed.

/opt is writeable.

Posted by jpeters on Feb. 26 2007,03:23
Quote (mikshaw @ Feb. 25 2007,09:52)
The command will probably (but not definitely) be /opt/myapp/bin/myapp, but you may need to refer to the myapp.uci.info file in case there are some special steps to perform.

Interesting.  The app is firefox-1.5.0.6.uci.  Using xterm, if  I "cd /opt/firefox-1.5.0.1" and then try loading, "firefox", I get no access priviledge errors and it defaults to loading the old version of firefox. If I do it in one step, "/opt/firefox-1.5.0.6/firefox", it loads.

Trying out a symlink gets the same result as doing the cd 2 step (sounds like a dance, doesn't it?)

Posted by roberts on Feb. 26 2007,03:57
If you chose to ignore the menu item and/or the icon, then I would sugguest to learn about PATHs. Standard *nix stuff.

If you decide to naviagte down to the firefox in /opt then it would be
./firefox to execute the local copy. Otherwise the firefox in your PATH will be executed. For search order of your PATH type

echo $PATH

Without specifying full path or relative path then first one found wins.

Posted by jpeters on Feb. 26 2007,04:12
Quote (roberts @ Feb. 25 2007,22:57)
If you chose to ignore the menu item and/or the icon, then I would sugguest to learn about PATHs. Standard *nix stuff.

If you decide to naviagte down to the firefox in /opt then it would be
./firefox to execute the local copy. Otherwise the firefox in your PATH will be executed. For search order of your PATH type

Thanks Roberts,  ./firefox it is!  (this isn't MS DOS, right?)

PS. There is no menu item or icon, which is what this thread is all about.

Posted by jpeters on Feb. 26 2007,04:30
Quote (mikshaw @ Feb. 25 2007,09:52)
probably depends upon the application itself.

I also tried installing gtk2-0705.dsl via "dsl-load" in bootlocal.sh. It worked fine for some apts and not others. For example, gnucash loaded, but firefox-1.5.0.6 would not. (both require gtk2 libraries).
Firefox-1.5.0.6 works fine if gtk2-0705 is loaded from within emelflm.

EDIT:  I substituted firefox-2.0-gtk1.uci, loading from bootlocal; loaded with an icon and all!

Posted by roberts on Feb. 26 2007,06:27
Then this thread is mis-titled,  as this has nothing to do with mydsl-load.

Are there really that many new extenions that do not even offer an menu item?

The purpose of the testing area is for just such purpose.
To report back to the user who contributed the extension, that which still needs to be tweaked.

Extensions are put together by user community.
It is also a community process to test and provide feedback to their creator.

Having a thread with extension work-arounds, does not make good  extensions.

Posted by jpeters on Feb. 26 2007,07:42
Quote (roberts @ Feb. 26 2007,01:27)
Then this thread is mis-titled,  as this has nothing to do with mydsl-load.

Are there really that many new extenions that do not even offer an menu item?

The problem only occurs when "mydsl-load /path/app" is written to bootlocal.sh; otherwise there is a menu item. No apt that I have tried got a mydsl menu item when installed from bootlocal using mydsl-load.  If the app has an icon, that does appear.

Posted by roberts on Feb. 26 2007,15:06
There is no reason to use /opt/bootlocal.sh for mydsl loading.
/opt/bootlocal.sh is run as root user.

The fact that X has not even started is the reason for such observed behavior!

Read Getting Started to learn about the proper way using a mydsl directory or the mydsl boot option for proper way to load extensions at boot time.



Posted by jpeters on Feb. 27 2007,04:34
Quote (roberts @ Feb. 26 2007,10:06)
There is no reason to use /opt/bootlocal.sh for mydsl loading.

True.....seems more simple to just load a bash script from xterm with all frequently used apts listed:

#!/bin/bash
mydsl-load /path/apt1
mysdl-load /path/apt2
...

Now I can run whatever I want from the mydsl menu.
But why keep things simple when there are more creative approaches?

Posted by roberts on Feb. 27 2007,05:31
There is the easy way (place extensions in a directory and type one thing) and then there is the manual way, create a list and manually type each and every extension name.

Whatever. No matter what I suggest you are apparently not going to accept.



Posted by jpeters on Feb. 27 2007,06:06
Quote (roberts @ Feb. 27 2007,00:31)
"There is the easy way (place extensions in a directory and type one thing)"

Sounds good to me......


"Whatever. No matter what I suggest you are apparently not going to accept."


?? hm...... (guess I neglected to include a smiley face on my previous post)

Posted by jpeters on Mar. 03 2007,04:26
Quote (roberts @ Feb. 26 2007,10:06)
There is no reason to use /opt/bootlocal.sh for mydsl loading.

One helpful use I found for mydsl loading via bootlocal is libraries such as tcltk.  Given that I frequently use a number of apps written in tcltk (my own), my system boots with tcltk loaded along  with desktop icons linked to my apps.  For my uses, this works nicely.

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.