Accessing the shell

On a SONiC switch the Broadcom diag shell runs inside syncd. You reach it from the host with bcmsh for an interactive session, or with bcmcmd to run one command from a script. Both give you the drivshell> prompt, a thin SAI front-end in front of the SDK command interpreter.

How the pieces fit together

        flowchart TB
  subgraph host["Host"]
    hbcmsh["bcmsh"]
    hbcmcmd["bcmcmd"]
  end
  subgraph syncd["syncd container"]
    cbcmsh["bcmsh<br/>(socat, readline)"]
    cbcmcmd["bcmcmd<br/>(C++ client)"]
    sock[("/var/run/sswsyncd/<br/>sswsyncd.socket")]
    dsserve["dsserve<br/>one client at a time,<br/>socket ⇄ pseudo-terminal"]
    subgraph proc["syncd --diag"]
      thread["diag-shell thread<br/>enables the shell, again every 1 s"]
      fe["SAI front-end<br/>prompt drivshell&gt;"]
      sdk["SDK command interpreter<br/>unit 0"]
    end
  end
  hbcmsh -- "docker exec -it" --> cbcmsh
  hbcmcmd -- "docker exec -i" --> cbcmcmd
  cbcmsh --> sock
  cbcmcmd --> sock
  sock --> dsserve
  dsserve -- "pty: stdin, stdout, stderr" --> proc
  thread --> fe --> sdk

From the user inward:

Host commands /usr/bin/bcmsh and /usr/bin/bcmcmd. Each runs docker exec into the syncd container and calls the container’s command of the same name.
Container clients. bcmsh is a bash script that runs socat. bcmcmd is a small C++ program.
dsserve, a UNIX-socket-to-pseudo-terminal proxy. supervisord starts syncd through it, so syncd’s standard input, output and error all go through one pseudo-terminal, and that terminal is exposed on the socket /var/run/sswsyncd/sswsyncd.socket.
syncd, started with --diag. Once the switch is created, a thread asks the SAI to enable the switch shell. That call blocks for as long as the shell runs.
The SAI front-end, which prints the drivshell> prompt. It handles a few keywords itself and passes every other line to the SDK command interpreter, always on unit 0.

How syncd starts the shell server

The syncd start-up scripts run syncd under dsserve:

CMD_DSSERVE=/usr/bin/dsserve
CMD_DSSERVE_ARGS="$CMD_SYNCD --diag"
if [ -x $CMD_DSSERVE ]; then CMD=$CMD_DSSERVE; CMD_ARGS=$CMD_DSSERVE_ARGS; …
exec ${CMD} ${CMD_ARGS}            # dsserve /usr/bin/syncd --diag -u -p … …

dsserve runs in the foreground and listens on its default socket, /var/run/sswsyncd/sswsyncd.socket.
It creates a pseudo-terminal, connects syncd’s standard input, output and error to it, and starts syncd. It accepts one client at a time.
Inside syncd, a thread enables the switch shell once a second. While a shell session is active the call blocks; when the shell exits, the thread enables it again a second later. The loop ends only if enabling the shell fails.
Each time the shell is enabled it prints Hit enter to get drivshell prompt.. and waits for a newline. Only one shell can be active at a time.

When no client is connected, syncd’s console output, including the Hit enter… banner and any SDK messages, goes to /var/log/syslog. While a client is connected, all of it goes to that client instead, including SDK log lines unrelated to the command you ran.

Note

The SAI also opens the shell during switch initialisation if an SDK init command fails and the config.bcm property sai_suspend_on_error is non-zero. It prints SDK init failure. Use diag commands to troubleshoot. and opens the same drivshell> prompt before switch creation has finished. Connect with bcmsh to investigate, and type quit to let initialisation continue.

Host commands

bcmsh [-n ASIC] [-h] [-q] [-t SECONDS]

Open an interactive session with the diag shell.

-n ASIC: Connect to syncd<ASIC>. Accepted only on multi-ASIC platforms; Trident 3 systems are single-ASIC.
-q: Do not print the banner.
-t SECONDS: Close the session after this many seconds without traffic. The default is 300; 0 turns the timeout off.
-h: Print usage.

Unless -q is given, bcmsh prints:

Press Enter to show prompt.
Press Ctrl+C to exit.
NOTICE: Only one bcmsh or bcmcmd can connect to the shell at same time.

Line editing and up-arrow history work locally: the line is sent to the switch only when you press Enter. Ctrl-C closes the session but does not interrupt a command that is already running inside syncd (see Interrupting commands).

Unvalidated

$ bcmsh
Press Enter to show prompt.
Press Ctrl+C to exit.
NOTICE: Only one bcmsh or bcmcmd can connect to the shell at same time.

Enter 'quit' to exit the application.
drivshell>ps
...
drivshell>

bcmcmd [-n ASIC] [-v] [-t SECONDS] [-f SOCKET] COMMAND

Run one diag-shell command line and print its output. bcmcmd does not need a terminal, so it can be used in pipelines and scripts.

COMMAND: One argument. Quote multi-word commands: bcmcmd "l2 show". If several bare words are given, only the last one is run.
-n ASIC: Connect to syncd<ASIC> on multi-ASIC platforms.
-t SECONDS: How long to wait for output before giving up. The default is 30.
-f SOCKET: Socket path. The default is /var/run/sswsyncd/sswsyncd.socket.
-v: Print [INFO] cmd: … and [INFO] domain socket filename: … for the options that follow it.
-h, --help: Print usage and exit with status 22.

-t and -f must be followed by at least one more argument after their value: bcmcmd -t 5 alone is rejected with [ERROR] bad timeout (exit 22), but bcmcmd -t 5 ps works.

Exit status:

Code	Meaning
0	The shell returned to the `drivshell>` prompt. This does not mean the diag command succeeded; see Errors and result codes.
1	Could not connect to or write to the socket (for example `connecting stream socket`).
5	Read error, or the server closed the connection (`ending connection`).
22	Usage error, or `-h`.
62	No prompt arrived within the timeout (`polling socket timeout`).

How bcmcmd talks to the shell. bcmcmd connects, sends a newline and silently waits for either the Hit enter to get drivshell prompt.. banner (answering it with another newline) or drivshell>. It then sends COMMAND followed by a newline and prints everything it receives until the output ends in drivshell> again. There is no framing or end-of-output marker; the prompt text is the only delimiter. This has some consequences:

The output starts with the shell’s echo of COMMAND and ends with drivshell>. Parsers should drop the first and last lines. The text comes from a terminal, so lines end in \r\n (the echoed command line in \r\r\n).
A command that does not return to drivshell> makes bcmcmd wait until the timeout and exit with 62. The command keeps running in syncd, and the shell may be left in another mode. Examples:
- cint with no arguments, which leaves the shell at cint>;
- pause, which waits for a key;
- quit, after which the shell shows the Hit enter… banner, not drivshell>;
- any command that runs longer than -t seconds without the output ending in the prompt.
If a command’s own output happens to end in the text drivshell> at the end of a read, bcmcmd stops early.
Only one client is served at a time. A second bcmcmd connects but gets no data until the first one disconnects, so it usually times out with exit 62.
When bcmcmd gives up, the command does not stop. It keeps running inside syncd, and until it finishes no other bcmcmd or bcmsh gets the shell. techsupport all, for example, runs for more than ten minutes. Give long commands a generous -t.

Hardware-validated

$ bcmcmd "echo hello world"
echo hello world
hello world
drivshell>

Hardware-validated

$ bcmcmd -t 60 "echo one; echo two"
echo one; echo two
one
two
drivshell>

Other network operating systems

Most switches built on Broadcom StrataXGS chips run the same SDK and the same diag shell, but each operating system hides it behind its own command. The shell commands are the same; the SDK release, and with it the available commands and output formats, can differ from SONiC’s. On every one of these systems the switch software does not know about changes you make in the shell, so stick to reading state unless the vendor’s support asks otherwise.

Arista EOS

platform trident diag <command> runs one diag-shell command and prints its output. It needs privileged mode (enable); otherwise EOS answers % Invalid input (privileged mode required). Quoting the command is optional. There is no interactive prompt; run one command per line.

switch>enable
switch#platform trident diag ps xe8
                 ena/    speed/ link auto    STP                  lrn  inter   max  loop
           port  link    duplex scan neg?   state   pause  discrd ops   face frame  back
       xe8(  9)  up     10G  FD   HW  No   Forward          None    F    SFI  9232
switch#platform trident diag ver
Broadcom Command Monitor: Copyright (c) 1998-2010 Broadcom Corporation
Release: sdk-6.4.12 built 20230526 (Fri May 26 03:40:50 2023)
...

EOS uses its own port names (Ethernet7/1); the shell uses the SDK’s (xe8). show platform trident interface map lists both side by side.

Cisco NX-OS

On Nexus 3000 and 9000 switches with Broadcom chips (NX-OS 7.x and later), bcm-shell module <module> opens an interactive shell with the prompt bcm-shell.<unit>>, after a warning that the shell should be used with caution. exit leaves it. Typing a unit number at the prompt switches to another chip of the same module.

switch# bcm-shell module 1
bcm-shell.0> l2 show
bcm-shell.0> exit

To run a single command, give it in quotes after the module, optionally with a unit prefix: bcm-shell module 1 "0:ps". Single commands are recorded in the system accounting log and can be piped through NX-OS filters such as | include; commands typed in the interactive shell are not logged.

NX-OS 6.x and modular chassis use the older form, from the module’s own shell:

switch# attach module 2
module-2# test hardware internal bcm-usd bcm-diag-shell
bcm-shell.0> exit
module-2# exit

Cisco recommends against changing chip settings this way and expects these commands to be used under the guidance of Cisco support.

Juniper Junos (QFX5100, QFX5110)

From the Junos shell, vty fpc0 opens the line-card console; there each diag-shell command is wrapped in set dcbcm bcmshell "<command>". As root, cprod runs one such command without the console:

FPC0(vty)# set dcbcm bcmshell "ps"
root@switch:~ # cprod -A fpc0 -c 'set dcbcm bcmshell "listmem"'

Cumulus Linux

Older Cumulus Linux releases (2.x–3.x) ship /usr/lib/cumulus/bcmcmd, which runs one command at a time: sudo /usr/lib/cumulus/bcmcmd ps. Cumulus warns that opening the shell interactively can disrupt switchd and forwarding.

Extreme EXOS

After enable debug-mode (which asks for a debug password), the shell is /extr/bin/bcm.shell; pick a unit with 0: and leave with quit.

The `drivshell>` front-end

Entry. When the shell starts it waits for a newline (the Hit enter banner), then prints Enter 'quit' to exit the application.
Prompt. The prompt is drivshell>, with no trailing space and no unit number. Input lines are limited to 1024 characters; longer lines are truncated with WARNING: input line truncated to %d chars.

Front-end keywords. A few lines are handled by the front-end itself before the SDK sees them. The check is made on the raw line:

Line	Effect
`quit`	Prints `Exiting the application.` and leaves the shell. Must be exactly `quit`, lower case, with nothing else on the line; `QUIT` or `quit` with trailing text goes to the SDK instead.
`bsv`	Prints the SAI and SDK versions; see `bsv`.
`phydump`	SAI PHY dump; see `phydump`.
`xled ARGS…`	SAI LED helper; see `xled ARGS`.
`sh` (any case)	Refused with `Command sh is blocked`; see Blocked commands.
`she…` (any case)	Refused: any line starting with `she`.
`reb…` (any case)	Refused: any line starting with `reb`.

Everything else goes to the SDK command interpreter, always on unit 0. Commands run one at a time. If the SAI has not enabled diag commands yet, every line fails with Feature unavailable.

phydump

Run the SAI PHY dump. This is a front-end keyword, not an SDK command, and must be the whole line. It does nothing unless the SAI’s PHY-dump feature is enabled. On a SONiC Trident 3 switch it is enabled and prints, for every front-panel port, a # <port> (logical=<n>, physical=<n>) heading, the port’s PHY control settings (pre-emphasis, DFE, link training, interface, FEC clauses) and the SerDes core and per-lane configuration. With 36 ports that is over 5,000 lines. Read-only.

Hardware-validated

drivshell> phydump

#####################################################
# ce0 (logical=1, physical=1)
#####################################################

Current PHY control settings of ce0 ->
Preemphasis              = 0x164608
DriverCurrent            = 0xffffffff
DFE ENable               = True
LP DFE ENable            = False
BR DFE ENable            = False
LinkTraining Enable      = False
Interface                = 0xe
CL74                     = False
CL91                     = False
CL108                    = False

 tscf16_phy_pmd_info_dump:539 type = 4096 laneMask  = 0xF, Address = 0x81
 tscf16_phy_pmd_info_dump:608 type = CFG


***********************************
**** SERDES CORE CONFIGURATION ****
***********************************

uC Config VCO Rate   = 180 (~25.750GHz)
Core Config from PCS = 0

Tx Lane Addr 0       = 3
Rx Lane Addr 0       = 0
...

xled ARGS

The SAI’s LED-processor helper. This is a front-end keyword, not an SDK command; it is recognised when xled is the first word of the line, and up to 128 words are passed to it.

Unvalidated

drivshell>xled

Blocked commands

The front-end refuses a few lines to protect syncd: the bare sh and anything starting with she (the SDK’s shell command, which would run Linux commands inside the syncd container) and anything starting with reb (reboot, which would stop the SDK and with it syncd). The refused line never reaches the SDK.

Warning

This block list only checks the start of the raw line. The same dangerous SDK commands can still be reached in other ways:

reset is an alias of reboot. It makes syncd exit, which restarts the switch dataplane.
exit clean frees the SDK’s resources for all attached units; this is what the SAI itself does at shutdown.
sh CMD is not blocked; only the bare line sh is. It runs CMD as a shell command, as root, inside the syncd container.
Text after ;, after leading spaces, or after a unit prefix such as 0: is never checked against the block list.

Do not run these on a production switch.

Leaving the shell

quit (exactly) leaves the drivshell> prompt but does not stop syncd. About a second later the shell is enabled again: a connected client sees Hit enter to get drivshell prompt.., and pressing Enter brings drivshell> back.
exit and QUIT do nothing. exit clean is not harmless; see the warning above.
Disconnecting (Ctrl-C in bcmsh, or bcmcmd finishing) leaves the shell at drivshell>, ready for the next client.

Shell modes and prompts

Prompt	How you get there	How you leave / notes
`Hit enter to get drivshell prompt..`	The shell has just been (re-)started by `syncd`.	Press Enter. This is not a real prompt; the shell is only waiting for a newline.
`drivshell>`	The default.	`quit`.
`cint>` (with a trailing space)	`cint` with no arguments. Prints `Entering C Interpreter. Type 'exit;' to quit.`	`exit;` returns to `drivshell>`. `cint FILE [ARGS…]` runs a file (at most 16 arguments) and returns without changing mode.
`FAILED(TEST).0>`	A diagnostic test failed under the test framework. Prints `Type "exit" to return from sh`.	`exit`. This is a nested classic SDK shell, so the classic-shell features listed below work inside it.
`?` (with a trailing space)	Continuation prompt after a line ending in `\`, in the classic SDK shell only (including `FAILED` shells); not in `drivshell>`.	—

The classic SDK prompt BCM.0>, shown in Broadcom documentation, cannot be reached on SONiC. There are no other mode prompts. The mode command switches the SDK’s command set between ESW, LTSW and CTSW; Trident 3 is ESW only, and the prompt does not change either way.

Differences from the classic BCM.0> shell

These classic-shell features are not available in drivshell>:

!! and !$ history substitution;
N: or N:: on its own to change the default unit. In drivshell> the unit is always 0, and N: alone does nothing;
\ line continuation, ~ to leave, and Type "EXIT" to exit shell on end of input;
the user-defined $prompt variable and the .debug prompt suffix;
Ctrl-C to interrupt a command (see Interrupting commands).

Everything else works as usual: ; chaining, quoting, variables, unit prefixes on individual commands, ? usage, rc scripts and the control commands.

Command-line syntax

Words and quoting

Words are separated by white space.
"…" and '…' group words; the quote characters are removed. Quotes can start in the middle of a word: a"b c"d is one word, ab cd. A line that ends inside a quote fails with ERROR: Command line ended while in a quoted string.
\x makes x literal everywhere, including inside quotes. A \ at the end of a line fails with ERROR: Can't escape EOL.
A statement can have at most 1024 words and 8192 bytes.

Chaining with `;`

; outside quotes ends a statement; the rest of the line runs next.
Statements run left to right even if an earlier one fails. The line stops early only on a usage error, an exit, or an interrupt.
The result of the line, and the Failed to execute… message, reflect the last statement that ran. $? is updated after each statement.

Hardware-validated

drivshell> echo "a  b" 'c;d' e\;f; echo second
a  b c;d e;f
second

Comments

There is no comment character on the interactive command line. A line starting with # is looked up as a command called # (see Unknown commands and rc fall-back).
Use noecho (Parameters: <Any text> Ignore whatever follows on command line) as a comment that is safe interactively.
In rc scripts loaded with rcload, everything from the first # to the end of the line is removed, even inside quotes.

Variables

Expansion. $name and ${name} are replaced with the variable’s value; @name is a deprecated synonym. Names consist of letters, digits, _ and ?. Variables are expanded inside double quotes but not inside single quotes. An undefined variable expands to nothing. $?name expands to 1 if name is defined and 0 if not.
SDK and config variables. If a name is not a shell variable, the SDK may also resolve it:
- $feature_NAME gives 1 if the chip has SOC feature NAME;
- any other name gives the value of the config.bcm property of that name, e.g. $portmap_1.
Scopes.
- local NAME [VALUE] sets a variable in the current scope. drivshell> itself has no local scope, so at the prompt local sets a global variable.
- setenv NAME [VALUE] sets a global (exported) variable. With no value it removes the variable.
- printenv [local|global|all] lists variables.
- Names beginning with _ are system variables. They can be read but not set.
- Each rcload runs in its own scope, with $1, $2, … set from its arguments.
- Variables set at the prompt stay set across bcmcmd calls and bcmsh sessions until they are removed or syncd restarts. Each bcmcmd call sees what earlier calls left behind.
Built-in variables.
- $? holds the numeric result of the last statement: 0 OK, −1 fail, −2 usage, −3 not found, −4 exit, −5 interrupted. It does not survive from one bcmcmd call to the next (it reads 0 there), so use it on the same line: expr 1 + 2; echo $?.
- For each unit the shell sets devname, ldevname, pcidev, pcirev, fw_prefix, unit<N> (=1), and the chip and device names as flags (=1).
Arithmetic. expr EXPRESSION evaluates a C-style integer expression and returns the value as the command result, usable in if.

Hardware-validated

drivshell> local port 5
drivshell> echo port is $port, quoted '$port', defined $?port
port is 5, quoted $port, defined 1

Command names and lookup

Matching. Command names are matched case-insensitively. In a command name such as PortStat, the upper-case letters are required and the lower-case ones optional: portstat, ps and PS all work, and RCLoad accepts rcl or rcload. If more than one command matches, the first wins, unless a later command’s full name is a prefix of what was typed.
Lookup order.
1. commands added at runtime for the unit (such as BCMSAI);
2. the shell built-ins (80 commands);
3. the chip’s own commands (ESW on Trident 3).
Because the built-ins come first, sh runs SHell, not a SHOW-family command.
Integers as conditions. A statement that is just an integer succeeds if it is non-zero and fails if it is zero. if relies on this.
Excess arguments. If a command succeeds but did not use all its arguments, the shell prints CMD: WARNING: excess arguments ignored beginning with 'X'.

Unit prefixes

A statement can be prefixed with a unit specification. It then runs once per listed unit, with that unit’s variables in effect:

N:CMD: Unit N (one or two digits).
N-M:CMD: Units N to M.
N,M,…:CMD: A list; ranges are allowed in it.
*:CMD: All attached units.

Errors are Error: Bad unit specification and Error: Unit N is not attached. White space after the : is allowed. On single-ASIC Trident 3 only 0: and *: are useful. In drivshell> a bare N: does not change the default unit.

Help

CMD ? or CMD help, as the only argument, prints Usage (CMD): … with the command’s built-in usage text. The SoC property help_cli_enable=0 turns this off.
? lists all commands in a compact format. help (also ??) with no arguments lists commands with one-line descriptions; help CMD … prints usage for each command named.
A usage error is not reported as a failure in drivshell>, so bcmcmd exits 0.

Errors and result codes

The SDK prints its own messages, e.g. Unknown command: foo. The drivshell> front-end then adds one line, depending on the result:

SDK result	Mapped to	Extra line printed by `drivshell>`
OK, `>0`	0	—
USAGE (−2)	0	— (usage text already printed)
EXIT (−4), INTR (−5)	0	—
NFND (−3)	−7	`Failed to execute the diagnostic command. Error: Entry not found.`
FAIL (−1) / other	−11	`Failed to execute the diagnostic command. Error: Operation failed.`
NOTIMPL (−6)	−16	`Command "LINE" is not supported. Error: Feature unavailable.`
diag disabled / busy	−16	`Command "LINE" is not supported. Error: Feature unavailable.`

None of these change bcmcmd’s exit status. Scripts must look for these strings in the output. The extra line comes after the SDK’s own message, separated by a blank line, for example when log off finds nothing to stop:

drivshell> log off
File logging is not active.

Failed to execute the diagnostic command. Error: Operation failed.

Throughout this reference, when a command is said to fail, this is the line you see.

Unknown commands and rc fall-back

When a word is not a known command, the shell tries to run a script called WORD.soc, as if you had typed rcload WORD.soc. It looks for the file in each directory of $path, or in syncd’s current directory if path is not set. On SONiC path is . / and syncd’s working directory is /, so both entries mean the container’s root directory. The remaining words become $1…. Only if that also fails is Unknown command: WORD printed. Turn this off with set RCLoad=off.

Control commands

These are SDK shell built-ins; the usage text below is quoted from the built-in help. Each command argument is one complete command line, so quote any that contain spaces, and use single quotes to stop $var being expanded too early.

loop COUNT|* "CMD" …: Runs the commands COUNT times, or forever with *. It stops on the first failure while LoopError is on (the default). loop 10 "echo hello world".
for VAR=START,STOP[,STEP[,FMT]] 'CMD' …: for port=0,23 'echo port=$port'. FMT is a printf format; the default is %d.
if COND ["CMD" … [else "CMD" …]]: COND is an integer or a command line; &&, || and ! are evaluated left to right. if $?quickturn && !"bist arl" "echo BIST failed". IFError (default on) stops after the first failing command.
case WHAT VALUE "CMD" [VALUE "CMD"]…: Runs the command whose VALUE matches WHAT.
expr EXPRESSION: C-style integer arithmetic; the value becomes the command result.
echo [-n] TEXT… / noecho TEXT…: Print the words joined by single spaces; -n leaves out the newline. noecho ignores its arguments.
time ["CMD" …]: Times the commands, e.g. time "sleep 1" "sleep 2". With no argument it prints the current time.
sleep [quiet] [SECONDS [USEC]] / delay USEC: Suspend the shell, or busy-wait for USEC microseconds.
pause [-x] TEXT…: Waits for SPACE (or x with -x) or Q. Under bcmcmd there is no way to answer, so it waits until the timeout.
background "CMD", jobs, kill N: Run a command in the background, list background jobs, or kill one.

Hardware-validated

drivshell> for p=1,3 'echo port $p'
port 1
port 2
port 3

Hardware-validated

drivshell> loop 2 "echo hello world"
hello world
hello world

Shell options (`set`)

set with no arguments shows the options, and set OPTION=VALUE changes one. set = prompts for each option in turn, which makes bcmcmd wait until its timeout.

Option	Default	Effect
`IFError`	on	Errors terminate an `if` command list.
`LoopError`	on	Errors stop `loop`/`for`.
`RCError`	on	rcload scripts abort on a failing command.
`RCNoPrintError`	off	If on, rcload does not print the per-line error.
`RCLoad`	on	Unknown command → try `WORD.soc`.
`RCTest`	on	`testrun` loads init scripts before some tests.
`MoreLines`	20	Lines per page for `more`.
`ReportTime`	5	Seconds between progress reports of long tests.

rc scripts

rcload FILE [ARGS…]

Runs commands from FILE line by line. ARGS become $1, $2, … in a new local scope. FILE must exist inside the syncd container.

A trailing \ joins the next line, # starts a comment, and \r is removed.
A failing line prints Error: file F: line N (error code E): script terminated or … script continuing, depending on RCError. Lines starting with expr never count as failures.
A file with no lines prints Error: file F: empty script.
Nesting too deeply prints rcload: recursion too deep.

A path containing / is opened directly. Otherwise the file is looked up in the rccache, then in $path.

Keeps rc files in memory so that later rcload NAME calls do not read the file system.

The SAI itself runs reload.soc and rc.soc scripts in some situations. config.bcm handling is covered in Configuration variables.

Hardware-validated

drivshell> rcload /tmp/show-ports.soc ce0
                 ena/        speed/ link auto    STP                  lrn  inter   max   cut   loop
           port  link  Lns   duplex scan neg?   state   pause  discrd ops   face frame  thru?  back   encap
       ce0(  1)  !ena   4  100G  FD   SW  No   Forward         Untag    F    CR4  9122    No          IEEE

Line editing, history and output

Echo. The shell echoes your input itself. That echo is why bcmcmd output starts with the command line.
History. history [COUNT] lists the shell’s history, but drivshell> lines are not recorded in it, so it prints nothing. In bcmsh, up-arrow history works locally.
Paging. Command output is not paged. Only more FILE pages, and pause waits, using MoreLines lines per page.
Console and log. console on|off turns console output on and off. log file=F [append=yes|no] [quiet=yes|no] [on|off] copies output to a file inside the container.

Files inside the `syncd` container

The shell’s file commands (ls, copy, save, log, rcload, rm …) work on the file system of the syncd container, as root. /tmp there is a tmpfs of its own, mounted noexec: the shell can write and read files in it, but nothing in it can be executed.

To give the shell a file from the host, such as an rc script or a Cint program, copy it to /root in the container and use the absolute path:

sudo docker cp watch.soc syncd:/root/
bcmcmd "rcload /root/watch.soc ce0"

Do not copy into /tmp or /var/tmp: both are separate in-memory file systems inside the container, and docker cp into them reports success but the file never appears there. Files the shell itself writes to /tmp (for example with log) can be read back through the container:

sudo docker exec syncd cat /tmp/bcm-diag.log > bcm-diag.log

Interrupting commands

drivshell> has no way to interrupt a running command. Ctrl-C in bcmsh closes your session, but the command keeps running inside syncd, and its output goes to syslog. Sending a raw Ctrl-C byte over the socket is not expected to stop it either.

Do not start loop * or other unbounded commands in drivshell>. The only way to stop them is to restart syncd.

Accessing the shell

How the pieces fit together

How syncd starts the shell server

Host commands

Other network operating systems

Arista EOS

Cisco NX-OS

Juniper Junos (QFX5100, QFX5110)

Cumulus Linux

Extreme EXOS

The drivshell> front-end

Blocked commands

Leaving the shell

Shell modes and prompts

Command-line syntax

Words and quoting

Chaining with ;

Comments

Variables

Command names and lookup

Unit prefixes

Help

Errors and result codes

Unknown commands and rc fall-back

Control commands

Shell options (set)

rc scripts

Line editing, history and output

Files inside the syncd container

Interrupting commands

The `drivshell>` front-end

Chaining with `;`

Shell options (`set`)

Files inside the `syncd` container