Good analogy. You made my mind reframe that thought. Thanks for your view.
indeed - but every little helps - even itās it just to protect against idiots doing dumb things accidentally. Also calls to OS are less portable across platforms - so only having to search and fix them in one type of node makes it easier than having to fix inside multiple types.
Hey - Iām all for fixing and enhancing core nodesā¦ Pull requests always welcome after a discussion on here. (and just because I said I donāt like it doesnāt mean it wonāt ever go ahead).
1 Like
Can I search for a JSONata command, e.g., $exec, in the Node-RED search? Hm it seems so:
again I didn't say anything, I was thinking outloud.
Different meaning of "blocking" I think? I should have said "blocking access to the exec node"
Is there such a command in Jsonata?
I come from a Unix background, where I am familiar with assembling a process by piping together the input and output of discrete commands to build a greater whole.
I saw an echo of that approach in Node-red where you pass a message from node to node, performing various manipulations along the flow.
That's why I welcomed the release of Node-red.
Jsonata on the other hand, while handy in some cases to manipulate json data, looks like a complete (special purpose) language embedded within Node-red.
This is contrary to the chain of compact single purpose tools paradigm of a Unix shell and Node-red, perhaps even windows commands (who knows?).
If you could pass a payload to an operating system command within a change node you could combine NR processing with any interpreted language you are familiar with, in preference to learning Jsonata.
Years ago I did suggest this as an enhancement and it was scorned on the spurious grounds that you would have to build a Bash interpreter into Node-red.
Since then, the danger of allowing OS access has become ever clearer, so of course this should never be implemented in the core.
And as Dave says there is an issue of portability across platforms.
For these reasons I will make it clear once again that I am not suggesting a change to core nodes.
So where is the list of NR core and contrib nodes that an organisation should consider blocking access to? It might be incomplete or out of date, but every little helps!
Nope, this was me thinking out-loud since it would be a "simpler" solution than adding a new field type. However an extra $exec(...) JSONata command would open a totally new can of worms, i.e., how to map those commands to various OS's - Window v. Linux v. MacOS v. Docker etc.
For simple commands such as ls -la | grep fubar it won't be a problem but more complex stuff you're better off using the exec node. But having said that, JSONata itself is a simplification of JS functionality. So if one were to say that an $exec command would be a bit like a busybox and only support a minimal number of commands, then it might well be something that could be implemented for various platforms. Also all the shell complexities would definitely not be supported by an $exec command, e.g. 2>&1.
JSONata is a simplification so that a function node doesn't always have to be used. It's not just data manipulation, especially since it can modify flow and global contexts. Or on the other hand, Node-RED is only about data manipulation - so JSONata is a big part of that 
It's not trivial but on the other hand, it's not rocket science. It's somewhere in between!
I say this having created a jsonata parser for Erlang and an exec node for Erlang, I can honestly say that to have an $exec JSONata command in Erlang-Red won't be that much of an issue. But that's because I'm using a library that abstracts the OS away for me, if that doesn't work on windows, then so be it I.e. Erlang-Red doesn't need to work on windows - at this stage.
So I do have a comfort zone and can definitely understand the reluctancy of Dave and Nick.
