When a shell command inside a fenced code block contains {...} syntax in its arguments, shelldoc mis-parses the content as a code-block attribute directive (the same syntax used for {shelldoctimeout=30}). The result is a silently mangled command that either hangs or produces unexpected output.
To reproduce:
$ kubectl get application myapp -n argocd \
-o jsonpath='{.status.operationState.phase}'
Succeeded shelldoc parses {.status.operationState.phase} as a directive attribute on the code block, stripping it from the command before execution. The truncated command then blocks waiting for input or produces wrong output.
Workaround: wrap the command in a Makefile target or script so the {...} syntax never appears in the exercise markdown.
Expected behaviour: {...} should only be treated as a directive when it appears on the opening fence line (```sh {shelldoctimeout=30}), not when it appears inside the command body.
When a shell command inside a fenced code block contains {...} syntax in its arguments, shelldoc mis-parses the content as a code-block attribute directive (the same syntax used for {shelldoctimeout=30}). The result is a silently mangled command that either hangs or produces unexpected output.
To reproduce:
$ kubectl get application myapp -n argocd \ -o jsonpath='{.status.operationState.phase}' Succeededshelldoc parses {.status.operationState.phase} as a directive attribute on the code block, stripping it from the command before execution. The truncated command then blocks waiting for input or produces wrong output.
Workaround: wrap the command in a Makefile target or script so the {...} syntax never appears in the exercise markdown.
Expected behaviour: {...} should only be treated as a directive when it appears on the opening fence line (```sh {shelldoctimeout=30}), not when it appears inside the command body.