SC2059: What about when escape codes (e.g. ANSI colors), not printf specifiers, are in the variable?

[techflashYT]

For bugs

• Rule Id (if any, e.g. SC1000):SC2059
• My shellcheck version (shellcheck --version or "online"): 0.10.0
• The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

For new checks and feature suggestions

• https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
• I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

#!/bin/sh

somevar="\e[1;31mSome red text\e[0m"

# this code functions correctly, but shellcheck produces SC2059
printf "$somevar\n"

# this code does NOT function correctly (printing a literal "\e[..."
# However, shellcheck doesn't complain.
printf "%s\n" "$somevar"

Here's what shellcheck currently says:

In a.sh line 6:
printf "$somevar\n"
       ^----------^ SC2059 (info): Don't use variables in the printf format string. Use printf '..%s..' "$foo".

For more information:
  https://www.shellcheck.net/wiki/SC2059 -- Don't use variables in the printf...

Here's what I wanted or expected to see:

No error about the line 6, as putting it outside of the format string, like in the latter example, does not produce the intended result.
OR
A different warning, explaining a better way to handle this case.
OR
Information about this case added to the SC2059 wiki page, which currently only specifies what to do in the case of there being a % in the string.

[wileyhy]

Hello, Based on testing, it appears that bash, ksh and mksh, if \printf\ lacks any conversion specifiers, will automatically interpret the example color code sequence correctly. If the conversion specifier '%s' is used, then the example color code will not be interpreted / printed as a color, rather as a string. Under POSIX, the '%b' conversion specifier is described: "An additional conversion specifier character, b, shall be supported as follows. The argument shall be taken to be a string that can contain <backslash>-escape sequences." I don't use dash on a regular basis, so I can't explain why this is so, however, it appears that dash, in order to interpret the color code correctly, requires an absolute path: \/bin/printf '%b' "${somevar}"\. Wiley #!/bin/sh -x # shellcheck disable=SC2016 reset somevar="\e[1;31mSome red text\e[0m" export somevar for SH in sh bash dash ksh mksh do [ -e "$( command -v "${SH}" )" ] \ || continue printf '\n\nShell: \t%s\n' "${SH}" printf 'Tested correctly:\n' command "${SH}" -c 'printf "$somevar\n"' printf 'Tested incorrectly:\n' command "${SH}" -c 'printf "%s\n" "$somevar"' printf 'Correct command:\n' command "${SH}" -c '/bin/printf "%b\n" "$somevar"' done

…

On Mon, Dec 2, 2024, 09:21 Techflash ***@***.***> wrote: For bugs - Rule Id (if any, e.g. SC1000):SC2059 - My shellcheck version (shellcheck --version or "online"): 0.10.0 - The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086) - I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit For new checks and feature suggestions - https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this - I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related Here's a snippet or screenshot that shows the problem: #!/bin/sh somevar="\e[1;31mSome red text\e[0m" # this code functions correctly, but shellcheck produces SC2059printf "$somevar\n" # this code does NOT function correctly (printing a literal "\e[..."# However, shellcheck doesn't complain.printf "%s\n" "$somevar" Here's what shellcheck currently says: In a.sh line 6: printf "$somevar\n" ^----------^ SC2059 (info): Don't use variables in the printf format string. Use printf '..%s..' "$foo". For more information: https://www.shellcheck.net/wiki/SC2059 -- Don't use variables in the printf... Here's what I wanted or expected to see: No error about the line 6, as putting it outside of the format string, like in the latter example, does not produce the intended result. OR A different warning, explaining a better way to handle this case. OR Information about this case added to the SC2059 wiki page, which currently only specifies what to do in the case of there being a % in the string. — Reply to this email directly, view it on GitHub <#3093>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUF2F23A7VSU5RJ4BVFZVKT2DSJH3AVCNFSM6AAAAABS35GAFGVHI2DSMVQWIX3LMV43ASLTON2WKOZSG4YTENZSGYZTMMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ale5000-git]

This is safer:

somevar="Some red text"
printf "\e[1;31m%s\e[0m\n" "$somevar"

It will make sure that if the $somevar variable is passed and contains unsafe characters they are printed as is and not interpreted.