When my shell scripts get too large, I usually switch to Perl. Still best in class at handling text processing with a few shell commands here and there.
ZX – A tool for writing better scripts
21–30 of 143 posts
Re: ZX – A tool for writing better scripts
#22Maybe the example doesn't do justice but it looks more complicated than simply using "&" and "wait".
Yup, it seems the perfect example to wonder if a language with async by default is appropriate for the use cases of bash scripts.
The example runs 7 commands and has to explicitly await for 4 of them. The other 3 can run in parallel and it awaits for the end of all of them, which is fair.
The typical bash script is sequential and I fear that its zx replacement will be an exercise of writing await, await, await.
I'd go with an await by default language and wrap parallel code in whatever that language offers to wait for the end of child processes.
Re: ZX – A tool for writing better scripts
#23No way. If your script requires something more complex than what is difficult to implement or maintain in bash, then it is no longer just a script. Regardless of how small the resulting application may be, you should treat it as an application and not merely a script. Node.js is not typically used in the system layer where Bash scripts are commonly employed. No single administrator would replace Bash with Node.js. For parallel execution and asynchronous operations, tools like ansible exist, along with python, which administrators are already familiar with.
Re: ZX – A tool for writing better scripts
#24Bit verbose for me with all that promise/await stuff. Substitution rules probably simpler tho
Re: ZX – A tool for writing better scripts
#25How does this compare to the recently released Bun Shell?
Re: ZX – A tool for writing better scripts
#26This looks really cool, actually, and I'm surprised I haven't heard of this before. My incorrect gut intuition is that JavaScript devs usually don't do very much in depth terminal level command work, but that's of course false on a Bayesian level. There are far more JavaScript developers in the world than there are even Python developers, to say nothing of the long tail of even less popular languages. If 30% of JS de…
Here's an anecdote to help your gut. I'm a platform engineer who's favorite language is Typescript. I LIVE in the terminal. The only reason I use vscode is cause it's easier to put him into vscode than it is to put vscode into vim. Otherwise I'd be in the terminal for everything but browsing.
Likewise! I use TypeScript everywhere possible, and zx is a godsend. Unfortunately, I've recently dealt with gobs of Python for ML software. After years of writing TypeScript, it's been a...sobering reminder of many painful coding issues that I'd forgotten even existed. Made me deeply appreciate what TS gives us haha.
Re: ZX – A tool for writing better scripts
#27I really really enjoy using zx. As a dev it lets me get back to a good scripting language, where I process input, run other programs, emit output. Powerful & succinct. As a tool maker, it helps me show my work. Many of the common tasks like running an script or calling fetch will by default log what's happening in clear format, pass through the activity. It's fantastic to write these devtools that do a bunch of tasks…
An immediately visible problem with zx is that wrapping commands in $`` makes it harder to copy and paste them back and forth to the shell to test them. Did that slowed you down sometimes or added an occasional bug?
Re: ZX – A tool for writing better scripts
#28Re: ZX – A tool for writing better scripts
#29When my shell scripts get too large, I usually switch to Perl. Still best in class at handling text processing with a few shell commands here and there.
I'm doing that with Ruby, and tgrought the years, it became also true for scripts that are fetching data, iterating over JSON objects, etc.
Re: ZX – A tool for writing better scripts
#30Earlier quoted context omitted.
This [pun very much intended]
Where's the pun in that?
I’m assuming it’s this https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... (no pun intended)