Error: <stdin>: syntax error in line 1 near 'digraph'

Did this terraform plan -out=tfplan followed by
terraform graph -type=plan -plan=tfplan | dot -Tpng > tfplan.png which gives the following error.

Error: : syntax error in line 1 near 'digraph

Environment: Windows10
dot -V: dot - graphviz version 8.1.0
terraform -version: Terraform v1.5.6

Hi @developer37,

Unfortunately I’m not sure what to suggest here. The keyword digraph is the typical initial token in a valid graphviz “dot” file representing a directed graph, so I cannot explain why the dot program would reject that input.

I do notice that in the error message you shared there seems to be a ' symbol just before digraph, but I’m not sure if that’s intended to be taken literally or if that was just the quotes around the keyword “digraph” and you’ve missed the closing quote when you copied the error message.

It might help to run the terraform graph ... command first, without piping it into dot, to verify that its output seems sensible. If you’re not sure how to decide if the output is sensible, you could share that text here and I will try to help review it.

If you do share any further code or shell output here, please mark it up properly as “Preformatted text” using the forum’s formatting features (in the toolbar above the editor window) so that the output is readable and won’t be misinterpreted by the forum software as normal text.

There seems to be a problem with windows file encoding. I had the same issue and solved it by saving the output of terraform graph first, then re-saving it with utf8-encoding. This made it work. I also needed to change dot -Tpng > tfplan.png to dot -Tpng -o tfplan.png to make the files readable.

Collapsing this into a single command is left as a n exercise for the reader.

Oh, that’s a good clue! I guess then probably what happened is that the GraphViz file was created using I/O redirection in PowerShell, which has an annoying habit of adding a redundant byte-order mark at the start of its UTF-8 output, which other software tends not to expect because UTF-8 doesn’t have “byte order” in the same sense that UTF-16/UCS-16 (used by the Windows API) do.

I guess graphviz was trying to complain about that byte order mark, but since it’s a nonprintable character it ended up invisible in the error message, making it seem like the tool was complaining about its own keyword.

Probably similar story about redirecting dot’s own output too. It probably got a byte order mark added and got incorrectly UTF-8 encoded, because the result of that command isn’t text and so needs to be written to disk verbatim rather than being transcoded by the shell.

I’m glad to hear you found a workaround. Thanks for sharing it!