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

[jazzbiker]

Hi, andyj!

I didn't knew, that this /usr/local/etc/X.d chain in .xsession is Your contribution :-) Great thing, surely! It was added not long ago and that is why it is not widely used by maintainers, I think it needs to be promoted, but I don't know how - wiki is down :-( I must say, that some topics were dedicated exactly to troubles, which could be cured using this per-extension X startup scripts. One of the examples is terminus-fonts.tcz, I use it every day and it needs manually created script in ~/.X.d, however this manual action could be avoided by adding corresponding /usr/local/etc/X.d script to the extension. If I am not mistaken, /usr/local/etc/X.d is the right place for all the fonts caching calls. Probably there are another common cases for this directory use.

Of course I realize, that /usr/local/etc/X.d scripts will be executed only at X startup. I was mentioning that their invocation order (at X startup) will be the reverse load order in onboot.lst, because their links are created inside /usr/local/etc/X.d during tce-load and consequent "find ... " (in .xsession) will list them in reverse creation order. Maybe it is filesystem dependent behaviour, I'm using ext4 and didn't tested the others.

Regards!

[jazzbiker]

In that case it should fall on the extension maintainers to coordinate the order of their scripts through naming.

Sorry, but I think it will seed the problems in the future. And if maintainers will use this fine possibility (per-extension X starup scripts) wider (I expect this the right way) all the possible future inconsistencies are inpredictable (projects are being updated and upgraded) and the user must have the ability to eliminate them with his own tools, I believe. Of course this is only an opinion.

Thanks!

[andyj]

If we "ls" /usr/local/etc/X.d we get one order of files, if we "find" we get another. One order is observable, the other is theoretically knowable but not without research. I was a little short sighted when I submitted the patch for /usr/local/etc/X.d in that I did not sort the results as my one file did not need sorting. Now I can see that if it was sorted using "sort" then when someone looked at a directory listing (using default sort) for /usr/local/etc/X.d they would see the files in execution order and there would be a lot less confusion and questions. Load order would be okay and would make sense if it was the order displayed by "ls", but one has to know to use a different command "find" to see that. I contend that showing one thing and doing something else will be perceived as wrong, as it apparently it is now by some. It should be intuitive, and I think that numbering files and sorting is how we can do that. Sadly, there just are not enough maintainers that this might be a problem. The fact that there are relatively few makes coordination a lot simpler than it might otherwise seem.

If this is really an issue, then try something like what I use in /opt/bootlocal.sh for files in /usr/local/etc/init.d instead:

Code: [Select]

for a in web-firewall openssh open-vm-tools php-fpm nginx; do
        [ -x /usr/local/etc/init.d/$a ] && /usr/local/etc/init.d/$a start &
done
It should be easy enough to adapt this approach for /usr/local/etc/X.d as well.

[jazzbiker]

One order is observable, the other is theoretically knowable but not without research.

Can the next be named "research" :-)

Code: [Select]

tc@box:~$ mkdir tmp; cd tmp
tc@box:~/tmp$ touch 1; touch 7; touch 3
tc@box:~/tmp$ find . -type f
./3
./7
./1
tc@box

?

I'm claiming, that Your patch is excellent, but You don't agree :-) Let's don't repair what's not broken!

[Rich]

Hi jazzbiker
Are you using  busybox find  or  GNU find?
Do they both behave the same way?

Code: [Select]

tc@E310:~$ mkdir count
tc@E310:~$ cd count/
tc@E310:~/count$ touch 1; touch 7; touch 3
tc@E310:~/count$ find . -type f
./7
./3
./1
tc@E310:~/count$ which find
/usr/bin/find
tc@E310:~/count$ ls -l /usr/bin/find
lrwxrwxrwx 1 root root 17 Jun  9  2019 /usr/bin/find -> ../../bin/busybox
tc@E310:~/count$ tce-load -i findutils
findutils.tcz: OK
tc@E310:~/count$ which find
/usr/local/bin/find
tc@E310:~/count$ ls -l /usr/local/bin/find
lrwxrwxrwx 1 root root 40 Dec 20 11:58 /usr/local/bin/find -> /tmp/tcloop/findutils/usr/local/bin/find
tc@E310:~/count$ find . -type f
./7
./3
./1
tc@E310:~/count$
On my machine (TC10 32 bit),  busybox find  and  GNU find  behave the same way. However, they produce a different
result than your machine.

[jazzbiker]

Hi, Rich!

This moment I use TC10 x86.

Code: [Select]

tc@box:~/count$ version
10.1
tc@box:~/count$ uname -a
Linux box 4.19.10-tinycore #1999 SMP Tue Dec 18 13:36:47 UTC 2018 i686 GNU/Linux
tc@box:~/count$ busybox | grep v1
BusyBox v1.29.3 (2020-07-04 15:39:28 EEDT) multi-call binary.
tc@box:~/count$ ls -l $(which find)
lrwxrwxrwx    1 root     root            17 Jul  4 15:55 /usr/bin/find -> ../../bin/busybox
tc@box:~/count$

Thanks for checking. Can I please ask You to provide one more test?

Code: [Select]

tc@box:~$ mkdir count
tc@box:~$ cd count
tc@box:~/count$ touch 1; sleep 1; touch 7; sleep 1; touch 3
tc@box:~/count$ find . -type f
./3
./7
./1

P.S. In my opinion this aspect of "find", "ls" ... behaviour depends on libc.

[Rich]

Hi jazzbiker

Code: [Select]

tc@E310:~$ mkdir count
tc@E310:~$ cd count
tc@E310:~/count$ touch 1; sleep 1; touch 7; sleep 1; touch 3
tc@E310:~/count$ find . -type f
./7
./3
./1
tc@E310:~/count$ busybox find . -type f
./7
./3
./1
tc@E310:~/count$
tc@E310:~/count$ busybox | grep v1
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.
tc@E310:~/count$ version
10.1
tc@E310:~/count$
My busybox has the same version number but a different date code.

[jazzbiker]

Thanks!

But now I can not understand, what's the difference between our systems and the "find" behaviour. busybox build date is different because I was patching vi (if I'm not mistaken).

Does this looks like for Your system?

Code: [Select]

tc@box:~/count$ ls
1  3  7
tc@box:~/count$ ls -u
3  7  1

I use default TC ~ residing in memory. U2?

[Rich]

Hi jazzbiker

... Does this looks like for Your system? ...

Yes, I get the same results for both the  busybox  and the  GNU  versions of  ls.

... I use default TC ~ residing in memory. U2?

No, I run persistent /home and /opt on all of my systems.

Code: [Select]

tc@E310:~/count$ cd /tmp/
tc@E310:/tmp$ mkdir count
tc@E310:/tmp$ cd count/
tc@E310:/tmp/count$ touch 1; sleep 1; touch 7; sleep 1; touch 3
tc@E310:/tmp/count$ find . -type f
./3
./7
./1
tc@E310:/tmp/count$ busybox find . -type f
./3
./7
./1
tc@E310:/tmp/count$
It seems the RAM file system behaves differently from one on a hard drive.

[andyj]

It looks like everyone is making my argument for me Maybe we should use sort and get consistent results for all?

[jazzbiker]

@Rich
So, how sad this appears to be, find's behaviour is fs-type dependent and can not be relied on :-( Looks like its output is already sorted by name on hd and unsorted for RAM. Thanks for testing. If You tracked this topic, what's Your opinion about these sort's in .xsession? Probably andyj is using persistent ~ too.

[jazzbiker]

It looks like everyone is making my argument for me Maybe we should use sort and get consistent results for all?

Yes, it looks like ;-( persistent home beats memory.

[jazzbiker]

GNUser, sorry for disturbing and making so many noise.

[andyj]

Probably andyj is using persistent ~ too.

No persistence for any directory in /:

Code: [Select]

tc@box:~$ cd /mnt/sda1
tc@box:/mnt/sda1$ la
total 52
drwxr-xr-x   11 root     root          4096 Dec 31  2019 ./
drwxrwxr-x    6 root     staff          120 Dec 20 23:00 ../
drwxr-xr-x    3 tc       staff         4096 May  1  2020 boot/
drwxr-xr-x   12 tc       staff         4096 Sep  3 12:03 lamp/
drwxr-xr-x   13 tc       staff         4096 Nov  7 15:08 lamp32/
drwsrwxrwx   13 tc       staff         4096 Nov  6 19:30 lamp64/
drwx------    2 root     root         16384 Dec 21  2018 lost+found/
drwxrwxr-x    3 tc       staff         4096 Feb 14  2020 tce32-10/
drwxrwxr-x    4 tc       staff         4096 May 27  2020 tce32-11/
drwxrwxr-x    3 tc       staff         4096 Feb 14  2020 tce64-10/
drwxrwxr-x    4 tc       staff         4096 Nov 27 04:39 tce64-11/
tc@box:/mnt/sda1$ df
Filesystem                Size      Used Available Use% Mounted on
rootfs                    7.0G    226.1M      6.8G   3% /
tmpfs                     3.9G         0      3.9G   0% /dev/shm
/dev/sda1                31.1G     22.8G      8.3G  73% /mnt/sda1
vmhgfs-fuse               1.8T      1.6T    182.7G  90% /mnt/hgfs/andy-home
vmhgfs-fuse               2.7T      1.8T    929.9G  66% /mnt/hgfs/bax2
tc@box:/mnt/sda1$
Just a lot of boot options for maintaining extensions across various releases.

[jazzbiker]

I've made some testing on USB ext4 drive and must say that I can not describe how "find" is sorting its output. It acts independent on name, date, inode and so on. Without digging into sources nothing can be said. So andyj's proposal to sort the find's output is the way to bring predictability, otherwise the same extensions' set will behave differently in the different environments, which is very undesirable, so I vote for sorting both find's in .xsession.

P.S. Of course /usr/local/etc/X.d resides in memory unconditionally for TC, but seems that relying on unprocessed find's output is unacceptable.