5 ms·

Swift as a (shell) scripting language has been terrible for me. To get us to Swift shell scripting, I think what's needed is the "syntax" for calling out to oth

Swift as a (shell) scripting language has been terrible for me. To get us to Swift shell scripting, I think what's needed is the "syntax" for calling out to other executables directly instead of wrapping it in a task. Of course, plumbing follows immediately and I don't know if we can keep the shell plumbing syntax in a Swift environment.

jph00 8y ago
That should be doable with a library, right? Is there any need for language syntax for this?
- jabl 8y ago
  If all you're doing is calling external processes, well, it's hard to beat the shell piping syntax. The problem is of course that as the complexity of the script grows, the absolute dreadfulness of actual programming in the shell rears its ugly head. I haven't really found a good compromise here myself.
  - delinka 8y ago
    You make a good point wrt complexity. A project to convert shell scripts into (even naïve) Swift code (form compiling) might be useful.
  - helge5 8y ago
    You can do piping in Swift, like so: http://noze.io/noze4nonnode/ http://noze.io/noze4nonnode/
- delinka 8y ago
  For the plumbing, maybe a library (of operator overloads) is all that's needed. For calling out to executables like a script (i.e. just put the exe name inline as if it were another symbol), you'd need first-class language support.
  - rgovostes 8y ago
    I don't see that working very well. If you ever made a typo in a function name, the compiler would have to assume that you are referring to an external tool that would be available at runtime. Swift gives the programmer a lot of flexibility in overriding operators, though, so one could probably make a decent DSL that approximates shell syntax.
    - delinka 8y ago
      For scripts, you're not compiling an executable that you'll run later, you're having Swift execute the code "now" so "available at runtime" becomes "immadiately after you parse the code."
- terhechte 8y ago
  The tricky part is that it is impossible to import any libraries in a script except: - The official libraries that ship with Swift - If you create a full-blown Swift package manager project and compile an executable. But this doesn't sound like a script anymore - If you use John Sundell's Marathon [https://github.com/JohnSundell/Marathon https://github.com/JohnSundell/Marathon] however it adds additional complexity around the writing of scripts I.e. none of the solutions are as simple as writing a bash script Edit: Just saw that Max Howell (creator of Homebrew) released this today https://github.com/mxcl/swift-sh https://github.com/mxcl/swift-sh This absolutely solves the issues. Fantastic.
  - wool_gather 8y ago
    swift-sh definitely bears looking into, thanks for that!
helge5 8y ago
Like this? http://www.alwaysrightinstitute.com/swift-dynamic-callable/ http://www.alwaysrightinstitute.com/swift-dynamic-callable/

jph00 8y ago

That should be doable with a library, right? Is there any need for language syntax for this?

jabl 8y ago
If all you're doing is calling external processes, well, it's hard to beat the shell piping syntax. The problem is of course that as the complexity of the script grows, the absolute dreadfulness of actual programming in the shell rears its ugly head. I haven't really found a good compromise here myself.
- delinka 8y ago
  You make a good point wrt complexity. A project to convert shell scripts into (even naïve) Swift code (form compiling) might be useful.
- helge5 8y ago
  You can do piping in Swift, like so: http://noze.io/noze4nonnode/ http://noze.io/noze4nonnode/
delinka 8y ago
For the plumbing, maybe a library (of operator overloads) is all that's needed. For calling out to executables like a script (i.e. just put the exe name inline as if it were another symbol), you'd need first-class language support.
- rgovostes 8y ago
  I don't see that working very well. If you ever made a typo in a function name, the compiler would have to assume that you are referring to an external tool that would be available at runtime. Swift gives the programmer a lot of flexibility in overriding operators, though, so one could probably make a decent DSL that approximates shell syntax.
  - delinka 8y ago
    For scripts, you're not compiling an executable that you'll run later, you're having Swift execute the code "now" so "available at runtime" becomes "immadiately after you parse the code."
terhechte 8y ago
The tricky part is that it is impossible to import any libraries in a script except: - The official libraries that ship with Swift - If you create a full-blown Swift package manager project and compile an executable. But this doesn't sound like a script anymore - If you use John Sundell's Marathon [https://github.com/JohnSundell/Marathon https://github.com/JohnSundell/Marathon] however it adds additional complexity around the writing of scripts I.e. none of the solutions are as simple as writing a bash script Edit: Just saw that Max Howell (creator of Homebrew) released this today https://github.com/mxcl/swift-sh https://github.com/mxcl/swift-sh This absolutely solves the issues. Fantastic.
- wool_gather 8y ago
  swift-sh definitely bears looking into, thanks for that!

helge5 8y ago

Like this? http://www.alwaysrightinstitute.com/swift-dynamic-callable/ http://www.alwaysrightinstitute.com/swift-dynamic-callable/