You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... 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.
The text was updated successfully, but these errors were encountered:
... 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.
The text was updated successfully, but these errors were encountered: