DSL Ideas and Suggestions :: uci applications in PATH

It would be nice if there were an easy way to add applications to the PATH (and maybe lib's too).

Perhaps adding /opt/bin to the standard path, and allowing binaries opr links to that.

That way the .tar.gz or wrapper scripts wouldn't be needed.

Wrapper scripts are still needed if the application requires libs that are not in standard locations. The user.tar.gz has uses beyond what you might think. It is actually a myDSL extension embedded in the compressed uci file, so theoretically it can be used for just about anything a tar.gz extension can.

While I agree that /opt/bin would be convenient, there are other ways a user can easily add uci extensions to his path.

You can create the /opt/bin directory yourself, and add that to your path:

Code Sample

export PATH="/opt/bin:$PATH"
ln -s /opt/something/bin/something /opt/bin/

That's how I do it, except my bin directory is /home/dsl/bin.

You can add the individual apps to your path, or try all in one go:

Code Sample

for i in /opt/*/bin; do export PATH="$i:$PATH"; done

That only works if the app is set up with its executable(s) in /opt/something/bin.

You can make aliases for the applications you want to run with a short command:

Code Sample

alias im='/opt/imagemagick/bin/display'

I'm sure there are other methods.

Thanks for the response.

Are you suggesting I have a /usr/bin/myapp entry in user.tar.gz?

A wrapper script works great for graphical apps that run from an icon, but for a command line app, especially a utility, it's awkward.

I currently pop up a dillo page explaining that to use my app (OWFS) you must call /opt/owfs/bin/owfs.

I'll do the user.tar.gz approach, but I was trying to be stingy in my use of memory. Now that I think about it, requiring uncompressing each time the PATH is explored might be a little unwieldy, too.

You should NOT have a /usr/bin/myapp in a .tar.gz or .uci package. There should be nothing that writes to /usr, /bin, /boot, /lib, or /sbin. These directories are all initially read-only. After mkwriteable has run (e.g. after loading a .dsl package) you can load files into these directories from a .tar.gz package, but by that time there's not much point in it being a tar.gz. For the sake of consistency, it's best to use a .dsl package for anything that needs to go into these directories.

I don't see why it's such a trouble to add bin directories to your PATH variable manually...it's one of the basic parts of being a linux user. If you are really that concerned with ease-of-use, just make your application a .dsl package that installs into /usr. If you go through the trouble of making an html page you could have set the PATH a hundred times over in that time.

I have no idea what your last sentence is saying. The PATH is explored every time you issue a command (gadzillions of times a day). There is no uncompressing required when this happens.

original here.