Bash is not very cross platform is it. You couldn’t run that flow on quite a few other platforms..
That's completely right Dave, a Node-red application written with that code would be confined to Linux.
Just like a Node-red application with that code in an exec node.
Or with C:/myfiles/picture.png in a write-file node.
So use an exec node then. I guess I’m not seeing why cramming the exec node functionality into the change node is a good idea. The exec node is dangerous enough already. See recent hacks. Such that I think it may be best to disable it by default. Wouldn’t want to bring that exposure to another node.
I agree, especially since Node-red has not been patched to alleviate the risk of malicious exec code on systems with passwordless sudo.
But that is a spurious argument in the context of my suggestion above, which would also be disabled by default. I dare say a function node could be made harmful, or the (horrible) contrib Python node.
I know you don't see the advantage of my suggestions. I'm sorry I can't convince you of their value. Ah well, it's your language not mine.
There are any number of languages that can create microservices. node.js, Python, Go, Ruby, .... A microservice can deliver/consume MQTT, TCP, UDP, UNIX Pipes and probably many other types of interconnections.
For the globals, all you need is a node.js module and simply require it into the globals in settings.js - that code/data is then available in Node-RED in functions or custom nodes. or (for data anyway) even from change nodes, etc. A node.js module is simply a file that exports some stuff.
There are so many different ways to do this kind of thing. For example, I have some scripts that run on CRON schedules that call out to a Node-RED endpoint (http-in/-out). But of course, you could easily use a command-line MQTT tool or many other ways.
If you weren't doing a command-line thing at its heart, then a more powerful scripting language like Python or node.js, etc. could do a lot more than BASH.
But PowerShell can now run cross-platform. 
No, it really wouldn't be a good idea at all! It would be really hard to debug or even to understand after a month. It would likely also be a security nightmare.
JSONata is constrained to a smallish subset of processing. Basically a subset of a single(ish) data input and output. At most, this JS idea should be similarly constrained. Anything more would at best invite some really poor design practices.
Perhaps you evaded the point that my example was confined to bash but the suggestion does not specify any language.
A more powerful scripting language could do a lot more than I (or @cymplecy) like to do in Javascript.
I'll shut up again now 
Jsonata can use external libraries quite easily, maybe having quick access to such includes would give you the benefit of using external code. Additionally, jsonata has the ability to register functions ("registerFunction" that encapsulates some functionality onto a custom command, maybe an interface to this method.
1 Like
Excellent - seems to work quite nicely 
Could I persuade you to make up a switch node version as well?
And not forgetting an inject node one! 
You can use the change node after an inject node for testing
That is the point of Node-RED. To link up simple nodes that do their thing well, and not to cram every capability into every node.
1 Like
Spoilsport!
That’s my job
1 Like
However, I do hope that the ability is being baked into the standard typed input options? That way, we can all benefit from it.
2 Likes
Thank you!
I just pushed an update to the repo that should perform now as well nice syntax checking.
Well, this little PoC shows that it's not overly complicated to get the discussed functionality into the core nodes.
It all comes down thus to the question if this feature attracts enough fans to persuade the community / maintainers to accept a PR. I'd definitely not vote for (or maintain) a (or another) parallel eco system of alternative change / switch / inject nodes...
Personal perception:
Once you get used to it a bit, it feels so easy & much more intuitive than any other option...
1 Like
If it makes it into core, I'll be using this all the time to set random values for testing flows and nodes - currently I have to use
$formatInteger($random() * 100, "0")
Using JSONata - super annoying.
True, but hopefully a lot faster. And no annoying $ signs 
Oh, and of course, it returns an actual number not text.
Math.floor etc I can get behind. But once you start allowing function definitions then why not use a function node that you can at least document rather than hide behind one line ?
And can you then also set other msg properties within the same call ? Gets confusing real quick. And do you then allow node.warn for debugging etc…
1 Like
I'm pretty convinced, you can do crazy stuff with JSONata as well. People don't do this (usually) not because they're unfamiliar with JSONata, but because it's crazy stuff. On the other hand it feels very convenient to write a small function to process a value in-line within a change node.
Not sure yet that I get your point regarding documentation. Of course there's the standard JS editor opening when you press the ... button. Agreed, the script doesn't look too nice in the small input box - as does a JSON structure or longer JSONata statement. Once we've clarified the 'if', there'll be time to investigate the best way to represent things...
Functionality can always be discussed. Yet ... why shouldn't that be possible and helpful?
