Problem with multilines long help

[Morikko]

You say in the doc here that with the long argument we can use \n to go to the next line.

However, when I did this the help print the "\n" rather than going to the next line.

After trying in my terminal I saw for printf "%s\n" "\nsalut" that the \n in the first string is used as new line and the one in the second string is printed as "\n"

[matejak]

You are right, the behavior does not match. The solution to the problem is not so straightforward as using echo -e is not portable and the (documented) behavior when passing the string as the first arg to printf is also not good as it makes weird things if your help string contains the percent % sign.
I will figure something out though.

[Morikko]

I found something that looks good from that stack question.

A solution might be to replace:
printf "\n%s\n" "My long help description\nAnd so on..."
with
printf "\n%s\n" $'My long help description\nAnd so on...'

[matejak]

This looks damn good. The tricky part is the need of having $'foo\nbar', but $"foo\nbar" doesn't work, which is bad in case one needs to format stuff s.a. "option blah (default: 'blabla')" (or even default: '$my_default', which allows for having the default as a value of a Bash variable).
However, I see the potential here, it is enough to quote the long help description.

[Morikko]

Yes I see.. Probably for those cases you will need to manage a different code at the generation time.
Only text --> Quote style --> $'my\ntext'
Variable (start with $) --> Double quote style --> "$variable"
Text with <'> --> Escape the <'> --> $'my\'text'\'

And you can combine strategy:
essai=ligne2; printf "%s\n" $'ligne1\nligne1.5\n'"$essai"$'\nligne\'3\''

More complicated to implement for sure but will manage (almost) all cases!

[matejak]

I see, there would be an issue with words s.a. don't, where backticks need to be escaped. In this case, I find it easier to substitute \n to literal newlines, that should work.