[Solved] links in ~/.X.d/ don't work, a small change to Xlibs.tcz fixes it

[GNUser]

I was surprised today when I put a link to a shell script in ~/.X.d/ and there was no effect (i.e., the script did not run at boot).

It turns out the problem is this line in /etc/skel/.xsession (part of the Xlibs.tcz extension):

Code: [Select]

[ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f | while read F; do . "$F"; done
The fix is to change the line to this:

Code: [Select]

[ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -o -type l | while read F; do . "$F"; done
I think the change adds some small value to the extension, so I'll submit my tweaked version for the repo.

[Rich]

Hi GNUser
~/.X.d/  is supposed to be used to launch processes after X has started, not execute scripts directly line by line. The
correct way to do this is create a file in  ~/.X.d/  that contains:

Code: [Select]

MyScript &This way when your script is launched it can't block other processes from starting.

[GNUser]

Thanks, Rich. I know. All my shell scripts are in a single directory (/opt/scripts), including ones called "jobs-startup" and "jobs-suspend".  "jobs-startup" does indeed put most things in the background in order not to hold up the boot process.

I really appreciate TCL's "no scatter" philosophy and would rather keep all my scripts in one place, with symlinks everywhere else. Using a symlink in this specific case also makes my life easier because my /opt is persistent but /home is not (i.e., any time I change ~/.X.d/ I need to create a new backup).

The workaround I had been using was to create ~/.X.d/jobs-startup containing only "exec /opt/scripts/jobs-startup", but a symlink seems more elegant.

Anyway, I thought it wouldn't hurt for ~/.X.d/ to be more flexible and allow symlinks. If tweaked extension seems pointless or harmful, no need to post it. Sorry for the noise.

[curaga]

I think the change is fine.

[jazzbiker]

Hi, Core people!

If You go tweaking .xsession I want to propose  a small tweak too

Code: [Select]

[ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -o -type l | sort | while read F; do . "$F"; done
to make scripts execution order fully predictable.

Regards!

[GNUser]

Hi, jazzbiker. Wow, that's a great idea, a simple way of making .xsession even more better I re-submitted tweaked Xlibs.tcz to include your idea.

[jazzbiker]

Hi, GNUser!
I'm glad You enjoyed this tweak, I expect it rather natural and this is the very first patch I'm applying to every fresh install of TinyCore making use of X. But I've proposed it earlier in http://forum.tinycorelinux.net/index.php/topic,2588.0.html thread. Maybe it will be better to wait for Curaga's or Juanito's approval?
Hope You applied this sort to ~/.X.d only, not to /usr/local/etc/X.d?

[GNUser]

Hi, jazzbiker. I added the sort command to both user and etc lines for consistency. Juanito can easily remove it from the etc line if he doesn't like it, or I'll be happy to revise the extension and resubmit it.

[jazzbiker]

Oh, in the above mentioned thread I gave my considerations on /usr/local/etc/X.d scripts sorting. Look, "find" command lists files in the reverse creation order. So /usr/local/etc/X.d scripts wiil be executed according to the reversed extensions' order in Your onboot.lst, and if You need, You can adjust the sequence of scripts' execution swapping the extensions in Your onboot.lst. But "sort" in .xsession applied to /usr/local/etc/X.d will eliminate this possibility. Sorry for disturbing You, but I will kindly ask You to resubmit the extension without the "sort" in the /usr/local/etc/X.d chain, of course if You agree that the above mentioned effect can be harmful.

[GNUser]

Haha, okay. I submitted three versions of tweaked Xlibs.tcz:

1. support for links in ~/.X.d
2. support for links in ~/.X.d, sort in $HOME/.X.d line, sort in /usr/local/etc/X.d line
3. support for links in ~/.X.d, sort in $HOME/.X.d line (no change to /usr/local/etc/X.d line)

Third option is most likely to add value without introducing any breakage.

[jazzbiker]

Thanks!

Sorry, I'd underestimated Your submitting pace :-) I expected we are starting discussion, while You've already submitted the target twice :-) Hope my intervention in the process will not be the waste of time :-)

[GNUser]

I'd underestimated Your submitting pace :-) I expected we are starting discussion, while You've already submitted the target twice :-)

Nobody has ever been able to accuse me of being the bottleneck in a team effort

I wanted to make it as easy as possible for the developers to update the extension. Now they have three versions and can choose the one they think will work best for everybody. Hopefully we can have all the features we want with no breakage for anyone.

[andyj]

Consistent and predictable behavior is the key, and should be the goal. If we're going to sort (which would give us predictability), then sort both /usr/local/etc/X.d (which theoretically system should come before personal) and $HOME/.X.d second for consistency. ~/.X.d is usually the same as $HOME/.X.d, but not necessarily, so to avoid confusion should not be used. Otherwise you would need to determine if they are the same or not to prevent scripts from being executed twice.

[jazzbiker]

Hi, andyj!

Predictability needs to be accompanied with controllability. The user can change the ~/.X.d/* names and achieve desirable execution order, using sort. But /usr/local/etc/X.d/* are coming from extensions, their names are defined by extensions' maintainers, and their execution order can be controlled by changing extensions loading order in onboot.lst, though invoking them through sorting will leave us with predictability ohne controllability.

[andyj]

Actually the files in /usr/local/etc/X.d won't be executed until .xsession is run when X starts which is after all extensions are loaded, not as the extensions are loaded so extension load order will not have any effect. It is also worth noting that an extension that has a file in /usr/local/etc/X.d will not be executed if it is loaded after X has started. The execution order in /usr/local/etc/X.d could be controlled by using names that start with numbers 00 through 99 like udev rules, but that is really only necessary if there is some kind of dependency between extensions. In that case it should fall on the extension maintainers to coordinate the order of their scripts through naming. How many scripts in /usr/local/etc/X.d are we talking about anyway? I know of one, because I started this way back when: http://forum.tinycorelinux.net/index.php/topic,22312.0.html, so this apparently was not an issue until then.