Possible race condition when using remote commands at startup

[SPFabGerman]

When starting lf, it ignores sometimes remote commands that are in the rc file.
E.g. when I have something like $lf -remote "send $id echo TEST" in my lfrc file, the TEST is only displayed around half the time.
It is possible to somewhat work around that, by using something like this: &sleep 1; lf -remote "send $id echo TEST", but this will still not have a guaranteed success.
This is especially problematic, when setting up mappings using remote commands, since the mapping will simply not be available.

This looks like a race condition with the server startup to me.
So sometimes the server is not ready to accept remote commands and so the command is simply dropped.

I tested a bit more and found, that the ´lf -remote ...´ command exits without any errors, even if the command was dropped.

This issue was not always present, since on an earlier version of lf (r14, if I remember correctly) everything worked fine.

[gokcehan]

@SPFabGerman I have taken a look at this now. I can reproduce the issue as early as r14. I think you are right that it is related to server not being ready when a remote command is run. It is possible to get rid of this issue by starting the server manually beforehand, maybe from within a desktop launch script or so. There has also been some recent changes with the server behavior. Remote command errors are now shown as output. So alternatively you can use the following to try the command until success (currently this should only work in master):

&while [ -n $(lf -remote "send $id echo TEST") ]; do sleep 1; done

I have also replaced load and save commands with a local file instead. So without load command, we could try to consider any output as error and return a non-zero exit code which would then make the following possible though it is not so different than the above solution:

&until lf -remote "send $id echo TEST"; do sleep 1; done

We could also move this logic to the remote commands to try commands until success with increasing intervals but I'm not sure if this is always desirable.

I'm inclined to think that the current first method is good enough for now.

[SPFabGerman]

I think having error messages on stderr and returning a non-zero exit status is the best solution for this problem. That could be integreated very well in various shell scripts, etc..
Moving this into the remote command logic seems unnecessary complex and starting the server beforehand in a script would be a solution, but I don't really like that, since it requires to makes lf less standalone. (If that makes sense.)

Maybe it would be a good idea to have kind of a wait command, that waits until the server is ready. Then the user could simply use that command once when needed and don't wory about the rest. It also would avoid the command beeing repeated over and over again and would therefor avoid busy waiting.

[gokcehan]

@SPFabGerman I have taken a look at the code now. It seems that non-zero return code should already be the case when the server is not ready. So the following example should already work:

&until lf -remote "send $id echo TEST"; do sleep 1; done

But it doesn't work. The reason is that when the server is not ready, client keeps trying to connecting with increasing intervals. If this remote command arrives before the client connects to the server but after the server starts running, command is silently dropped since there is no client connection exists on the server to send the command. I will try to add an error message for this case. Returning a non-zero code for such errors on the server side is more complicated and I don't have an easy way to do it yet. I'm still not sure if it is a good idea to assume any returned message should be considered an error.

I'm not sure how a wait command would work for the case when the server is not yet started as there is no way to process a wait command either when the server is not ready.

[illia-danko]

Maybe it's related or a separate issue. I ended up with a command as a such:

cmd fzf-jump ${{
    set -f
    res="$(fzf --preview 'bat --style=numbers --color=always --line-range :500 {}')"
    lf -remote "send $id select \"$res\""
    lf -remote "send $id open \"$res\""
}}
map <c-t> fzf-jump

Occasionally, but steady the execution is failed on the second remote command and it's only selected a file on ui. Note, I run lf binary from the lfcd.sh from the documentation.

[gokcehan]

@iDanko This issue is about commands at startup so I don't think your issue is related. By the way, I don't remember open command taking an argument which may or may not be related to your issue.