`ble/term.sh:` updating tput cache for TERM=xterm-256color... done

[ghost]

I get this the first time I open a terminal after reboot like everytime. Is this normal ? How can I avoid this message being printed each time I reboot & open terminal for 1st time ?

[akinomyoga]

Thank you for the report! This is unexpected. Could you tell me the result of the following commands in a ble.sh session?

$ echo "$_ble_base_cache"
$ ls -la "$_ble_base_cache"
$ df "$_ble_base_cache"

Also, what would be shown when you press C-x C-v in a ble.sh session?

[ghost]

Thank you for the report! This is unexpected. Could you tell me the result of the following commands in a ble.sh session?

$ echo "$_ble_base_cache"
$ ls -la "$_ble_base_cache"
$ df "$_ble_base_cache"

Also, what would be shown when you press C-x C-v in a ble.sh session?

$[~]$ echo "$_ble_base_cache"
/home/mpk/.cache/blesh/0.3
$[~]$ ls -la "$_ble_base_cache"
total 88
drwx------ 2 mpk mpk   200 Aug 10 02:46 .
drwx------ 3 mpk mpk    60 Aug 10 02:46 ..
-rw-r--r-- 1 mpk mpk 30687 Aug 10 02:46 ble-decode-bind.50116.UTF-8.bind
-rw-r--r-- 1 mpk mpk 11724 Aug 10 02:46 ble-decode-bind.50116.UTF-8.unbind
-rw-r--r-- 1 mpk mpk  6022 Aug 10 02:46 cmap+default.4.xterm-256color.dump
-rw-r--r-- 1 mpk mpk  2686 Aug 10 02:46 cmap+default.binder-source
-rw-r--r-- 1 mpk mpk  8638 Aug 10 02:46 cmap+default.binder-source.bind
-rw-r--r-- 1 mpk mpk  2198 Aug 10 02:46 cmap+default.binder-source.unbind
-rw-r--r-- 1 mpk mpk  9696 Aug 10 02:46 keymap.emacs
-rw-r--r-- 1 mpk mpk  1956 Aug 10 02:46 xterm-256color.term
$[~]$ df "$_ble_base_cache"
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs            8162012 46596   8115416   1% /tmp
$[~]$ 
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) with ble.sh
$[~]$

Also I'm on Arch & I'm having my local cache linked to tmpfs for security & performance reasons. Would that be a reason for this line print?

 $[~]$ ls -la ~/.cache
lrwxrwxrwx 1 mpk mpk 4 Aug  7 07:56 /home/mpk/.cache -> /tmp

For this instance, I'm on non-git stable version (not alpha). Or does it exist on alpha & should I need to try from latest git?

[akinomyoga]

OK, so your cache directory is located in tmpfs. This is the reason that the cache is lost every time on a reboot.

Would that be a reason for this line print?

Yes.

$[~]$ ls -la ~/.cache
lrwxrwxrwx 1 mpk mpk 4 Aug  7 07:56 /home/mpk/.cache -> /tmp

Your setup has a security issue. /tmp is usually visible to all users, so other users can see the filenames of your cache files. Also, the permission of ~/.cache is set to 700 in normal cases, which means that the permissions of cache files therein don't have to be set up in normal cases. So, also the contents of your cache files are probably visible to all the users.

For this instance, I'm on non-git stable version (not alpha). Or does it exist on alpha & should I need to try from latest git?

The reported behavior wouldn't change between ble-0.3 and ble-0.4 (master).

[ghost]

Tq for confirmation. Btw I don't mind about tmp userspace caching as I'm the only user on my machine & would rather have cache rebuild each time. Is there any other way to supress the tput cache message on the start ? Like supressing the line prints https://github.com/akinomyoga/ble.sh/blob/560160b0408a28e5ebb8b45a6ff84ef2a4aa590a/lib/init-term.sh#L301

[akinomyoga]

Is there any other way to supress the tput cache message on the start ?

For example, you can set a temporary XDG_CACHE_HOME when sourcing ble.sh:

# bashrc

XDG_CACHE_HOME=/path/to/alternative/cache/directory/on/disk source /path/to/ble.sh ....

# Edit: For example, if you install ble.sh to the default location in ~/.local, you can write as
XDG_CACHE_HOME=~/.local/share/blesh/cache.d source ~/.local/share/blesh/ble.sh ....

[ghost]

Is there any other way to supress the tput cache message on the start ?

For example, you can set a temporary XDG_CACHE_HOME when sourcing ble.sh:

# bashrc

XDG_CACHE_HOME=/path/to/alternative/cache/directory/on/disk source /path/to/ble.sh ....

This is quite a big ask but, does this print actually help user in any way? https://github.com/akinomyoga/ble.sh/blob/560160b0408a28e5ebb8b45a6ff84ef2a4aa590a/lib/init-term.sh#L301 Just curious if it's viable to not have it.

[akinomyoga]

This is quite a big ask but, is this print actually help user?

The tput-cache creation sometimes takes from several to ten seconds depending on the operating system and the current status of the system. Without the messages, it appears to be hanging from the user's perspective in such a case.

[ghost]

The tput-cache creation sometimes takes from several to ten seconds depending on the operating system and the current status of the system

Well, that's a strange issue though. I wonder why a direct console print would solve service hangs. Wouldn't https://github.com/akinomyoga/ble.sh/blob/560160b0408a28e5ebb8b45a6ff84ef2a4aa590a/lib/init-term.sh#L300 be enough to initialize xterm ?

[akinomyoga]

It doesn't resolve the hang, but the message provides the user with information about what is blocking.

[akinomyoga]

Wouldn't

https://github.com/akinomyoga/ble.sh/blob/560160b0408a28e5ebb8b45a6ff84ef2a4aa590a/lib/init-term.sh#L300

be enough to initialize xterm ?

Why? Or what do you mean actually? The speed of tput is unrelated to whether the current TERM is xterm or not.

[ghost]

It doesn't resolve the hang, but the message provides the user with information about what is blocking.

But line 301 doesn't give any info about what's blocking right? It just about mentioning tput cache updation.

[akinomyoga]

But line 301 doesn't give any info about what's blocking right? It just about mentioning tput cache updation.

What do you mean? It tells the user that tput-cache updating is currently running. If it takes time, the user can correctly guess that the currently running tput-cache updating is blocking for a while.

Edit: see line 299. Line 301 just updates the line that has already been outputted by line 299.

[ghost]

Okay it seems that it's really needed. This is just a minor cosmetic issue for me btw.

[akinomyoga]

OK, thanks for the report again.