Introduce a standalone CLI program

[sxyazi]

Please describe the problem you're trying to solve

For a long time, Yazi has been designed as a TUI application. But as Yazi continues to evolve, new needs arise, and these needs can be more efficiently met as a CLI program.

When Yazi starts, it needs to read all configuration files, check and merge these configurations, and detect the operating system and terminal type for correct image rendering. These are time-consuming operations, especially detecting the terminal type, which requires sending CSI sequences to the terminal and waiting for a response.

This requires Yazi to have the ability to read from stdin. But this is not suitable when integrating externally, such as calling Yazi in a shell script to perform the following tasks:

• ya send: Ability to communicate with DDS to address Ability to change yazi CWD from external process #891. After changing the shell's current working directory, send a message to Yazi to notify the ongoing Yazi instance to synchronize the cwd.
• ya cp: A faster alternative to cp with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
• ya mv: A faster alternative to mv with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.
• ya ls: A faster and more beautiful alternative to ls. This is part of future plans.
• ya colors: Address Produce LS_COLORS output when invoked with special flag #852, output Yazi themes as LS_COLORS for a more readable way to use these colors in the shell through configuring the Yazi theme. It still needs to read the configuration file, but it can be minimized and lazily loaded only when this command is called, rather than at program startup, and only the theme configuration is read. Note that I am still considering whether to implement it; it may ultimately not become a reality.
• ya plugin / ya theme: Providing plugins, theme management functionality, such as installation, updating, uninstalling, etc., is also a feature I am still considering.

The new CLI program will use ya as its name because it is short enough and will be more convenient when executing commands like ya cp or ya mv.

The only issue might be potential name conflicts with shell wrappers, but I don't think this is a big problem - I renamed the shell wrapper to yy last month, and it does not interfere with existing users since shell functions should always take precedence over CLI programs.

For new users who want to use the new CLI, I will note in the documentation that it may conflict with the name of the shell wrapper they set before.

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

.

Additional context

No response

[raffaem]

• ya cp: A faster alternative to cp with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.

• ya mv: A faster alternative to mv with the powerful async task scheduling system, providing a progress bar and more beautiful. This is part of future plans.

What would be the difference with advcpmv?

[eljamm]

Sorry for all the reference spam 😓

I learned that it might not always be appropriate to link issues in commits, especially if GitHub's gonna reference it again after every rebase.