Why do we need to use echo here? In Unix implementations, when there are special symbols in the user's path (such as ;, which is a valid filename), it can potentially lead to ACE (Arbitrary Code Execution).

For example, foo;rm bar.txt would result in echo foo;rm bar.txt.

Well, echo is the simplest way to expand path. It's better than writing another parser.

I think ACE can be avoided by wrapping the path with quote.

Hmm, seems unnecessary to make it so complicated. Just expanding the system preset variables should suffice?

This is just a simple replace, like replace("$USERPROFILE", || env::get("USERPROFILE")), without worrying about user variables.

On Windows, there're more presets than you might think. In my knowledge alone, there are %USERPROFILE%, %ALLUSERSPROFILE%, %TEMP%, %TMP%, %APPDATA%, %LOCALAPPDATA%, %PROGRAMDATA%, %PROGRAMFILES%, %COMMONPROGRAMFILES%,...

And when you install some programs, they add more to the list (%GO_HOME%, %PYTHONPATH%, %OneDrive%,...)

I found 97 variables at https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables, and I think users might not be aware of most of them. Implementing all of them would be laborious and pointless.

Is it possible to implement only a portion of them or have Yazi set a unified name that can work across different systems, similar to what dirs does? Alternatively, can we directly use dirs, which is currently a dependency of Yazi?

One user may not use all the variables, but a combination of many users may cover a whole lot of them.

On the contrary, I don't think calling echo is something complicated. It's no different than calling file for mimetype or lsar for archive review. Even better since we don't have to install anything.

• If it relies on the cmd, sh, and echo commands, it should be placed in the external/ directory as a separate file. Since it relies on cmd and sh, it should be handled through shell.rs rather than creating a new one, and it should be asynchronous. Yazi encapsulates all external commands that need to be called multiple times as asynchronous because it's not just a system call but involves the entire process lifecycle of creation and destruction. This would add complexity to expand_path.
• I'm not a security expert, I can't be certain if the current Unix implementation is absolutely secure. Currently, the visible issue is that only " is escaped, and \ itself is not escaped, which is also a valid part of a filename.
• In the Windows implementation, why is .replace("\\\"", "\"") needed and is this an undefined behavior? Also, I would prefer using OsString to get the result as it can be directly converted to PathBuf without the need for String::from_utf8_lossy.
• I'm not sure if implementing complete variable expansion is worthwhile. I lean towards implementing only the common ones (in the dirs's list), and leaving more complex cases to implement through plugins (Lua can read env variables).

I think this should be built-in instead of relying on plugin, because I don't expect my file manager to be less useful than a cd command.

If you don't want to use external program call, then how about just using regex to expand it?

How about the proposal to make echo asynchronous mentioned above?

BTW, I'm not sure how about Windows, but in Unix the cd command "indeed" doesn't support expanding paths; it relies on the shell's expansion capabilities, and Yazi's goal is not to reimplement a shell, that might seem reasonable although...

Currently shell.rs is in core module. If we want to call echo via shell.rs then we have to move it to shared module. What do you think?

This is a real issue, I'll try to make it done later

I switched to the regex, would you like to give it a review?

Thank you!