🚀 Discover the Rust Revolution for Shell Scripts with Mush 🚀

Hello dear dev.to-ers! Are you ready for an epic revolution in the world of shell scripts? We have a surprise for you! 🎉

🌟 Mush: The Future of Shell Scripts is Here! 🌟

Have you ever wished for a better and more robust way to organize your shell scripts? Tired of compatibility issues between BASH and ZSH? Well, sit back and get ready to be blown away by the storm of innovation sweeping through the world of shell scripting, courtesy of Mush.

🐚 Mush: Rust-Inspired Shell Scripting Reinvented 🐚

Mush is a powerful and flexible tool for creating shell scripts, inspired by Rust. This tool is completely transforming how we organize and write shell scripts. With Mush, forget about compatibility worries across different shells and embrace the beauty of Rust-inspired syntax and security.

🎨 Key Features of Mush 🎨

• 🌈 Intuitive and clean syntax inspired by Rust.
• 💪 Enhanced security and stability thanks to Rust.
• 🚀 A project management system to organize your scripts.
• 🌐 Multi-shell compatibility for effortless portability.
• 🛠️ Extensible and customizable to fit your needs.

⭐ Star Mush on GitHub! ⭐

If you're as excited as we are about this shell script revolution, take action! Star the Mush GitHub page to show your support. Help us spread the word about this incredible resource for shell script enthusiasts.

💡 Conclusion 💡

Mush is the future of shell scripts and is about to change how we write and organize BASH and ZSH scripts. Join the Rust-Inspired revolution and make a difference in the world of shell scripting.

Don't wait! Start using Mush today and experience the power of shell scripting like never before! 🔥🚀

Comments

[TaiKedz]

... it's not clear what this is, from this post, the github repo, or the webstie....

What is meant by a "shell package" ? This is not a standard concept by far, you're going to need to explain what the problem domain is before getting to talk about the solution...

What does this do? Multiple shell scripts combined to one? (it's a shell script linker?) A combination of the binaries a shell script calls? (an environment gatherer for consistent dependencies? how does that even get resolved?)

The only front page example shows compiling main() { echo "Hello world" ; } but neither use-case above would be needed for it.

And it produces a binary? like, an ELF or EXE? How is that related, or even desirable, for shell scripts? Sounds like a horrendous idea... what kind of benefits even come from this?

Safety isn't a feature of shell scripting, convenience is its hallmark. Where does rust fit into this? Is this transpiling shell scripts into rust, and compiling that? why?

We can't see what this project is about. With the current materials, it looks ... like it doesn't itself even know what it is...

[Francesco Bianco]

I see you well know the domain: github.com/taikedz/bash-builder

Thanks for your support! If you have spare time, You are welcome as main-contributor or maintainer.

[TaiKedz]

Thanks for the invitation, I would have to pass on that for now.

The project seems to be very incomplete, and it is still not clear what it aims to achieve. More work on its explanations are needed, as I stated in prior comment. I gave it a try, it doesn't seem to do any linking, just source calling. So the output executables aren't portable.

The idea seems interesting though. The promise of solving cross-environment compatibility and dependency sounds interesting though. But from my experience so far, trying to guarantee identicity of runtime from shell scripting is non-trivial.

The reason we can have guarantees for programming languages is that the dependencies are first-citizens in the language's ecosystem.

Shell scripting relies on arbitrary binaries of various implementation-flavours. grep is not the same grep on two distros. rsync is not the same rsync on different distros. ssh is not the same implementation on different distros. Their default behaviours are not the same across distros.

So making the promise of cross-platform execution.... is a tall order. My take has been: do basic linking/source inclusion into a single file ; normalise the runtime environments across your park, or write highly-portable scripts using common-denominator utility features. Use re-usable code snippets and linking to abstract away flavour-switching.