Prior to the enhancements to `/container/print` in RouterOS 7.20, the sequence could be even longer because you needed to manually give the command repeatedly until the runtime entered a settled state, else the `shell` command would fail.

What has _not_ changed in RouterOS 7.20 is the need for that “sleep 3600” hack. We need it in order to work around the lack of interactive mode in `container.npk`, without which containers of this type will start, do a whole lot of _nothing_, and then stop. We must give it some type of busy-work to keep it alive long enough to let us shell in and do our actual work. This sneaky scam is a common one for accomplishing that end, but it has the downside of requiring the user to predict how long you want the container to run before stopping; this version only lasts an hour.

If you are imagining more complicated methods for keeping containers running in the background when they were designed to run interactively, you are next liable to fall into the trap that…


# <a id="cmd"></a>There Is No Host-Side Command Line Parser
# <a id="cmd"></a>The Host-Side Command Line Parser Is Not Bash

The RouterOS CLI isn’t a Bourne shell, and the container feature treats the optional `entrypoint` and `cmd` values as simple strings, without any of the parsing you get for free when typing `docker` commands into a Linux command shell. The net effect of all this is that with many containers, you’re limited to two-word commands, one in `entrypoint` and the other in `cmd`, as in the above “`sleep 3600`” hack.

Because the RouterOS CLI isn’t a Bourne family shell, you do not get identical parsing as when typing `docker` commands into a Linux terminal. They added basic string splitting for the `cmd` argument in 7.20, so that this now works:
But how then do you say something akin to the following under RouterOS?

    docker run -it alpine:latest ls -lR /etc

    > /container add remote-image=docker.io/library/alpine name=alpine
You might want to do that in debugging to find out what a given config file is called and exactly where it is in the hierarchy so that you can target it with a `mount=…` override. If you try to pass it all as…

    /container/add … entrypoint="ls -lR /etc"
    > run alpine cmd="ls -lR /etc"

…the kernel will complain that there is no command in the container’s `PATH` called “`ls -lR /etc`”.

…but you still won’t get things like [glob] expansion, which is why this fails:
You may then try to split it as…

    /container/add … entrypoint="ls" cmd="-lR /etc"

    > run alpine cmd="ls -lR /etc/ssl/certs/*"
…but that will earn you a refusal by `/bin/ls` to accept “&nbsp;” (space) as an option following the `R`!

If you get cute and try to “cuddle” the options with the arguments as…

    /container/add … entrypoint="ls" cmd="-lR/etc"

…the `/bin/ls` implementation will certainly attempt to treat `/` as an option and die with an error message.(^Yes, for certain. I tested the GNU, BSD, _and_ BusyBox implementations of `ls`, and they all do this.)

Things aren’t always this grim. For instance, you can run [my `iperf3` container](/dir/iperf3) as a client instead of its default server mode by saying something like:

    /container/add … cmd="-c192.168.88.99"

This relies on the fact that the `iperf3` command parser knows how to break the host name part out from the `-c` option itself, something not all command parsers are smart enough to do. There’s 50 years of Unix and Linux history encouraging programs to rely on the shell to do a lot of work before the program’s `main()` function is even called. The command line processing that `container.npk` applies to its `cmd` argument lacks all that power. If you want Bourne shell parsing of your command line, you have to set it via `ENTRYPOINT` or `CMD` in the `Dockerfile`, then rebuild the image.

There is one big exception to all this: a common pattern is to have the `ENTRYPOINT` to a container be a shell script and for that to do something like this at the end:
For some containers, there is a workaround. A common pattern is to have the `ENTRYPOINT` to a container be a shell script and for that to do something like this at the end:

    /path/to/actual/app $@

This ropes the `/bin/sh` inside the container into the process, and depending on exactly how it’s done, it might be able to split a single passed command argument string into multiple arguments to the internal program. The main problem with this is that it’s entirely contingent on how the container image is set up. The only way to profit from this realization other than by happenstance is if you’re creating the image yourself and can arrange for it to run your passed argument string through an interpretation process akin to the one shown above. That amounts to a type of “command injection” vulnerability, but as long as you’re certain your commands are coming from trusted sources, it might be a risk you’re willing to accept.
This ropes the `/bin/sh` inside the container into the process, and depending on exactly how it’s done, it might be able to process the command argument string in a way you expect. The main problem with this is that it’s entirely contingent on how the container image is set up. The only way to profit from this realization other than by happenstance is if you’re creating the image yourself and can arrange for it to run your passed argument string through an interpretation process akin to the one shown above. That amounts to a type of “command injection” vulnerability, but as long as you’re certain your commands are coming from trusted sources, it might be a risk you’re willing to accept.

[glob]: https://en.wikipedia.org/wiki/Glob_(programming)


# <a id="terminal"></a>Interactive Terminal Handling

Although RouterOS proper is built atop Linux, and it provides a feature-rich CLI, it is nothing like a Linux command shell. I am not speaking of skin-level command syntax differences here; the differences go far deeper.

When you SSH into a RouterOS box, you’re missing out on a meaningful distinction between stdout and stderr, and the kernel’s underlying termios/pty subsystem is hidden from you. These lacks translate directly into limitations in the ability of `container.npk` to mimic the experience of using Docker at the command line.