using multi-line output from 'run' as stdIn on MacOS

Communities CommandBox CLI
1

In bash, when I execute the following:

`

$ping -t 4 127.0.0.1 | grep packets

`

I get the expected output of:
`

4 packets transmitted, 4 packets received, 0.0% packet loss

$

`

likewise, if I execute:

`

$grep packets <<< “ping -t 4 127.0.0.1”

`

again, I get:

`

4 packets transmitted, 4 packets received, 0.0% packet loss
$

`

In the CB CLI, I get interesting behavior when trying the same commands using different variations of the “run” shell command (!):

trying to pipe in commandBox’ built in ‘grep’ command:

`

CommandBox:esb> !ping -t 4 127.0.0.1 | grep “packets”

PING 127.0.0.1 (127.0.0.1): 56 data bytes

64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.082 ms

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.139 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.078 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.085 ms

— 127.0.0.1 ping statistics —

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.078/0.096/0.139/0.025 ms

CommandBox:esb>

`

piping in the shell’s “grep” (using run):

`

CommandBox:esb> !ping -t 4 127.0.0.1 | !grep “packets”

PING 127.0.0.1 (127.0.0.1): 56 data bytes

64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.091 ms

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.145 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.124 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.064 ms

— 127.0.0.1 ping statistics —

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 0.064/0.106/0.145/0.031 ms

bash: syntax error near unexpected token `&&’

ERROR (3.8.0+00766)

Command returned failing exit code [2]

CommandBox:esb>

`

(Where is the unexpected token `&&’ error coming from?)

and attempting the alternate, "grep packets <<< “!ping -t 4 127.0.0.1"”
from inside commandBox gives similar results. I can’t seem to pass any external commands (executed using “run”) using stdIn to builtin or external shell commands from the commandBox shell.

Here, I’m using ‘ping’ as an example as it’s easy to reproduce, but any command that returns multiple lines to stdout shows the same behavior for me in commandBox.

Is this a known limitation of the shell or am I doing this wrong?

I’m running terminal on MacOS Sierra 10.12.6 and I’m running CommandBox 3.8.0+00766 and CLI Loader 1.5.5 (output of “ver” command)

Thanks in advance!
–Joel

2

You can’t pipe the output of native shell executions right now. It used to work, but then interactive commands would hang forever. I actually just spent 15 minutes explaining the full history of this to John Farrar (and the potential future fix) in the CFML Slack channel. The conversation is in a thread off of the #box-products channel.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

3

In case you don’t take a look at the conversation on Slack, the other bit I just shared with John F would probably also help you. If you want to do piping or file direction and you want it all to take place in the native shell, wrap the entire command in quotes so CommandBox doesn’t interpret the | or >, etc.

Here’s an example I just helped John with:

!“git rev-parse --abbrev-ref HEAD > git_branch.txt”

Without the quotes above, it’s two separate CommandBox commands, but with the quotes, the entire thing gets passed to the native shell.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

4

Thanks for the suggestion Brad, but it appears bash doesn’t like the quotes, single or double. (at least on my Mac):

CommandBox:esb> !“git status”

bash: git status: command not found

ERROR (3.8.0+00766)

Command returned failing exit code [127]

CommandBox:esb> !“ping -t 4 127.0.0.1”

bash: ping -t 4 127.0.0.1: command not found

ERROR (3.8.0+00766)

Command returned failing exit code [127]

CommandBox:esb> !“ls -last”

bash: ls -last: command not found

ERROR (3.8.0+00766)

Command returned failing exit code [127]

CommandBox:esb> !‘ls -last’

bash: ls -last: command not found

ERROR (3.8.0+00766)

Command returned failing exit code [127]

–Joel

5

Other interesting results:

`

CommandBox:esb> run “svn status”

bash: svn status: command not found

ERROR (3.8.0+00766)

Command returned failing exit code [127]

CommandBox:esb> run command=“svn status”

CommandBox:esb>

`

“run svn status” (without the quotes) returns the bash equivalent. (same with “!svn status” (no quotes)

6

Hmm, interesting-- it seems Windows behaves differently than *nix. Go figure. Looks like the extra quotes get passed through to the shell and Windows don’t care, but Bash gets angry.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

7

The run command always required positional parameters. It’s part of the special exception that the command gets from the parser. In order to prevent you from having to escape everything which would be a pain, all text after ! or run just gets turned directly into the command to be run.

Let me clear something up though, in your last 2 E-mails, you’ve been wrapping EVERYTHING in quotes, but that was only a work around I had came up with (which we now know only works on Window) for when your command had >, >>, ||, or &&, etc in it. There would be no need to try and wrap something like “svn status” since it should just work by itself.

Can you try something like this and let me know if it works? This bypasses the parsing exception I mentioned above and is another way to control the exact input to the “run” command.

echo “ping -t 4 127.0.0.1 | grep packets” | run

That differs from

run ping -t 4127.0.0.1 | grep packets

in that the pipe in the second example will get eaten by the CommandBox parser first and result in two commands, while in the first one the pipe is part of a quoted string so it can get captured from the CLI without being noticed and then you can send it directly into the “run” command.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

8

You are a scholar and a saint, Brad!

CommandBox:esb> echo “ping -t 4 127.0.0.1 | grep packets” | run

4 packets transmitted, 4 packets received, 0.0% packet loss

CommandBox:esb>

That worked! :slight_smile:

9

Cool, and sorry there’s not a good way to capture that result in the CommandBox shell right now. In the mean time, you could write it to a file and then cat out the file if you really really needed to use it in box.

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com