> This is currently ignoring all template files correct? these also have bash in them, but don't have a hashbang
Ah, correct. The command would probably be `shfmt -l -w . srcpkgs/*/template` then. The diffs I posted should still work OK as an example of the changes.
> Personally I don't like the pipe symbol | and logic operators &&, || being moved to the next line.
I initially thought the same. Even more, the `\` can be ignored as these tokens accept a newline after:
```sh
foo &&
bar
```
I went with this format because it's simpler to see what commands are chained together and how. If the `&&` is at the beginning of the line, one can quickly see it which might not be the case if the lines are long or complex.
This is also mentioned in the Google shell style: https://google.github.io/styleguide/shell.xml#Pipelines
> I think the spaces around `|` in case statements are confusing.
I'm not sure about this one. I've spaced `;;` in single-line case statements for the same reason that `&&` and others are spaced. In this case, sometimes switch cases can become complex:
```sh
case $a in
b|c) foo ;;
*"some long string"*|"some other long string") bar ;;
esac
```
This is a very silly example, but from experience I prefer to always space cases to ease readability in complex ones and to stay consistent in the rest.
Closing note, though - I've tried to keep as little options as possible to avoid a case such as the amount of options that `indent` has; see `man indent`. On the other hand, I've had people raise the `\\n &&` vs `&& \\n` before, so I'm open to adding an option for it if you guys have a strong feeling about it.
This is not some kind of strong feeling but a matter of the status quo in existing scripts.
Of course we could all adhere to a new style. The question is, if the majority wants to do that.
> my comment was about the OR patterns in case statements, it could be read as "b " or " c".
Hadn't thought about that, but I've never had that problem myself. What do you think about complex glob/match examples as in the one I gave above?
I'm in favour of spacing when in doubt, so I'm still somewhat in favour of the current format.
> The question is, if the majority wants to do that.
Perhaps we should wait on the opinion of more contributors then?
Updated diffs, running `shfmt -l -w . srcpkgs/*/template` to also do all templates.
`git diff` - https://clbin.com/bKP2J
`git diff -w` - https://clbin.com/ZiDEP
Incremental runs (after the first run, not writing to files in disk) take about 0.8s on my machine.
To ease testing and perhaps its use in CI, I've released the first version and uploaded binaries:
https://github.com/mvdan/sh/releases/tag/v0.1.0
Bump. Would it be an easier process if I did a pull request running the tool on a set of helper scripts, excluding `srcpkgs` for now? That should keep the diff small and not incur as many merge conflicts.
I'm going to close this, as there doesn't seem to be enough interest.
@pullmoll @ebfe @Duncaen @Vaelatern in case you're interested, the upcoming 2.0 release keeps `&&`, `||` and `|` symbols in the same line without a backslash. There will be a new flag to get back the old, google-style behaviour.
If anyone wants to try to move this forward I'll be happy to help with any bugs or questions. Thanks!