Even if successful, add-trailing-comma reading from stdin returns 1 as a status code in the shell. Is this the intended behavior?
idgserpro opened this issue · comments
Create a test.py:
# -*- coding: utf-8 -*-
test = [
1,
2
]add-trailing-comma - < test.py outputs correctly:
# -*- coding: utf-8 -*-
test = [
1,
2,
]But the return statuscode is 1:
❯ echo $? [11:30:11]
1This is a different behavior from other formatters, like black:
black - < test.py [11:30:46]
# -*- coding: utf-8 -*-
test = [1, 2]
reformatted -
All done! ✨ 🍰 ✨
1 file reformatted.
❯ echo $? [11:30:54]
0Some formatters in editors (like vim-autoformat) expect a 0 statuscode to make sure the formatter call was ok, and this is inconsistent with exit codes with special meanings.
Since the stdin feature comes from a month old PR (#75), I think it's nice to consider changing this to be standard like other tools.
The exit code behaviour is there for scripting purposes -- without it you can't discern from "made no changes" and "made changes".
Making the behaviour different for stdin would introduce an inconsistency. I don't think black's behaviour is a relevant precedent -- this tool predates black by almost 3 years.
The linked exit code documentation is for "bash scripting" and is not relevant here
The linked exit code documentation is for "bash scripting" and is not relevant here
The link is to show that in may situations, 1 is expected if something actually went wrong. We have similar behavior in git hooks.
Indeed, this issue is up to debate. That's why I opened in the first place asking for the intended behavior.
Exiting non-zero from this hook aborts the commit
that's actually the entire reason it exits nonzero -- to abort git commits