Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hard TODO #8

Open
francescobianco opened this issue Sep 18, 2023 · 0 comments
Open

Hard TODO #8

francescobianco opened this issue Sep 18, 2023 · 0 comments

Comments

@francescobianco
Copy link
Member

francescobianco commented Sep 18, 2023

... 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...

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant