Feature request - Access OS command line option in Change node

Core Development Feature Requests
1

We can use JSONata expressions in the change node, which gives access to powerful data manipulations. I believe a JSONata interpreter is built-in to Node-red:

This proposal is to also allow operating system commands (which would be passed to the os for evaluation, not evaluated by NR)

This will build on Node-red's ability to stitch together nodes and external programs (exec and daemon) cf the pipeline concept in Bash

Some examples using Bash syntax. I'm not sure if it should be DOS commands on Windows or Bash to WSL :

  • An eccentric date format requirement: "08 hours on day 081 of 2023" - date +"%H hours on day %j of %Y"
  • How many times today have Node-red flows restarted? - grep "Node-RED.*Started flows" /var/log/syslog | wc -l
  • Create an array [1,2,3,4,5,6,7,8,9,10] - printf "%s," {1..10} | sed ' s/,$//' (needs additional template node to change string to array)

Untitled 1
Untitled 1800Ă—451 18.9 KB

2

Correct me if I'm wrong, but can't you already do this? I have no problems using JSONata in a change node to output a string. That string can then be passed as input to the exec node.

And therein lies the problem doesn't it? There are at least 4 or 5 commonly used shells and they all have many different commands.

Feels to me like conflating too many different things into a single node?

3

Yes of course you can use an exec node.

The proposal is to make programming in Node-red more flexible for people who already have familiarity with the CLI of their operating system.

As for multiple shells, if I wanted a C shell command I would just prefix the command with csh. The OS handles it invisibly.

I agree, there are a lot of change node options. Maybe you would like to remove JSONata to it's own node to reduce the list? :upside_down_face:

4

Still feels like a lot of complexity to squeeze into a single node - but that's only my opinion of course. :grin:

But that directly relates to changing things on a msg. Running OS commands seems different to me.

5

The examples I gave above directly relate to changing a message; except for counting NR deploys you can do them with Javascript in a function node.

I struggle to understand this objection.
People use Node-red in different ways for example some-parental-control-with-nodered-and-a-windows-pc or
integrating-node-red-mcu-edition-into-the-node-red-editor
Do you object to these on the basis that it's somewhat different to "normal" Node-red philosophy?

Yes it might allow me to run some application which would be better launched from an exec node. I wouldn't choose to start an xterminal and open a browser from a change node, but if I did, so what?

What it would do is allow me to more easily use my knowledge of the shell as an alternative perhaps to learning yet another language - JSONata.

The long dropdown of change node options is certainly a problem but if necessary it could be broken down into categories.

6

I would be against this simply because it would be making something simple more complex and the more complex things gets, the more issues crop up. A node should do one thing and do it well. As I understand it, JSONata is included as part of node-red so it is not an external program.

The exec node's job is to exec external programs and that is what it does. So if you need to run some special script to make a change to something, the exec node is there for you to use.

My two cents.

7

I'm not objecting really, but rather commenting based on what I know about Node-RED philosophy over the years :slight_smile:

Heaven knows I tend to pack far too much into my own nodes. :rofl:

What we do with our own custom nodes is in a different league to what happens to core nodes though.

So if you were suggesting a custom node with this capability, I might comment about similarity with other nodes but that would be all.

Don't get me wrong - my comments were just that, comments about a suggestion. Of course, it won't be down to me what changes might or might not happen to a core node.

At the end of the day, it wouldn't bother me if another option were added as long as it was backwards compatible and didn't add bloat to Node-RED.

8

I have some concern about this. At present, the change node can only operate on messages and should not produce any side effects. The exec mode is much more capable and should be used with caution. If I imported a flow from this forum or an example for a node in the palette, I definitely would open any exec node to be sure that nothing malicious or misguided was going on inside. I would hate to have to do this with every change node.

2 Likes
9

this would make flows using the change node platform specific. I would prefer to keep anything specific to as few places as possible. Further we currently allow blocking of certain nodes in order to help security - and often that is the exec node to prevent things like rm - r :-)...

We can't block parts of nodes - and having users have to poke around inside nodes to work out why it works on one platform and not on another is not something we would not want to do lightly.

10

I concede defeat and limp off with just a couple of questions

Does the js code to run bash commands in 90-exec.js make the exec node platform specific? (Don't think I have ever successfully installed NR on Windows so no chance to test it).

OK it makes sense to only allow :(){ :|:& };: or sudo rm ... in exec (or daemon, some contrib nodes, ...)

How?

Is it impossible to use child_process.exec() in a fnction node? I have seen some discussion about that

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.