Thanks for a great tool.
If you disagree and think this is just a matter of personal preference, no problem. Feel free to close. I think it looks a bit odd, but perhaps it makes sense in other contexts.
I'm using shfmt 3.12.0.
I use docopts in my shell scripts. Using docopts requires running eval "$(docopts <<EOF. shfmt moves the word docopts and everything after it to a new line, which I think looks odd. Here's a file before and after formatting. I would rather "shfmt" leave Before unchanged.
This is a case where I would have used something like # shfmt-disable-next-line if it were available, to prevent shfmt from changing this line, but the shfmt docs recommend opening an issue instead when one feels like doing that, so that's why I've opened this issue.
Before
#!/usr/bin/env bash
eval "$(docopts --help=- -A ARGS : "$@" <<EOF
Run "ls". This is just an example for a bug report.
Usage:
example-command
example-command -h | --help
Options:
-h, --help
Show this documentation
EOF
)"
ls
After
#!/usr/bin/env bash
eval "$(
docopts --help=- -A ARGS : "$@" <<EOF
Run "ls". This is just an example for a bug report.
Usage:
example-command
example-command -h | --help
Options:
-h, --help
Show this documentation
EOF
)"
ls
Thanks for a great tool.
If you disagree and think this is just a matter of personal preference, no problem. Feel free to close. I think it looks a bit odd, but perhaps it makes sense in other contexts.
I'm using shfmt 3.12.0.
I use docopts in my shell scripts. Using docopts requires running
eval "$(docopts <<EOF. shfmt moves the worddocoptsand everything after it to a new line, which I think looks odd. Here's a file before and after formatting. I would rather "shfmt" leave Before unchanged.This is a case where I would have used something like
# shfmt-disable-next-lineif it were available, to prevent shfmt from changing this line, but the shfmt docs recommend opening an issue instead when one feels like doing that, so that's why I've opened this issue.Before
After