Use uutils/coreutils for cross platform commands?

[mrgrain]

It's all in the title really. Rust coreutils are rapidly becoming the standard in Linux and are now even available for Windows.

The crate already builds as wasm (and can run in the browser!). Since this project already does create a was, for the shell parser, it might not be that big of a lift to include coreutils as well.

This would replace a number (all?) custom implementations of commands with the coreutils, thus providing wider and more accurate support for flags. Potentially even speed benefits. More crucially it would close the wide gap of commands still missing.

This is a proposal/thought. If you are interested I might be able to work on it.

[dsherret]

This was recommend a few times in deno_task_shell, but last time I checked there wasn't a way to provide an environment to the commands. Everything uses a global environment.

For example, the pwd command is doing stuff like std::env::current_dir(): https://github.com/uutils/coreutils/blob/3ceaab508f7178947cbaf7e806a70bb4905f8378/src/uu/pwd/src/pwd.rs#L24

It would be nice if they refactored the code to allow providing a trait for the system.

[dsherret]

Another issue is that the code is using directives like #[cfg(windows)], which doesn't work well once compiled to Wasm (because when compiled all the code goes away, but someone might be running the wasm on windows). That would need to be refactored to do a runtime check. Something like this is better:

https://github.com/dsherret/sys_traits/blob/709e02e198721f81b485c078ccdf1835fa3e6a40/src/impls/wasm.rs#L1273-L1275

[eduardomourar]

It seems what you are asking is to build with wasm32-wasip1 target (already supported by uutils coreutils). That way you can provide all necessary input functions depending on the host OS. I have also created a PR to add wasm32-wasip2 support here and you can find coreutils working in the browser here.

[dsherret]

Isthere a way to easily hook into that so it uses a custom environment defined by JS? This library allows spawning multiple commands with different environments that don't necessarily have the current process' environment. So using the current process' environment wouldn't be sufficient here.

Additionally there would need to be a way to preserve the windows cfg directives, which I believe would require a refactoring to change those to be runtime checks for wasm?

[eduardomourar]

Yes, your WASM binary runs in isolation so you can have a custom environment defined by leveraging JCO, needed until we have WASI Preview 2 support natively in Node.js and Deno. You can see an example in my code here.

By compiling to wasm32, any other cfg directives (including the one for windows) will be skipped. In return, you will gain the real portability I believe you intended.

[dsherret]

Hmmm I guess it would need to instantiate a wasm instance per command in order to have the environment correct for that command. Or I guess actually everything would be executed sync instead of async though.