Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix astyle Display Language Dependency & Makefile Colored Output #9441

Merged
merged 4 commits into from
May 9, 2018

Conversation

MaEtUgR
Copy link
Member

@MaEtUgR MaEtUgR commented May 8, 2018

This PR solves two problems which I found during Cygwin Toolchain usage:

  • astyle check passes in any case
    The shell script which checks the style relies on greping for the keyword "Formatted" in the output of astyle. But the program has localization support and will output in other languages e.g. german. This leads to all style checks always succeeding. I only tested this on Windows in Cygwin but I can imagine the problem also exists on non-english Ubuntu installations.
    Solution: is the parameter --formatted of astyle which only produces any output if there was something to fix. This allows for a display language independent condition for an empty string inside the shell script.

  • Makefile colors do not work e.g. \033[0;34mFormatting with astyle \033[m
    Certain terminal combinations like cygwin - mintty - xterm - bash do not escape colors by default.
    Solution: Force interpretation of backslash escapes with the parameter -e of echo.

I also switched the colored messages to a lighter blue (94 instead of 34) because in certain terminals default blue is hard to read on black background while on linux both blues were easy to read (see pictures).

terminal1
terminal2

The shell script which checks the style relies on greping for the
keyword "Formatted" in the output of astyle. But the program has
localization support and will output in other languages e.g. german.
This leads to all style checks always succeeding. I only tested this
on Windows in Cygwin but I can imagine the problem also exists in
non-english Ubuntu installations.

Solution is the parameter --formatted of astyle which only produces
any output if there was something to fix. This allows for a display
language independent condition for an empty string inside the shell
script.
Force interpretation of backslash escapes with the parameter -e of echo.
Switch to a lighter blue because on certain terminals default blue is
hard to read on black background.
@MaEtUgR MaEtUgR added the bug label May 8, 2018
@MaEtUgR MaEtUgR self-assigned this May 8, 2018
@MaEtUgR MaEtUgR requested review from bkueng and julianoes May 8, 2018 12:49
@MaEtUgR MaEtUgR changed the title Fix astyle Display Language Dependency & makefile colored output Fix astyle Display Language Dependency & Makefile Colored Output May 8, 2018
@MaEtUgR MaEtUgR force-pushed the pr-fix-astyle-language-dependency branch from bc3f4d6 to ef3d170 Compare May 8, 2018 12:49
@MaEtUgR MaEtUgR changed the title Fix astyle Display Language Dependency & Makefile Colored Output [WIP] Fix astyle Display Language Dependency & Makefile Colored Output May 8, 2018
@MaEtUgR
Copy link
Member Author

MaEtUgR commented May 8, 2018

I just manually tested on linux and the escape parameter gets put out to the terminal -e Formatting with astyle... I have to look up why.

It seems that on linux only inside a makefile the parameter after the echo
command gets printed if no single quoted sting comes afterwards so I had
to switch to single quotes such that I can use the parameter.
@MaEtUgR MaEtUgR changed the title [WIP] Fix astyle Display Language Dependency & Makefile Colored Output Fix astyle Display Language Dependency & Makefile Colored Output May 8, 2018
@MaEtUgR
Copy link
Member Author

MaEtUgR commented May 8, 2018

Fixed:

It seems that on linux only inside a makefile the parameter after the echo
command gets printed if no single quoted sting comes afterwards so I had
to switch to single quotes such that I can use the parameter.

I successfully tested also on linux now.

${DIR}/fix_code_style.sh --dry-run $FILE | grep --quiet Formatted
if [[ $? -eq 0 ]]; then
CHECK_FAILED=$(${DIR}/fix_code_style.sh --dry-run --formatted $FILE)
if [[ $CHECK_FAILED ]]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check for an empty string like this: if [ -n "$CHECK_FAILED" ]; then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, I changed it.
For anyone else interested here's the explanation for the -n parameter in the man pages of test: https://linux.die.net/man/1/test

Thanks to @bkueang 's review comment I switched to an explicit check for
an empty sting instead of a condition that could be theoretically true
in other cases and is less readable.

Type "man test" on your terminal to read up what -n stands for.
@MaEtUgR MaEtUgR mentioned this pull request May 8, 2018
@bkueng bkueng merged commit 2c56cee into master May 9, 2018
@bkueng bkueng deleted the pr-fix-astyle-language-dependency branch May 9, 2018 05:54
@haozhang-yuneec
Copy link

@MaEtUgR M
FYI

Makefile colors do not work e.g. \033[0;34mFormatting with astyle \033[m
Certain terminal combinations like cygwin - mintty - xterm - bash do not escape colors by default.
Solution: Force interpretation of backslash escapes with the parameter -e of echo.

This change introduce a new issue in MacOS console:

bash-3.2$ make format
-e \033[0;94mFormatting with astyle \033[m

@MaEtUgR
Copy link
Member Author

MaEtUgR commented May 28, 2018

@haozhang-yuneec Thanks for reporting! Unfortunately I have no access to a mac to test this. I assumed it would behave the same as a linux terminal... (Why does every console have to be different?)
Issue for that here: #9495

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants