shfmt: allow ignore errors

[mhalano]

I have a script where I get this erros:

postgresql_backup.sh.epp:16:22: > must be followed by a word

This line isn't a redirect. The file is a Puppet's template which uses tags, so I need to ignore certain errors (because I know isn't errors for real).

The idea is create a way to pass a flag to ignore determined errors, like shellcheck do (option -e)

[mvdan]

I'm not sure I understand. Why would you run shfmt on a file which is not a shell script?

[mhalano]

It's a shell script, but will be parsed to include some values and after that will be written on the target machine to be executed. I can show you some lines of this file:

DATE=$(date +%Y%m%d%H%M)

<% if $timescale { -%>
PATH_NAME="psql-timescale-${DATE}"
<% } else { -%>
PATH_NAME="psql-${DATE}"
<% } -%>

TAR_NAME="${PATH_NAME}.tar.bz2"

/bin/mkdir -p "${PATH_BASE}/${PATH_NAME}"

You see there is a condition on the template (I'm using EPP, the default template for Puppet). Depending on the condition, just one line with PATH_NAME will be written on the shell script.

Did you get it now?

[mvdan]

Right. That's just not valid shell code, so I'm not sure how you expect it to be formatted.

If you want to write in a different templating language that outputs shell, that's fine, but only the output is shell. The input is not.

[mhalano]

I just want to ignore some rules, like the one I mentioned about a word after >. In this case > is part of the tag, not a redirect, so would be sane be able to ignore some rules. My case expands easily. Imagine someone or some company has a little different style guide and want to ignore just some rules.

[mvdan]

You're seeing parser errors. shfmt parses shell code before it's formatted. The only possibility that comes to mind for your use case is: when a parser error is encountered, ignore the rest of the line and try to continue parsing.

But that seems rather sloppy. What if your shell code has actual syntax errors? What if the language that's mixed in with shell happens to have lines that parse correctly as shell, and then get formatted when you don't want them to be? What if the line with an error is in the middle of a command, should we stop parsing the command or continue parsing it after skipping a line?

All in all, I don't see a way to do this.

[mhalano]

Shellcheck has all rules very well defined and documented, including codes for each one of them so I could exclude, like this:

In site/profiles/templates/postgresql/postgresql_backup.sh.epp line 16:
<% if $timescale { -%>
^-- SC1009: The mentioned syntax error was in this simple command.
                 ^-- SC1083: This { is literal. Check expression (missing ;/\n?) or quote it.
                     ^-- SC1073: Couldn't parse this redirection. Fix to allow more checks.
                      ^-- SC1072:  Fix any mentioned problems and try again.

For more information:
  https://www.shellcheck.net/wiki/SC1083 -- This { is literal. Check expressi...
  https://www.shellcheck.net/wiki/SC1072 --  Fix any mentioned problems and t...
  https://www.shellcheck.net/wiki/SC1073 -- Couldn't parse this redirection. ...

You can see the error code SC1073 is the same error (can't parse the allegedly redirection), but with shellcheck I can specify -e SC1073 and this specific error will be skipped. So the idea (I know it isn't a short or easy task) is to document the errors, create codes for them and allow to be skipped.

[mvdan]

Right, the parser would need a substantial rewrite, and it's not clear how we would handle the edge cases that I mentioned above.

For shellcheck, it probably makes sense to separate its checks into rules that can be ignored, and have a form of fallback when there is invalid syntax in a command.

For shfmt, I honestly doubt that makes sense. You either apply the formatting, or you don't. The formatting isn't a separate set of checks or transformations that could be applied selectively.

The only possible change I can see here is a way to make the parser skip over lines which have syntax errors, like I mentioned before. But that still has rough edges and could lead to bad formatting, so I'm inclined to not do it.