[Feature Request] Command to wait previous command

[andry81]

Additionally to `cm_Wait` add `cm_WaitPrev`.
Useful to runs an external command, wait it's completion and continue with the next one.

[Fla$her]

It's useful, but not in the case of scripts where there is asynchronous execution (such as start "" program.exe in .bat) or something that is executed in a separate thread.
In any case, I support it. I had such thoughts, but I imagined it a little differently: em_Name(1)

[andry81]

2Fla$her
The `start` can wait too: `start /B /WAIT "" "command"`

On another hand, you can add something like `cm_WaitProcId <id>`, where `<id>=-1` or `<id>=PrevCommand` is a previous command child process id.

[Fla$her]

2andry81
I only gave start as an example. There are situations (with other programs) that cannot be debugged on their own.

[andry81]

I only gave start as an example. There are situations (with other programs) that cannot be debugged on their own.

I am not sure that you mean. Debugged for what?

[Fla$her]

where `<id>=-1` or `<id>=PrevCommand` is a previous command child process id.

And how will it work if the PID is new every time?

Debugged for what?

To prevent the output of program functions to a separate thread.

[andry81]

where `<id>=-1` or `<id>=PrevCommand` is a previous command child process id.

And how will it work if the PID is new every time?

The child process running by a previous command will always has a different PID, why it should has the same? You have to wait on that pid to wait the process exit.

To prevent the output of program functions to a separate thread.

Do you mean to a separate console? Otherwise an external command has to run in a separate process with a standalone console, how else? It is not even related to the Total Commander.

[Fla$her]

The child process running by a previous command will always has a different PID, why it should has the same? You have to wait on that pid to wait the process exit.

You don't seem to understand my question. I'm asking about the practical applying of cm_WaitProcId <id>. Do you propose to find out the PID and change the button/command for this every time? I don't see any practical benefit in this when building chains of commands.

Do you mean to a separate console?

No, a certain function (including a cyclic one) of the program can be allocated to a separate thread within the current process. In other words, the operation can be performed without waiting.

[andry81]

The child process running by a previous command will always has a different PID, why it should has the same? You have to wait on that pid to wait the process exit.

You don't seem to understand my question. I'm asking about the practical applying of cm_WaitProcId <id>. Do you propose to find out the PID and change the button/command for this every time? I don't see any practical benefit in this when building chains of commands.

The <id> here is not a dynamic pid here, it is a constant number or a string identifier.

No, a certain function (including a cyclic one) of the program can be allocated to a separate thread within the current process. In other words, the operation can be performed without waiting.

I am taking about waiting on a command completion no matter what has to be execute internally. Internal commands synchronization is kind of different question and a part of TC plugin API.

[andry81]

To clarify all been said.

cm_WaitPrev

to wait on a previous command no matter what is handled behind it (external or internal call, thread or process).

cm_WaitProcId <id>

to wait only on an external child process behind the <id>. In case of an internal call it can be NOP (no operation command).

[Fla$her]

The <id> here is not a dynamic pid here, it is a constant number or a string identifier.

Where does the string identifier come from? Give an example of an implementation. I still don't understand how this can work.

I am taking about waiting on a command completion no matter what has to be execute internally. Internal commands synchronization is kind of different question and a part of TC plugin API.

Since you're talking about plugins, I'll give you a simple example. TCFS2 from em_ executes the autorun.wdx hotkey (SetHotkeyAction). Autorun executes the function via RunThread with a new thread, which will end only with TC closure or by the command cm_UnloadPlugins 8.
As a result, at best you will wait for TCFS2 to complete, but not what is executed after the hotkey.

[andry81]

The <id> here is not a dynamic pid here, it is a constant number or a string identifier.

Where does the string identifier come from? Give an example of an implementation. I still don't understand how this can work.

This is already an example of implementation. The `cm_WaitProcId PrevCommand` works the same way as the `cm_Wait` works, but instead of waiting on amount of time it does wait on the child external process of a previous command. I don't know what to said more here.

Since you're talking about plugins

I am not. I am talking about the TC process start functionality. A plugin can do what it wants without any notification.

I'll give you a simple example. TCFS2 from em_ executes the autorun.wdx hotkey (SetHotkeyAction). Autorun executes the function via RunThread with a new thread, which will end only with TC closure or by the command cm_UnloadPlugins 8.
As a result, at best you will wait for TCFS2 to complete, but not what is executed after the hotkey.

In this example plugin can run anything it wants. The `cm_WaitPrev` just waits `em_executes` to return. The `cm_WaitProcId` depends on an external process being executed directly by the TC process inside the `em_executes` user command (registered `CreateProcess*` Win32 API call). If it calls to the plugin then there is no any direct calls to the `CreateProcess*` by the TC itself and the `cm_WaitProcId` can return immediately.

[Fla$her]

This is already an example of implementation.

No, this is not an example. This is a generalized narrative. In the example, a specific chain of commands and em_ customization with the process name and its unchanging number <id> is needed, which will function without fail.

Since you're talking about plugins

I am not.

>>>

... and a part of TC plugin API.

In this example plugin can run anything it wants. ... If it calls to the plugin then there is no any direct calls to the `CreateProcess*` by the TC itself and the `cm_WaitProcId` can return immediately.

Well, with this you only confirm my thesis about the uselessness of the proposed command for such situations.

[andry81]

This is already an example of implementation.

No, this is not an example. This is a generalized narrative. In the example, a specific chain of commands and em_ customization with the process name and its unchanging number <id> is needed

I am not a developer of TC to bring an example of real implementation. But this example is definitely is not so hard to implement without knowledge of the details in the plugings.

which will function without fail.

What fail? You didn't introduce an example of it.

Well, with this you only confirm my thesis about the uselessness of the proposed command for such situations.

You have to prove that statement.