inotify watches files and folders, but it operates "after the fact".
But it errors on nonexistent files. To make a dummy file, I might as well use a link instead.
An inotify watch is needed for each and every file. It won`t watch a "parent" path.
But in many cases it`d be okay. A really sad way of going about this, but it could work.
I need to intercept access to links as it`s happening, and stop it.
Then need to auto. run an exec. that does "readlink" to get the paths in the link.
The exec. then searches the paths for the original file that was being accessed.
If the file`s found then it`s path is substituted for the original one and the access continues.
Sort of a backward "aliases" for paths allowing many paths to merge with the original path.
Kind of a hacked "path join" or a "junction".
.
How to "intercept" a path access.?
"intercept access to links" You mean you want to run arbitrary code when one clicks on a link, or when one uses it as a part of some other command -possibly cli? Or are you wanting to intercept the creation of such links and run code?
I'm guessing you are trying to redirect the links from a known program path or library path, so that they point to things installed 'out of the way'. ??
I'm guessing you are trying to redirect the links from a known program path or library path, so that they point to things installed 'out of the way'. ??
amigo; You know me so well... Still playing with the junction idea.
Yes, redirect the path for any access from any source ( like a link does ).
For many things this can be hacked, I`ve made a few, but for apps it`s no small problem.
I can`t see how inotify could do it, it`s a hacky solution at best. And alias is no help either.
Links will hold a path, the problem`s the ext kernel module ( I think ), and fs tools of course.
I`m not trying to replace unions, want a simpler half-way solution with partial functionality.
# Behavior:
1) Read item from the first path encountered.
2) Create new item, write to the first writable path. If none then the write fails of course.
3) Modify write to the items path, if it`s writable.
... "Maybe" if that fails, write to the first writable path ( cow ). I don`t see this as a necessity.
... And if the item`s path comes before the first writable path, then the write would fail.
4) Delete item only if it`s in a writable path. No delete of original read-only, no white-outs.
I emailed one of the extfs devs, but no reply. I`m not surprised. But maybe got him thinking.
No reply from the Xfe dev either. I guess just wait for the next release to see if it stuck.
.
Yes, redirect the path for any access from any source ( like a link does ).
For many things this can be hacked, I`ve made a few, but for apps it`s no small problem.
I can`t see how inotify could do it, it`s a hacky solution at best. And alias is no help either.
Links will hold a path, the problem`s the ext kernel module ( I think ), and fs tools of course.
I`m not trying to replace unions, want a simpler half-way solution with partial functionality.
# Behavior:
1) Read item from the first path encountered.
2) Create new item, write to the first writable path. If none then the write fails of course.
3) Modify write to the items path, if it`s writable.
... "Maybe" if that fails, write to the first writable path ( cow ). I don`t see this as a necessity.
... And if the item`s path comes before the first writable path, then the write would fail.
4) Delete item only if it`s in a writable path. No delete of original read-only, no white-outs.
I emailed one of the extfs devs, but no reply. I`m not surprised. But maybe got him thinking.
No reply from the Xfe dev either. I guess just wait for the next release to see if it stuck.
.
I'm afraid you won't get any devs interested in your idea. links are handled in kernel space and the sort of processing/decision-making you describe would never make it into kernel space. At that level, a link points to another specific location(inode) -it could never work having a link, which is like a sign post, pointing at multiple locations.
Of course, the real goal of your quest has already been solved using various methods. And of course, each of those methods has its advantages and disadvantages. You don't like having so many mounts. I agree that it could get messy. But, I'm afraid that anything you do could get messy when handling lots of running apps. Still, unioning at the application level is probably the easiest way to accomplish what you want and retain control. If you 'top off' the union with a chroot you actually have a pretty powerful way of sandboxing a process -even though chroots are also not perfect.
I wonder, did you know there is still another (modern) way of implementing COW -using devmapper? I'm pretty sure it's been done elsewhere, but the only implementation that I know of is in the fedora CD's. It looks pretty complex -just like unioning does.
I think we already found an ideal solution to the problem with unionfs-fuse, fakechroot and fusermount -which all can be used by normal un-privileged users. I would still urge you to abandon using an intermediate layer with a bunch of loosely-grouped libs in a separate SFS/whatever.
The best verbal formulation I've found for a workable solution is from the 'chakra' project -an archlinux LiveCD. There they manage both regular arch packages and 'bundles' -modules which can be loaded dynamically. They specify that a bundle may require any normal package, but must not depend on any other bundle. It makes sense that any underlying requirements -libraries, etc, should be handled as normal packages. Bundles only make sense for applications -but they can include any libs *not available* from the core distros packages, or may include newer/older versions of libs which are correct for the application, but different from the distros versions of those libs. I haven't looked into the specifics of loading the bundles, but I'm pretty sure that it involves union mounts.
In order for your scheme to work, you need to separate the concepts of the: 1. content format 2. delivery method and 3. method of making the software available/runnable.
The content format can be an archive or a filesystem image or even a stream from a mounted remote filesystem. There's nothing to stop you from unioning a decompressed or vfs-mounted archive -in mostly the same way you do with an SFS. SFS's are, generically, a file-system image. You could also use cramfs(also read-only like squashfs) or an ext2/3/4 or other linux filesystem (as an image).
Delivery method refers to how one gets access to the 'module' -from a local drive SC/flash/HDD, etc or over the network -using httpfs-mounts, traditional download, etc. It's really a minor thing to work out, but in the implementation the method chosen here has a great effect on usability(think of how puppy takes so long to boot up because of looking all over the place for obscurely-named sfs's ,etc).
How you make the software available refers to whether you:
1. install the files normally (congratulations, one less problem)
2. use a union-mount or union filesystem to squeeze the files in place
3. create links in the real, main paths which refer to the out-of-normal-place files. The gobo method -super messy and still requires you to write to (and delete from) normal paths.
4. configure and compile the applications to use an out-of-place prefix. (this is the way of real compile-from-source ROX-compatible application directories)
5. use the limited tricks of wrappers which set LD_LIBRARY_PATH and PATH, etc. Note that this does not allow a solution to accessing files looked for under /usr/share, /etc and others.
If I understand your quest, using union-mounts offers the most-complete and least-intrusive solution. Of course there are still other, more obscure methods. But, I think you'll find it easier to analyze them and evaluate their usefulness by thinking about the three points mentioned above.
When I say, use union-mounts, I really mean to use independent mounts -not adding/removing layers to an underlying aufs unionfs. I really think aufs should be avoided simply because it involves a kernel patch. Even though aufs has a really small footprint as to insertion points in the kernel code, it can still be very hard to maintain/upgrade. Still (wistfully), aufs has that nice ability to add/remove layers on-the-fly. But, a user-level application has no business messing with system mounts created by root anyway.
Now there, I've let you distract me again -and I know you still won't be happy with my response... Sometime I must tell you about how tedious it gets trying to individually hack more than a few programs to do wonderful things. Hacking stuff over arbitrary decisions or criteria gets old right fast -and you'll never ever keep up with events around you. One must never think that he is the first to come up with an idea -we stand on the shoulders of giants. And they have usually either implemented the thing in the most elegant way possible, or have demonstrated the unsurmountable flaws of the idea. Successful implementation comes from leveraging both the wisdom and techniques of those giants in a practical, mass-repeatable way.
Of course, the real goal of your quest has already been solved using various methods. And of course, each of those methods has its advantages and disadvantages. You don't like having so many mounts. I agree that it could get messy. But, I'm afraid that anything you do could get messy when handling lots of running apps. Still, unioning at the application level is probably the easiest way to accomplish what you want and retain control. If you 'top off' the union with a chroot you actually have a pretty powerful way of sandboxing a process -even though chroots are also not perfect.
I wonder, did you know there is still another (modern) way of implementing COW -using devmapper? I'm pretty sure it's been done elsewhere, but the only implementation that I know of is in the fedora CD's. It looks pretty complex -just like unioning does.
I think we already found an ideal solution to the problem with unionfs-fuse, fakechroot and fusermount -which all can be used by normal un-privileged users. I would still urge you to abandon using an intermediate layer with a bunch of loosely-grouped libs in a separate SFS/whatever.
The best verbal formulation I've found for a workable solution is from the 'chakra' project -an archlinux LiveCD. There they manage both regular arch packages and 'bundles' -modules which can be loaded dynamically. They specify that a bundle may require any normal package, but must not depend on any other bundle. It makes sense that any underlying requirements -libraries, etc, should be handled as normal packages. Bundles only make sense for applications -but they can include any libs *not available* from the core distros packages, or may include newer/older versions of libs which are correct for the application, but different from the distros versions of those libs. I haven't looked into the specifics of loading the bundles, but I'm pretty sure that it involves union mounts.
In order for your scheme to work, you need to separate the concepts of the: 1. content format 2. delivery method and 3. method of making the software available/runnable.
The content format can be an archive or a filesystem image or even a stream from a mounted remote filesystem. There's nothing to stop you from unioning a decompressed or vfs-mounted archive -in mostly the same way you do with an SFS. SFS's are, generically, a file-system image. You could also use cramfs(also read-only like squashfs) or an ext2/3/4 or other linux filesystem (as an image).
Delivery method refers to how one gets access to the 'module' -from a local drive SC/flash/HDD, etc or over the network -using httpfs-mounts, traditional download, etc. It's really a minor thing to work out, but in the implementation the method chosen here has a great effect on usability(think of how puppy takes so long to boot up because of looking all over the place for obscurely-named sfs's ,etc).
How you make the software available refers to whether you:
1. install the files normally (congratulations, one less problem)
2. use a union-mount or union filesystem to squeeze the files in place
3. create links in the real, main paths which refer to the out-of-normal-place files. The gobo method -super messy and still requires you to write to (and delete from) normal paths.
4. configure and compile the applications to use an out-of-place prefix. (this is the way of real compile-from-source ROX-compatible application directories)
5. use the limited tricks of wrappers which set LD_LIBRARY_PATH and PATH, etc. Note that this does not allow a solution to accessing files looked for under /usr/share, /etc and others.
If I understand your quest, using union-mounts offers the most-complete and least-intrusive solution. Of course there are still other, more obscure methods. But, I think you'll find it easier to analyze them and evaluate their usefulness by thinking about the three points mentioned above.
When I say, use union-mounts, I really mean to use independent mounts -not adding/removing layers to an underlying aufs unionfs. I really think aufs should be avoided simply because it involves a kernel patch. Even though aufs has a really small footprint as to insertion points in the kernel code, it can still be very hard to maintain/upgrade. Still (wistfully), aufs has that nice ability to add/remove layers on-the-fly. But, a user-level application has no business messing with system mounts created by root anyway.
Now there, I've let you distract me again -and I know you still won't be happy with my response... Sometime I must tell you about how tedious it gets trying to individually hack more than a few programs to do wonderful things. Hacking stuff over arbitrary decisions or criteria gets old right fast -and you'll never ever keep up with events around you. One must never think that he is the first to come up with an idea -we stand on the shoulders of giants. And they have usually either implemented the thing in the most elegant way possible, or have demonstrated the unsurmountable flaws of the idea. Successful implementation comes from leveraging both the wisdom and techniques of those giants in a practical, mass-repeatable way.
A thoughtful post amigo. I agree with everything you`ve said. ( Surprised? 
)
Except the: "-it could never work having a link". Limited use as I stated for sure.
It wouldn`t allow legacy package installs if used on any of the dirs you mentioned.
But for individual apps to use them for file system path patching, they could work well.
It certainly is easiest to use the legacy package systems of most distros. But it`s not the best.
Delivery methods. I made LanPup many years ago. Could boot from web or a satellite signal.
TinyCore`s masses of links is a brute force method for the job. Much prefer elegant simplicity.
mhddfs works very well and is smaller than unionfs-fuse. Both use libfuse.
mikeb observed that aufs`s load is running it, adding layers doesn`t increase it that much.
The load of many user-space unions may be worse than one kernel-space "Puppy style".
Thinking of using aufs in place of mhddfs, faster and it`s already being loaded in many distros.
Idea of a common lib. in the package has limited use for sure. A "patch" lib. dir. is a good idea.
Especially for Puppy`s many variants "grab bag of bones". You never know what libs you`ll get.
An evolving world is a given, been there, am doing that... Good tools are the only salvation.
On the backs of Titans we go forth to change the world. Thanks for the reply amigo. Terry B.
.
)Except the: "-it could never work having a link". Limited use as I stated for sure.
It wouldn`t allow legacy package installs if used on any of the dirs you mentioned.
But for individual apps to use them for file system path patching, they could work well.
It certainly is easiest to use the legacy package systems of most distros. But it`s not the best.
Delivery methods. I made LanPup many years ago. Could boot from web or a satellite signal.
TinyCore`s masses of links is a brute force method for the job. Much prefer elegant simplicity.
mhddfs works very well and is smaller than unionfs-fuse. Both use libfuse.
mikeb observed that aufs`s load is running it, adding layers doesn`t increase it that much.
The load of many user-space unions may be worse than one kernel-space "Puppy style".
Thinking of using aufs in place of mhddfs, faster and it`s already being loaded in many distros.
Idea of a common lib. in the package has limited use for sure. A "patch" lib. dir. is a good idea.
Especially for Puppy`s many variants "grab bag of bones". You never know what libs you`ll get.
An evolving world is a given, been there, am doing that... Good tools are the only salvation.
On the backs of Titans we go forth to change the world. Thanks for the reply amigo. Terry B.
.
I meant that you will never see such a junction-link feature implemented in kernel VFS or any of the normal file-systems -it simply does not fit into the philosophy of the kernel VFS and would not be accepted into any of the normal linux filesystems. YOu could cretainly implement that using fuse, though.
The point I meant to make about mhddfs is that when using it *all* 'layers' are read-write. If you read the documentation about where things get written to and how that decision is made, you'll get an idea of the complexity of implementing the juncton idea -the problem is not exactly the same, but entails the same principles.
I meant to ask you before about where the links come from that you want to exhibit this ~ behavior. If you mean for them to part of your application, then I think I have an idea how you could achieve the behavior you want -with wrappers. Instead of trying to dynamically change links to point where you want in a certain situation, or having a junction-link, or even a union mount, you simply have a wrapper script at the main location which decides what to do. You know, you can even have a fake shared-library which is actually a script.
If you can explain more fully a specific use case with at least two optional expected behaviors, then I can help a little more.
The point I meant to make about mhddfs is that when using it *all* 'layers' are read-write. If you read the documentation about where things get written to and how that decision is made, you'll get an idea of the complexity of implementing the juncton idea -the problem is not exactly the same, but entails the same principles.
I meant to ask you before about where the links come from that you want to exhibit this ~ behavior. If you mean for them to part of your application, then I think I have an idea how you could achieve the behavior you want -with wrappers. Instead of trying to dynamically change links to point where you want in a certain situation, or having a junction-link, or even a union mount, you simply have a wrapper script at the main location which decides what to do. You know, you can even have a fake shared-library which is actually a script.
If you can explain more fully a specific use case with at least two optional expected behaviors, then I can help a little more.
Again thanks amigo. Now I realize the value of shell inheritance and a private environment.
Unions can be global or local (private). A "link" Jct. would be global and couldn`t work.
Basically need what a local union does, but no cow or white-outs. Use what you got?
I know mhddfs isn`t ment for this. Better is Puppy`s aufs as it`s there and kernel space.
# AppPkg setup:
/(path)/xfe-1.2.3.AppPkg/( AppRun link-to-exec.)
/(path)/xfe-1.2.3.AppPkg/.AppPkg/0/( scripts )
/(path)/xfe-1.2.3.AppPkg/.AppPkg/xfe-1.2.3/xfe-1.2.3.sq
/(path)/xfe-1.2.3.AppPkg/.AppPkg/xfe-1.2.3/$HOME
/tmp/.AppPkg/xfe-1.2.3 ( Sq.mnt.pt.)
/tmp/.AppPkg/xfe-1.2.3._U # if a union is used.
Files are made dynamically in $HOME as $HOME isn`t known. So can`t rely on package.
Install the app and use all of it to find where all the dynamically generated dirs/files are.
Need to take fs snapshots of /root, etc... to compare with after the install. Or file mod times?
I`m thinking, a no search setup script, cp -sn link a list of /path/files to /. Reduce the calls.
Probably have to limit the line length and dir/file count so cp doesn`t choke. Boot cleanup.
Most apps only need one line of cp/rm. Fast with only one call to cp and no searching.
A wrapper script would be needed for each file, so it seems more complex than using links.
Errors if a script /root is accessed with /root/Config/xxx. Or maybe there`s another way?
I can make BaCon exec. files... So if I can just "get the picture", an exec. might be better.
I think you should understand the requirements, ask anything for clarification. Terry B.
.
Unions can be global or local (private). A "link" Jct. would be global and couldn`t work.
Basically need what a local union does, but no cow or white-outs. Use what you got?
I know mhddfs isn`t ment for this. Better is Puppy`s aufs as it`s there and kernel space.
# AppPkg setup:
/(path)/xfe-1.2.3.AppPkg/( AppRun link-to-exec.)
/(path)/xfe-1.2.3.AppPkg/.AppPkg/0/( scripts )
/(path)/xfe-1.2.3.AppPkg/.AppPkg/xfe-1.2.3/xfe-1.2.3.sq
/(path)/xfe-1.2.3.AppPkg/.AppPkg/xfe-1.2.3/$HOME
/tmp/.AppPkg/xfe-1.2.3 ( Sq.mnt.pt.)
/tmp/.AppPkg/xfe-1.2.3._U # if a union is used.
Files are made dynamically in $HOME as $HOME isn`t known. So can`t rely on package.
Install the app and use all of it to find where all the dynamically generated dirs/files are.
Need to take fs snapshots of /root, etc... to compare with after the install. Or file mod times?
I`m thinking, a no search setup script, cp -sn link a list of /path/files to /. Reduce the calls.
Probably have to limit the line length and dir/file count so cp doesn`t choke. Boot cleanup.
Most apps only need one line of cp/rm. Fast with only one call to cp and no searching.
A wrapper script would be needed for each file, so it seems more complex than using links.
Errors if a script /root is accessed with /root/Config/xxx. Or maybe there`s another way?
I can make BaCon exec. files... So if I can just "get the picture", an exec. might be better.
I think you should understand the requirements, ask anything for clarification. Terry B.
.
It took me a while to figure out that you imagine:
/(path)/xfe-1.2.3.AppPkg/( AppRun link-to-exec.)
to be the junction/link. No, that simply needs to be an AppRun *script* which can figure out anything you need to know, perform any intermediate steps and then, finally, exec the wanted program.
I've whipped up a quick AppRun which is close to what you need, I think. Lots of notes in there, so please tell me if you don't understand what its' doing or if it needs to something else -before we proceed to a more complex script which includes right-click options, handling of files dropped on the icon or *multiple files* dropped on the icon.
And, creating a link from the AppRun script to somewhere in the normal PATH will let this AppDir be run from the command line or executed by other file managers(but not by clicking on the toplevel AppDir directory like with rox -that's what makes this bundle/application directory/program folder/AppDir/RoxApp a RoxApp. Only rox looks for an AppRun script in every directory you point it at.)
I hope this gets you a little farther down the road. I know those roads are long in your neck of the woods(or is it desert?) - I come from the second desert to the east of you... Or, if you are in the woods there, then just walk east until you hit the Pecos River, jump in, and then jump back out when you get half-way to the Gulf...
/(path)/xfe-1.2.3.AppPkg/( AppRun link-to-exec.)
to be the junction/link. No, that simply needs to be an AppRun *script* which can figure out anything you need to know, perform any intermediate steps and then, finally, exec the wanted program.
I've whipped up a quick AppRun which is close to what you need, I think. Lots of notes in there, so please tell me if you don't understand what its' doing or if it needs to something else -before we proceed to a more complex script which includes right-click options, handling of files dropped on the icon or *multiple files* dropped on the icon.
And, creating a link from the AppRun script to somewhere in the normal PATH will let this AppDir be run from the command line or executed by other file managers(but not by clicking on the toplevel AppDir directory like with rox -that's what makes this bundle/application directory/program folder/AppDir/RoxApp a RoxApp. Only rox looks for an AppRun script in every directory you point it at.)
Code: Select all
#!/bin/sh
# we need to know where this app is because
# you want to access files here
# $0 is the name/path by which we were executed
if [ ! -L "$0" ] ; then
# if it's not a link, then the name of the directory is
# where we are
APP_DIR=`dirname "$0"`
APP_DIR=`cd "$APP_DIR";pwd`;
else
# if this AppDir was executed by running a link
# then readlink will tell us where the real location is
if [ ! -z `which readlink 2> /dev/null` ] ; then
APP_DIR=`readlink -f "$1"`
APP_DIR=`dirname "$APP_DIR"`
else
echo "$PROG: Can't get real path to AppRun!" 1>&2
# actually we could still find it using /proc/self/exe
fi
fi
# APP_NAME is the name of the directory -the toplevel of the AppDir
APP_NAME=`basename "$APP_DIR"`
# we want to reference some scripts in a subdir of the AppDir (bin)
# so add that to the normal PATH -our new PATH goes in front of
# the old PATH so that local(inside the AppDir) programs get used
# instead of anything in the normal PATH
APP_BIN_DIR="${APP_DIR}/bin"
PATH=${APP_BIN_DIR}:$PATH
# now we want to mount a filesystem image (SFS,sq,ext2fs, whatever)
# and place the path to the binaries there in PATH also
# One really shouldn't count on the user being able to write to the AppDir
# itself, so create mount points under /tmp or in the users $HOME
# although, for simplicity's sake as a demo, we'll use mount/unmount
mkdir -p /tmp/.AppPkg/xfe-1.2.3
# mkdir -p /$HOME/.AppPkg/xfe-1.2.3
# really should be in users $HOME so that more than one person can
# run this App -even at the same time:
mount -t squahsfs -o loop $APP_DIR/xfe-1.2.3.sq /tmp/.AppPkg/xfe-1.2.3
# so I guess there's a dir /tmp/.AppPkg/xfe-1.2.3/usr/bin?
PATH=/tmp/.AppPkg/xfe-1.2.3/usr/bin:$PATH
# make this PATH (combined above) available to everything called from here
# for instance xfe may call some binary helpers included with it.
# if this local PATH is not exported, then xfe will not know about
# it and those helpers will not be found
export PATH
# if there are libraries in the *sqf* that are needed by (xfe), then
# add the local library path to LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/tmp/.AppPkg/xfe-1.2.3/usr/lib:$D_LIBRARY_PATH
# now run the program:
exec xfe "$@"
# by exec-ing it the current process is taken over by xfe so that
# once started, `ps ax` will show xfe as running and not this shell instance
# This example only works for programs which access a PATH or LD_LIBRARY_PATH
# the program can access the users' $HOME just like normally.
# If a program would normally look for items in /etc or /usr/share,
# then this solution will not work -a union mount must be used
# or some even hackier solution must be used...
Hi amigo; Very good... Some Qs:
# mkdir -p /$HOME/.AppPkg/xfe-1.2.3 This really should be in users $HOME
# so that more than one person can run this App -even at the same time:
Why is this so? It seems like /tmp/.AppPkg/xfe-1.2.3 would have global access, not $HOME.
# by exec-ing it the current process is taken over by xfe so that once started,
# `ps ax` will show xfe as running and not this shell instance
Is the only difference in using "exec", or " &" at the end, that "exec" ends the script?
If that`s the only difference then I don`t see the point in the "exec" command.
" &" doesn`t like anything else on the line after it. But this isn`t a problem usually.
I had a few other command type Qs, but I can`t think of them right now. Damn..!
I hadn`t ever considered a drag-n-drop AppDir. MU made a few Rox desktop dnd apps.
Yes, sadly Rox filer is the only FM that does AppDir. A new FM "Sunflower" may help.
Idea of a purpose for an AppDir right click menu: To select a package to dnld & compile.
I agree, making AppDir is a pain in the arse. Making legacy pkgs. and SFS is not so bad.
I`m ready for the rest of your tutorial. And tricks for a hacky Jct.! A transparent mount?
### So you`re from somewhere around San Antonio? Or one of the border cities?
My youngest daughter lives with her husband who`s stationed in El Paso - Ft. Bliss.
### Here`s my streamlined AppPkg setup & run scripts. About as fast as a union-chroot.!
Links all the needed dirs/files. There`s still a few holes in it I`m sure. Need build advice.
This setup script is run with the apps exec. file ( no path ) as arg. $@.
# And the "hook" run script. It hangs with the app taking only about 40 bytes of ram!:
# mkdir -p /$HOME/.AppPkg/xfe-1.2.3 This really should be in users $HOME
# so that more than one person can run this App -even at the same time:
Why is this so? It seems like /tmp/.AppPkg/xfe-1.2.3 would have global access, not $HOME.
# by exec-ing it the current process is taken over by xfe so that once started,
# `ps ax` will show xfe as running and not this shell instance
Is the only difference in using "exec", or " &" at the end, that "exec" ends the script?
If that`s the only difference then I don`t see the point in the "exec" command.
" &" doesn`t like anything else on the line after it. But this isn`t a problem usually.
I had a few other command type Qs, but I can`t think of them right now. Damn..!
I hadn`t ever considered a drag-n-drop AppDir. MU made a few Rox desktop dnd apps.
Yes, sadly Rox filer is the only FM that does AppDir. A new FM "Sunflower" may help.
Idea of a purpose for an AppDir right click menu: To select a package to dnld & compile.
I agree, making AppDir is a pain in the arse. Making legacy pkgs. and SFS is not so bad.
I`m ready for the rest of your tutorial. And tricks for a hacky Jct.! A transparent mount?
### So you`re from somewhere around San Antonio? Or one of the border cities?
My youngest daughter lives with her husband who`s stationed in El Paso - Ft. Bliss.
### Here`s my streamlined AppPkg setup & run scripts. About as fast as a union-chroot.!
Links all the needed dirs/files. There`s still a few holes in it I`m sure. Need build advice.
This setup script is run with the apps exec. file ( no path ) as arg. $@.
Code: Select all
#!/bin/sh
######### AppPkg setup script. Terence Becker SunBurnt Nov. 11 2013
### No warranty of any kind... Use at your own risk!
### Link cleanup code, run at boot backgrounded & time-delayed. ###
#find $HOME -xtype l -delete ### Remove Dead Links.
#find /usr -xtype l -delete
#find /etc -xtype l -delete
#find /opt -xtype l -delete
#find /var -xtype l -delete
#gtk-update-icon-cache -f -i /usr/share/icons/hicolor # update gtk cache
PF=`realpath $0` # full path of this file
apP=${PF%/0*} # full path to "mid" dir.
cd $apP # change to "mid" dir.
F=${PF##*/} # full name of this file
PKG=${F%.run} # pkg. name only, no ext.
#>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mnt. Sq. File, Make Links, Set Paths, Run App.
if [ "$1" ];then
echo -e "\n### Run: $PKG\n"
APP="$PKG/$PKG" # loose files dir.
[ ! -d $APP ]&&
APP="/tmp/.AppPkg/$PKG" && mkdir -p $APP # Sq. file mnt. dir.
SQ=$PKG/$PKG.sq
#echo -e "\n$PKG\n$APP\n$SQ\n$@\n" ;exit
#SQ='a'
[ -f $SQ ]&&
if [ ! "`mount |grep $APP`" ];then # mount Squash file
mount -r -t squashfs -o loop $SQ $APP
[ $? -gt 0 ]&&
echo -e "\n### ERROR: Failed Squash File Mount: $SQ\n" && exit
echo -e "\n# Mount Squash File: $SQ\n"
fi
us=/usr/share
p=${PKG%%[-_]*} ; p=`ls -d $APP$us/$p* 2>/dev/null` # link /usr/share/(dep)
[ -d $APP$p ]&& cp -snpP $APP$p/* $p 2> /dev/null
p=$us/applications # link .desktop files
[ -d $APP$p ]&& cp -snpP $APP$p/* $p 2> /dev/null
p=$us/pixmaps # link /pixmaps files
[ -d $APP$p ]&& cp -snpP $APP$p/* $p 2> /dev/null
p=$PKG$HOME # link $HOME files
[ -d $p ]&& cp -snprP $p/* $HOME 2> /dev/null
p=$PKG/etc # link /etc files
[ -d $p ]&& cp -snprP $p/* /etc 2> /dev/null
p=$PKG/opt # link /opt files
[ -d $p ]&& cp -snprP $p/* /opt 2> /dev/null
p=$PKG/var # link /var files
[ -d $p ]&& cp -snprP $p/* /var 2> /dev/null
au=$APP/usr
[ -d $au/bin ]&& PATH=$au/bin:$PATH # app. path /usr/bin
[ -d $au/games ]&& PATH=$au/games:$PATH # app. path /usr/games
[ -d $au/lib ]&& LLP=$au/lib:$LD_LIBRARY_PATH # app. path /usr/lib
[ -d lib ]&& LD_LIBRARY_PATH=$apP/lib:$LLP # path to "patch" /lib
export PKG PATH LD_LIBRARY_PATH
echo -e "\n$PATH\n\n$LD_LIBRARY_PATH\n"
0/run $@ & # run app. hook file
else #>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unmount Sq. File.
echo -e "\n\n### End: $PKG\n"
umount -d /tmp/.AppPkg/$PKG 2> /dev/null # unmount Squash file
fi #>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End.
Code: Select all
$@
0/$PKG.run &"It seems like /tmp/.AppPkg/xfe-1.2.3 would have global access, not $HOME."
Yes, using /tmp allows anyone to write or delete stuff there, but using a fixed 'public' location means the user would have no privacy. Unprivileged users might have trouble writing or creating dirs under there if they have already been created by another user, also one couldn't run two instances of the program at the same time.
"I don`t see the point in the "exec" command"
Without using the exec the shell will keep on running until the program finishes -using *precious* (LOL)resources and also showing up in 'ps ax' as /bin/sh name-of-xour-proggie. It is a small matter, but, unless there is a reason to keep the shell running -like needing to process something *after* the wrapped program, then exec is highly advisable. Still, I remember helping you with a Chrome AppDir where we were doing something after the program had exited -but that may have been unnecessary.
"A new FM "Sunflower" Yeah, I saw your interest there. That one should be fairly easy to modify as it is a python-based FM. It simply needs to check, each time that a directory is clicked
, if there is an AppRun inside there, then execute the AppRun instead of opening the dir. Actually, nearly any file manager could be made to do this with just a couple of lines of code. Displaying the .DirIcon and using any AppInfo.xml would be more involved. This is where creating links in normal path which point to the AppRun can provide basic functionality when used with other file managers -or even from the command-line.
"drag-n-drop AppDir" Actually, that is the whole point of Risc On X (ROX). The usage concept turns the normal paradigm upside down. Instead of opening a program and then using File-Open and browsing to where the file you want is located, you simply drop the file onto the icon. This is the way applications worked under MacOS Classic, and early Xerox/NeXT systems. Puppy has never used even half of what ROX is supposed to do... Of course, Puppy uses a well-fleshed-out set of right click options and default actions when simply clicking an icon. I never really liked using many default-click actions as for many files, I may want open them with different things. And neither Run Actions, nor right click will let you drop multiple files and do something useful with them
El Paso - Ft. Bliss San Antonio
Sort of close. My daughter is from Juarez and now lives in San Antonio. My home town is exactly half-way between El Paso and Dallas -I'll keep you guessing for awhile...
I myself lived in Mexico for nearly 15 years, but now have been in Germany for over 10 years -I miss Mexico like crazy! I spent some time around Flagstaff and lived one Winter in Meas -back when it was a pretty small place. I remember Apache Junction -what's the name of those mountains? something mysterious sounding...
"find /usr -xtype l -delete" Wow!, couldn't you think of anything more destructive?? And all those links -that doesn't fit the concept at all. It does allow you top temporarily make something available as if tit were installed in a normal path. But, if you have the rights to create links in those paths, why not simply install the thing and be done with it. And Making lists of existing links so they can be restored afterwards?? That is really hacky, too -it makes the underlying programs unavailable as long as you app is running -I mean if linking to your app has deleted any existing links -and what if they are really applications instead of just links?
"0/run $@ & # run app. hook file
$@
0/$PKG.run &" You may need a shebang at the top, although I think it may be that $1 or $@ is empty -is your AppRun being executed with parameters? -like AppRun name-of-proggie.
I'm gonna try to extend this all into a small tutorial which will start out with the most basic 'WrapDir' and then go step-by-step to more complex usage. Here's one tip, if you pepper your code with echo statements(with useful output) and then execute the thing from a terminal, then you can get some quick debug output -simply cd into the AppDir, open a terminal and run`./AppRun` or `./AppRun arguments`. In particular, you can easily check if all your vars are being expanded the way you envision it.
It's late here in the Rhein/Main region(still keeping you guessing...), so you'll have to 'make do' with this for today -unless your still up after (your) midnight when I start all over tomorrow.
Wait, a tantalizing preview of how we distinguish between a simple left-click on the icon, a right-click(or run AppRun with args) and dropping multiple files on the icon:
Yes, using /tmp allows anyone to write or delete stuff there, but using a fixed 'public' location means the user would have no privacy. Unprivileged users might have trouble writing or creating dirs under there if they have already been created by another user, also one couldn't run two instances of the program at the same time.
"I don`t see the point in the "exec" command"
Without using the exec the shell will keep on running until the program finishes -using *precious* (LOL)resources and also showing up in 'ps ax' as /bin/sh name-of-xour-proggie. It is a small matter, but, unless there is a reason to keep the shell running -like needing to process something *after* the wrapped program, then exec is highly advisable. Still, I remember helping you with a Chrome AppDir where we were doing something after the program had exited -but that may have been unnecessary.
"A new FM "Sunflower" Yeah, I saw your interest there. That one should be fairly easy to modify as it is a python-based FM. It simply needs to check, each time that a directory is clicked
, if there is an AppRun inside there, then execute the AppRun instead of opening the dir. Actually, nearly any file manager could be made to do this with just a couple of lines of code. Displaying the .DirIcon and using any AppInfo.xml would be more involved. This is where creating links in normal path which point to the AppRun can provide basic functionality when used with other file managers -or even from the command-line.
"drag-n-drop AppDir" Actually, that is the whole point of Risc On X (ROX). The usage concept turns the normal paradigm upside down. Instead of opening a program and then using File-Open and browsing to where the file you want is located, you simply drop the file onto the icon. This is the way applications worked under MacOS Classic, and early Xerox/NeXT systems. Puppy has never used even half of what ROX is supposed to do... Of course, Puppy uses a well-fleshed-out set of right click options and default actions when simply clicking an icon. I never really liked using many default-click actions as for many files, I may want open them with different things. And neither Run Actions, nor right click will let you drop multiple files and do something useful with them
El Paso - Ft. Bliss San Antonio
Sort of close. My daughter is from Juarez and now lives in San Antonio. My home town is exactly half-way between El Paso and Dallas -I'll keep you guessing for awhile...
I myself lived in Mexico for nearly 15 years, but now have been in Germany for over 10 years -I miss Mexico like crazy! I spent some time around Flagstaff and lived one Winter in Meas -back when it was a pretty small place. I remember Apache Junction -what's the name of those mountains? something mysterious sounding...
"find /usr -xtype l -delete" Wow!, couldn't you think of anything more destructive?? And all those links -that doesn't fit the concept at all. It does allow you top temporarily make something available as if tit were installed in a normal path. But, if you have the rights to create links in those paths, why not simply install the thing and be done with it. And Making lists of existing links so they can be restored afterwards?? That is really hacky, too -it makes the underlying programs unavailable as long as you app is running -I mean if linking to your app has deleted any existing links -and what if they are really applications instead of just links?
"0/run $@ & # run app. hook file
$@
0/$PKG.run &" You may need a shebang at the top, although I think it may be that $1 or $@ is empty -is your AppRun being executed with parameters? -like AppRun name-of-proggie.
I'm gonna try to extend this all into a small tutorial which will start out with the most basic 'WrapDir' and then go step-by-step to more complex usage. Here's one tip, if you pepper your code with echo statements(with useful output) and then execute the thing from a terminal, then you can get some quick debug output -simply cd into the AppDir, open a terminal and run`./AppRun` or `./AppRun arguments`. In particular, you can easily check if all your vars are being expanded the way you envision it.
It's late here in the Rhein/Main region(still keeping you guessing...), so you'll have to 'make do' with this for today -unless your still up after (your) midnight when I start all over tomorrow.
Wait, a tantalizing preview of how we distinguish between a simple left-click on the icon, a right-click(or run AppRun with args) and dropping multiple files on the icon:
Code: Select all
if [[ $# = 0 ]] ; then
# What to do if icon is simply clicked.
# your code here
elif [[ $1 == '--help' ]] ; then
# option where args have been passed to AppRun or from
# right-clicking and choosing a menu item(specified in the AppIbfo.xml)
# your code here
elif [[ $1 == '--showvolume' ]] ; then
# another as above -as many of these as you want
# your code here
elif [[ $# > 0 ]] ; then
# '$#' means the number of command-line arguments(positional parameters) passed -when you drop files on the icon, then they are each treated as a positional parameter
for item in $@ ; do
# do something here with each item
# now if we just had an idea for this... Actually, several of my AppDirs use this
done
Now I`m peaked... Abilene or San Angelo for pretty girls? Or Odessa or Midland?
Superstition Mountain, and behind it is the Superstition range of mountains.
Home of Jacob Waltz`s Lost Dutchman`s gold mine ( Lost Peralta mine.).
I think we`re crossed up, Sq. file`s mounted in /tmp, the $HOME is in /(AppPkg)/$HOME.
The app mount needs to be globally accessible? But $HOME is property of the user.
Code after exec would be pointless, so " &" does the work of both. I`ve never used exec.
Sunflower needs Devx for Python ( no prob.) and PyGTK from dotpups.de/puppy5/racy:
pygtk-2.24.0-i486.pet, pygobject-2.21.3-i486.pet, py2cairo-1.10.0-i486.pet
I`m using Precise-5.3 so it`s hard to say if this build will work in it.
Yes, open html in browser or editor? Right click is very useful, as is text tips.
I loved V.B. for it`s text tips use "hover over a variable in the editor and it shows the value.
And if you swipe highlighted a section of code it would show it`s value also. Very nice!
After almost 20 years you`d think Linux in general would have something to compare with it.
"find /usr -xtype l -delete" It deletes dead links only! This could possibly be a problem.
I checked /root and there were 5 dead links, one was trash, but the other 4 may "work".
Create app links, then at each boot, bg & delay run script deleting dead links in "our dirs".
Yes, you`ll have to demo. "getting around" permissions on "normal" Linux distros for me.
Yes, setup script has shebang, but run script doesn`t ( exec.). Run is only 15 bytes total.!
Yes, setup is run with the app`s exec. file and args. If no arg., setup unmounts the Sq. file.
My setup script above has 2 "report" echos in it, very useful. I just leave them in the code.
Preview looks good, use getopts ( looks to be messy ) to parse the options from the string.
Too bad GtkDialog has no right-click event for most of it`s widgets ( and many other events ).
I wanted to try making a Filer with it, but as usual it`s fubar and I get discussed with it.
# How can a script enable redirecting an access to a dir.? File accesses won`t help much.
.
Superstition Mountain, and behind it is the Superstition range of mountains.
Home of Jacob Waltz`s Lost Dutchman`s gold mine ( Lost Peralta mine.).
I think we`re crossed up, Sq. file`s mounted in /tmp, the $HOME is in /(AppPkg)/$HOME.
The app mount needs to be globally accessible? But $HOME is property of the user.
Code after exec would be pointless, so " &" does the work of both. I`ve never used exec.
Sunflower needs Devx for Python ( no prob.) and PyGTK from dotpups.de/puppy5/racy:
pygtk-2.24.0-i486.pet, pygobject-2.21.3-i486.pet, py2cairo-1.10.0-i486.pet
I`m using Precise-5.3 so it`s hard to say if this build will work in it.
Yes, open html in browser or editor? Right click is very useful, as is text tips.
I loved V.B. for it`s text tips use "hover over a variable in the editor and it shows the value.
And if you swipe highlighted a section of code it would show it`s value also. Very nice!
After almost 20 years you`d think Linux in general would have something to compare with it.
"find /usr -xtype l -delete" It deletes dead links only! This could possibly be a problem.
I checked /root and there were 5 dead links, one was trash, but the other 4 may "work".
Create app links, then at each boot, bg & delay run script deleting dead links in "our dirs".
Yes, you`ll have to demo. "getting around" permissions on "normal" Linux distros for me.
Yes, setup script has shebang, but run script doesn`t ( exec.). Run is only 15 bytes total.!
Yes, setup is run with the app`s exec. file and args. If no arg., setup unmounts the Sq. file.
My setup script above has 2 "report" echos in it, very useful. I just leave them in the code.
Preview looks good, use getopts ( looks to be messy ) to parse the options from the string.
Too bad GtkDialog has no right-click event for most of it`s widgets ( and many other events ).
I wanted to try making a Filer with it, but as usual it`s fubar and I get discussed with it.
# How can a script enable redirecting an access to a dir.? File accesses won`t help much.
.
"Abilene or San Angelo for pretty girls? Or Odessa or Midland? " You do seem to know the neighborhood. Actually, it's Big Spring -pronounced 'Beg Sprangs' in the local dialect. Be sure to add alittle twang when you pronounce that and it helps to achieve the proper drawl if, while pronouncing it, you roll your jaw the way a cow does when chewing its cud -nice slooowww figure-eights...
"I think we`re crossed up" Yeah, I don't understand what you are trying to do there. If something needs access to $HOME then it can access it directly -there's no need to recreate, link or bind to the users $HOME.
"use getopts ( looks to be messy )" I hate getopts and never use it. In fact, remembering what we were doing with Chrome AppDir, I think I patched the use of getopts out of fakeroot or fakechroot.
"How can a script enable redirecting an access to a dir.?" You can only do that with a union mount/fs. This why I pointed out (in example AppRun) that modifying PATH and/or LD_LIBRARY_PATH will only work for programs which don't access /usr/share, /var/?? or /etc (or /usr/etc). When programs are compiled, these paths get hard-coded into the application. Modifying the PATH is a message to *the shell* about where programs should searched for. Modifying LD_LIBRARY_PATH is a message to ld-linux.so about where to look for libraries when dynamically linking the program before executing it.
For proggies which need to access a modified path to /etc/ /usr/share ,etc., you have three choices: configure and compile the applications to use the modified paths you want (or with relative paths where possible), edit pre-compiled binaries to reflect the altered paths(this is what PortableApps AppImage does), or use a union mount to redirect access to any path -whether directory or file.
You might really want to check out AppImage as it does a lot of what you want and has a GUI helper (AppImageKit) for creating them. It does rely heavily on Python, but you seem to not mind that. I personally do not like using python stuff and avoid it nearly as much as java... AppImage does something interesting, it embeds a filesystem image(iso) behind and ELF header, so that the finished product is a single file which, when run, fuse-mounts the internal image and executes the wanted program inside -kind of like a self-extracting archive except that the content is fuse-loop-mounted instead of being extracted.
"I think we`re crossed up" Yeah, I don't understand what you are trying to do there. If something needs access to $HOME then it can access it directly -there's no need to recreate, link or bind to the users $HOME.
"use getopts ( looks to be messy )" I hate getopts and never use it. In fact, remembering what we were doing with Chrome AppDir, I think I patched the use of getopts out of fakeroot or fakechroot.
"How can a script enable redirecting an access to a dir.?" You can only do that with a union mount/fs. This why I pointed out (in example AppRun) that modifying PATH and/or LD_LIBRARY_PATH will only work for programs which don't access /usr/share, /var/?? or /etc (or /usr/etc). When programs are compiled, these paths get hard-coded into the application. Modifying the PATH is a message to *the shell* about where programs should searched for. Modifying LD_LIBRARY_PATH is a message to ld-linux.so about where to look for libraries when dynamically linking the program before executing it.
For proggies which need to access a modified path to /etc/ /usr/share ,etc., you have three choices: configure and compile the applications to use the modified paths you want (or with relative paths where possible), edit pre-compiled binaries to reflect the altered paths(this is what PortableApps AppImage does), or use a union mount to redirect access to any path -whether directory or file.
You might really want to check out AppImage as it does a lot of what you want and has a GUI helper (AppImageKit) for creating them. It does rely heavily on Python, but you seem to not mind that. I personally do not like using python stuff and avoid it nearly as much as java... AppImage does something interesting, it embeds a filesystem image(iso) behind and ELF header, so that the finished product is a single file which, when run, fuse-mounts the internal image and executes the wanted program inside -kind of like a self-extracting archive except that the content is fuse-loop-mounted instead of being extracted.
Lots of good info! Had a friend from Abilene, Mona was her name, she`d say: Howwwdy!
My thought was the $HOME files be in the AppPkg like everything else. No Tracking needed.
Dead link removal, bg and delayed 60 sec., boot is faster and user has time to start apps. too.
Do a dead link cleanup on all "install" dirs: /etc, /opt, /var, /usr/share, $HOME. Any others?
My thought again is to keep the base os clean with only daemons, services, and utilities.
getops sucks... I agree, tried it once and that`s that.! I wrote a function that`s much better.
Got AppImage but it won`t run, probably Python deps. Most apps on the 2 sites no work also.
Lots of good Java apps? I`d have it installed. Same for everything else that`s not too heavy.
I`m told special compiling doesn`t work on all apps, and binary edit is even less successful.
Poorly written apps and no set stds, messy. With relative paths the app lives in the AppDir.
So, fix every app you wanna use ( Ha Ha Ha ), or make app setup as compliant as possible.
I don`t like the messiness of links, but no app modding is needed, and apps start pretty fast.
Like a better TinyCore, only link the apps, not the entire O.S.! And a similar easy cleanup.
# How to bypass permissions in a "normal" Linux so apps can make links? sudo or su ?
I found out that "cp -s" only links files, not dirs. What a crock.! So I`m using both cp and ln.
I wrote a cross-link function, it links end of an existing path to a duplicate path in the AppDir.
6ms fast because no exec. calls until loop ends. Use to link some dirs., and use cp -s for files.
My thought was the $HOME files be in the AppPkg like everything else. No Tracking needed.
Dead link removal, bg and delayed 60 sec., boot is faster and user has time to start apps. too.
Do a dead link cleanup on all "install" dirs: /etc, /opt, /var, /usr/share, $HOME. Any others?
My thought again is to keep the base os clean with only daemons, services, and utilities.
getops sucks... I agree, tried it once and that`s that.! I wrote a function that`s much better.
Got AppImage but it won`t run, probably Python deps. Most apps on the 2 sites no work also.
Lots of good Java apps? I`d have it installed. Same for everything else that`s not too heavy.
I`m told special compiling doesn`t work on all apps, and binary edit is even less successful.
Poorly written apps and no set stds, messy. With relative paths the app lives in the AppDir.
So, fix every app you wanna use ( Ha Ha Ha ), or make app setup as compliant as possible.
I don`t like the messiness of links, but no app modding is needed, and apps start pretty fast.
Like a better TinyCore, only link the apps, not the entire O.S.! And a similar easy cleanup.
# How to bypass permissions in a "normal" Linux so apps can make links? sudo or su ?
I found out that "cp -s" only links files, not dirs. What a crock.! So I`m using both cp and ln.
I wrote a cross-link function, it links end of an existing path to a duplicate path in the AppDir.
6ms fast because no exec. calls until loop ends. Use to link some dirs., and use cp -s for files.
Code: Select all
################ Find the Path Difference, and Make a Link.
List='/root
/etc
/opt
/var'
link() {
Path=$APP$Base # APP = mnt. or app. dir.
find $Path |while read P
do
R=${P/*$Base/$Base}
[ -d /$R ]&& continue
# ln -s $P $R ; break
echo "L $P $R" ; break
done
}
echo "$List" |while read Base ;do link ;done