Description
Describe the problem
Arduino IDE receives two types of streams from Arduino CLI for display in the "Output" view, which are given distinct coloration to allow them to be visually differentiated by the user (#1064):
- stdout - printed in white
- stderr - printed in red
🐛 Some of the text from the stdout stream is given the stderr coloration.
To reproduce
Equipment
I encountered this during a "Burn Bootloader" operation with an AVR board. This adds a hardware prerequisite to the reproduction procedure.
- AVR-based Arduino board (e.g., Uno, Mega, Leonardo)
- ISP programmer (e.g., "Arduino as ISP", USBasp)
Steps
- Select File > Preferences... from the Arduino IDE menus.
- Check the box next to Show verbose output during > ☐ compile.
- Click the OK button.
- Connect the ISP programmer to the Arduino board and to your computer.
- Select the board, programmer and port (if applicable) in the Arduino IDE.
- Select Tools > Burn Bootloader from the Arduino IDE menus.
- Wait for the "Burn Bootloader" process to finish.
- Check the coloration of the command from the second step of the "Burn Bootloader" process.
🐛 The command, which is always printed to stdout, is colored red instead of the expected white.
Expected behavior
Output from stdout stream is always printed in white (or whatever color the theme dictates) in the "Output" view.
Arduino IDE version
Original report
2.0.0-rc9.1-snapshot-0b33b51
Last verified with
2.0.1-snapshot-bc264d1
Operating system
Windows
Operating system version
10
Additional context
I bisected the introduction of the bug to a54d7c8 (does not occur when using the build from the previous commit 84109e4).
I can see from the logs (the Burn Bootloader process was done with the arduino.cli.daemon.debug
setting enabled) that the text with the unexpected coloration was indeed in the out_stream
field of the response from Arduino CLI, not the err_stream
field:
2022-08-07 00:13:54 daemon INFO 75 | RESP: {
75 | "out_stream": "IkM6XFVzZXJzXHBlclxBcHBEYXRhXExvY2FsXEFyZHVpbm8xNVxwYWNrYWdlc1xhcmR1aW5vXHRvb2xzXGF2cmR1ZGVcNi4zLjAtYXJkdWlubzE3L2Jpbi9hdnJkdWRlIiAiLUNDOlxVc2Vyc1xwZXJcQXBwRGF0YVxMb2NhbFxBcmR1aW5vMTVccGFja2FnZXNcYXJkdWlub1x0b29sc1xhdnJkdWRlXDYuMy4wLWFyZHVpbm8xNy9ldGMvYXZyZHVkZS5jb25mIiAtdiAtcGF0bWVnYTMyOHAgLWN1c2Jhc3AgLVB1c2IgIi1VZmxhc2g6dzpDOlxVc2Vyc1xwZXJcQXBwRGF0YVxMb2NhbFxBcmR1aW5vMTVccGFja2FnZXNcYXJkdWlub1xoYXJkd2FyZVxhdnJcMS44LjUvYm9vdGxvYWRlcnMvb3B0aWJvb3Qvb3B0aWJvb3RfYXRtZWdhMzI4LmhleDppIiAtVWxvY2s6dzoweDBGOm0K"
75 | }
This is the Base64 encoding of the command:
"C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude" "-CC:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf" -v -patmega328p -cusbasp -Pusb "-Uflash:w:C:\Users\per\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.8.5/bootloaders/optiboot/optiboot_atmega328.hex:i" -Ulock:w:0x0F:m
Issue checklist
- I searched for previous reports in the issue tracker
- I verified the problem still occurs when using the latest nightly build
- My report contains all necessary details