> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice
um… what?
Zx 3.0
111–120 of 169 posts
Re: Zx 3.0
#112Earlier quoted context omitted.
using sh is usually preferred: somecmd & someothercmd & wait runs the two commands in parallel and waits for both. no need for await. to run in serial replace & with && and skip the wait
Huh, neat, didn't know "wait". Thanks! Still doesn't let you easily get the output of the two commands, but a good start.
You can just use files as a temporary buffer:
(/my/bg_producer1 > /shm/file1) &
(/my/bg_producer2 > /shm/file2) &
/my/longrunningfgjob
wait
(/my/consumer1 Re: Zx 3.0
#113First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Great that it's under active development, but changes to my scripts are infrequent and slow. I wouldn't want to be touching an old script on a server somewhere saying "How do I do X in ZX again?" and everything I find online is now for v15 while I'm still on v3. Maybe if it had plans around…
> First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already.
Would you feel better if they called version three v1.9 instead?
Re: Zx 3.0
#114await $`dep deploy --branch=${branch}` … await $`mkdir /tmp/${name}` Code like this[1] looks prone to shell injection [1] https://github.com/google/zx
Template tag functions in JS can intercept the interpolation values passed in. So it's possible they're automatically escaping to prevent shell injection. They could also be parsing out the first word as the command and not using shell execution at all.
Indeed, escaping is what they seem to do.
Re: Zx 3.0
#115I feel like the await keyword everywhere is a bit verbose. One might use something like the gpp preprocessor (hopefully the macros could be defined in a separate file): #!/usr/bin/env zx #define _ await $ #define __ await Promise.all #define _1 process.argv[1] #define _2 process.argv[1] #define _3 process.argv[1] _`cat package.json | grep name` let branch = _`git branch --show-current` _`dep deploy --branch=${branch}…
[deleted]
Re: Zx 3.0
#116I feel like the await keyword everywhere is a bit verbose. One might use something like the gpp preprocessor (hopefully the macros could be defined in a separate file): #!/usr/bin/env zx #define _ await $ #define __ await Promise.all #define _1 process.argv[1] #define _2 process.argv[1] #define _3 process.argv[1] _`cat package.json | grep name` let branch = _`git branch --show-current` _`dep deploy --branch=${branch}…
I don't think it is very relevant to critique the Javascript syntax on a post about a specific library
I am not talking about JavaScript in general. I have been doing mainly JavaScript programming for the last 8 or 9 years or so (before that other languages like C# and C++ for many years). And I use those keywords all the time.
For this specific use case, they are trying to replace shell scripts. So I thought maybe some people might be willing to consider abbreviations for the async and await keywords for this case.
Re: Zx 3.0
#117Is this a typo?
console.log(`Files count: ${count}`)
Re: Zx 3.0
#118> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice um… what?
It is _a_ perfect choice.
I know a bit of bash, but I'm always looking up how to do things I know are simple in JS. I would love to be able to write scripts in JS because I'm faster with it, and I find it easier to read.
Re: Zx 3.0
#119> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice um… what?
What is the nature of your outrage exactly? Bash is very difficult as a language to write code in. JS is very familiar to a lot of developers and its syntax is orders of magnitude easier to understand than Bash.
Re: Zx 3.0
#120First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Great that it's under active development, but changes to my scripts are infrequent and slow. I wouldn't want to be touching an old script on a server somewhere saying "How do I do X in ZX again?" and everything I find online is now for v15 while I'm still on v3. Maybe if it had plans around…
> First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Would you feel better if they called version three v1.9 instead?
The major version bumps imply breaking changes. Two major versions within a few months implies I might have to refactor my code every couple of months to stay up to date, or face a buildup of tech debt if I want to take advantage of a new feature in the future.
If there are no breaking changes, then I would feel better if they called it v1.9.