This depends on a working npm environment, so you will continue to have the usual dependency rot.
The only way I would consider writing JS for shell commands is deno. It can produce self-contained binary executables from Typescript.
You can also write env-dependent scripts in the same way with
#!/usr/bin/env -S deno run --allow-read --allow-run
Two benefits here above zx: much stricter security (env, read/write, net all need to be explicitly allowed), and batteries-included stdlib inspired by Go.
OT: Sorry for voting spam, you might be wondering why: you only ever submit stories about your own projects, and this is the fifth release post you’ve made for zx that isn’t some kind of technical update, just a project release. Releases of zx, fx, expr, deployer etc .. It’s just spam.
My own personal observation is that when I want a “script” that a typical posix shell provides a decent amount of utility using what is already present on most platforms without too much baggage carrying needed. Practically, there is an inflection point where the demands of a “script” surpass what is reasonable to expect to get from a posix shell without an undue amount of hoop jumping (i.e. some types of performance, data structures, etc). When you arrive at that inflection point is when a developer makes the jump from maintaining a “script” and writing a “program” in a suitable full featured language.
I suppose what I’m getting at is, maybe the best tool for the job is one that already does the things you want in the expected way without bolting anything on to it to provide syntactic sugar and features that it doesn’t already have. I rarely love a wrench enough to wish it was also a good hammer…
Counterposing zx to bash, and relying on npm, is convincing me that this tool misunderstands the reasons why anyone writes bash.
I write shell scripts all the time. Do you think I like the language? Hell no! It’s weird and bad. I have to google basic things like for loops every time. Writing bash sucks.
I do it anyway, because a shell script I wrote ten years ago and haven’t touch since still works. npm can’t compete.
I strongly recommend changing the value proposition. zx does not compete against bash. It competes against other npm cli tooling. That kind of apples-to-apples comparison would come out pretty favorably, I think.
Yes and if your goals is portability, longevity bash is better option (although docker images can also be used for zx). And if your goal to create something right now, without googling, zx is the solution. Take a look on how people already use it on GitHub. I recently wrote a script myself: it downloads all icloud photes, sorts them in folders by year-month and burns to DVDs. With zx it was super easy for me. I could do tge same in bash, but it would take me much longer (i used arrays and maps)
I had to give up on bash when I found out that Apple stopped updating their bash like 15 years ago so my scripts had to be compatible with ancient versions.
I mostly test shell scripts with FreeBSD’s POSIX shell, which has a very small number of bash extensions. If they work there, they’ll work out of the box almost anywhere and in the tiny niche cases where they don’t work, it’s easy to install one of the many shells that they will work with.
Apple stopped updating bash when the FSF moved it to GPLv3. If you’re relying on newer bash features, you’re adding a hard dependency on GPLv3 software, which can cause headaches for people wanting to redistribute downstream.
I write scripts compatible with bourne shell. I don’t get people’s fixation with bash. Why do people refer to it in discussions such as this one? What’s particular with bash an not, say zsh? Didn’t apple change to having zsh as default a few years ago?
I personally have used fish for almost over almost 15 years. While I do write some fish scripts, I think as shellscript as being #!/bin/sh compatible. Which it more or less means bourne shell.
I use a compatible subset of zsh and bash functionality, so that I can run my scripts in zsh on macOS and bash on anything else. That allows me to get some of the 15 years back :)
I am not a fan of the main API but I think the associated simple-ish APIs for piping and stdout look nice. Is it that much better than python’s subprocess? I mean it’s a bit better! And fortunately I think the lessons this brings can be totally brought into other languages’ process spawning tools.
For the first couple years of my life as a professional programmer, I worked at a place that used fabric. It gave me this impression that subprocess wrangling was a very tough thing, and had a lot of “magic” involved. Even though I had programmed in C++, I had never fully grokked that a process would receive a list of arguments, and that shells are doing this word splitting.
After really getting a hold of subprocess though, I really feel like I saw the light. Subprocesses can be managed relatively sanely. I no longer feel the need for stuff like fabric, and I totally regret not understanding this stuff sooner. Processes are not that complicated! It’s just that a shell is doing enough magic for us that it’s easy to lose the plot as a junior developer
All this to say that I think every subprocess API should receive a list of arguments for processes. For many that will be the way that they really absorb what their shell is doing.
This looks neat! I’ll probably be sticking to xonsh for my hybrid shell and general purpose programming needs, but I’d really like to see more exploration in this space in general.
This depends on a working npm environment, so you will continue to have the usual dependency rot.
The only way I would consider writing JS for shell commands is deno. It can produce self-contained binary executables from Typescript.
You can also write env-dependent scripts in the same way with
Two benefits here above zx: much stricter security (env, read/write, net all need to be explicitly allowed), and batteries-included stdlib inspired by Go.
The $ function is a neat trick though.
Zx works with deno.
I like dax as an alternative that embeds deno_task_shell so it doesn’t rely on Bash.
OT: Sorry for voting spam, you might be wondering why: you only ever submit stories about your own projects, and this is the fifth release post you’ve made for zx that isn’t some kind of technical update, just a project release. Releases of zx, fx, expr, deployer etc .. It’s just spam.
Also check out zxpy.
Disclaimer: I made zxpy.
Are there actually people asking for this?
My own personal observation is that when I want a “script” that a typical posix shell provides a decent amount of utility using what is already present on most platforms without too much baggage carrying needed. Practically, there is an inflection point where the demands of a “script” surpass what is reasonable to expect to get from a posix shell without an undue amount of hoop jumping (i.e. some types of performance, data structures, etc). When you arrive at that inflection point is when a developer makes the jump from maintaining a “script” and writing a “program” in a suitable full featured language.
I suppose what I’m getting at is, maybe the best tool for the job is one that already does the things you want in the expected way without bolting anything on to it to provide syntactic sugar and features that it doesn’t already have. I rarely love a wrench enough to wish it was also a good hammer…
Yes. A lot of people use JS every day. For them it’s easier to write in JS. ZX in for them.
Counterposing zx to bash, and relying on npm, is convincing me that this tool misunderstands the reasons why anyone writes bash.
I write shell scripts all the time. Do you think I like the language? Hell no! It’s weird and bad. I have to google basic things like for loops every time. Writing bash sucks.
I do it anyway, because a shell script I wrote ten years ago and haven’t touch since still works. npm can’t compete.
I strongly recommend changing the value proposition. zx does not compete against bash. It competes against other npm cli tooling. That kind of apples-to-apples comparison would come out pretty favorably, I think.
Yes and if your goals is portability, longevity bash is better option (although docker images can also be used for zx). And if your goal to create something right now, without googling, zx is the solution. Take a look on how people already use it on GitHub. I recently wrote a script myself: it downloads all icloud photes, sorts them in folders by year-month and burns to DVDs. With zx it was super easy for me. I could do tge same in bash, but it would take me much longer (i used arrays and maps)
I had to give up on bash when I found out that Apple stopped updating their bash like 15 years ago so my scripts had to be compatible with ancient versions.
I mostly test shell scripts with FreeBSD’s POSIX shell, which has a very small number of bash extensions. If they work there, they’ll work out of the box almost anywhere and in the tiny niche cases where they don’t work, it’s easy to install one of the many shells that they will work with.
Apple stopped updating bash when the FSF moved it to GPLv3. If you’re relying on newer bash features, you’re adding a hard dependency on GPLv3 software, which can cause headaches for people wanting to redistribute downstream.
I write scripts compatible with bourne shell. I don’t get people’s fixation with bash. Why do people refer to it in discussions such as this one? What’s particular with bash an not, say zsh? Didn’t apple change to having zsh as default a few years ago?
I personally have used fish for almost over almost 15 years. While I do write some fish scripts, I think as shellscript as being #!/bin/sh compatible. Which it more or less means bourne shell.
I use a compatible subset of zsh and bash functionality, so that I can run my scripts in zsh on macOS and bash on anything else. That allows me to get some of the 15 years back :)
came across clerc just now, will try write something with both Zx and clerc
I am not a fan of the main API but I think the associated simple-ish APIs for piping and stdout look nice. Is it that much better than python’s
subprocess? I mean it’s a bit better! And fortunately I think the lessons this brings can be totally brought into other languages’ process spawning tools.For the first couple years of my life as a professional programmer, I worked at a place that used fabric. It gave me this impression that subprocess wrangling was a very tough thing, and had a lot of “magic” involved. Even though I had programmed in C++, I had never fully grokked that a process would receive a list of arguments, and that shells are doing this word splitting.
After really getting a hold of
subprocessthough, I really feel like I saw the light. Subprocesses can be managed relatively sanely. I no longer feel the need for stuff like fabric, and I totally regret not understanding this stuff sooner. Processes are not that complicated! It’s just that a shell is doing enough magic for us that it’s easy to lose the plot as a junior developerAll this to say that I think every subprocess API should receive a list of arguments for processes. For many that will be the way that they really absorb what their shell is doing.
This looks neat! I’ll probably be sticking to xonsh for my hybrid shell and general purpose programming needs, but I’d really like to see more exploration in this space in general.