Anyway, but we do know that this output is very predictable. We should know the temp will never come out as a single digit going below 10 degrees(or 3 character ie. 9.5). So we can safely assume in this case that the output will always be 7 characters total. That's the + sign, then 4 characters making up the numeric temperature(54.2), then the degree sign and C. So, use cut. ( check on terminal: cut --help )

(sidenote: there is the possibility that the output could come out as 100 degrees C which adds another character, but in this case it's not so bad it would only change the math by cutting off the decimal place... well 100C is just really bad anyway so who cares whether conky works or not during a fire)

It's just text, so you just observe the typical scheming there depending on which color or whatever. If you want a different color go to the end of the line and encapsulate it in some color markers. Or you could use the exising color and keep it inside the existing markers.

Just curious here...why use ${exec sensors ... } instead of using ${hwmon} or ${platform} for cpu temp?

I've always used hwmon, as that's how I first saw it, and exec seemed like something for advanced things.

I would think hwmon would be a more efficient approach, although the data is potentially different on each system so each person has to know what to go looking for(or just randomly test devices 0, 1, etc. and for each possible sensor 0, 1, 2), to tweak each config. Maybe it seems easier just looking at the sensors output then finding how to grep it for the situation?

but, for that matter, the output from sensors is equally different on any system too, and you still end up tweaking the values.

The conky variables doc does say,

"exec: Executes a shell command and displays the output in conky. warning: this takes a lot more resources than other variables. I'd recommend coding wanted behaviour in C and posting a patch."

So, it's a good point, and in these cases it would also eliminate the grep, cut, and more, even aside from the more resources of using exec.

Just curious here...why use ${exec sensors ... } instead of using ${hwmon} or ${platform} for cpu temp?

I've always used hwmon, as that's how I first saw it, and exec seemed like something for advanced things.

I would think hwmon would be a more efficient approach, although the data is potentially different on each system so each person has to know what to go looking for(or just randomly test devices 0, 1, etc. and for each possible sensor 0, 1, 2), to tweak each config. Maybe it seems easier just looking at the sensors output then finding how to grep it for the situation?

but, for that matter, the output from sensors is equally different on any system too, and you still end up tweaking the values.

The conky variables doc does say,

"exec: Executes a shell command and displays the output in conky. warning: this takes a lot more resources than other variables. I'd recommend coding wanted behaviour in C and posting a patch."

So, it's a good point, and in these cases it would also eliminate the grep, cut, and more, even aside from the more resources of using exec.

Makes sense, thankfully I have yet to run into a situation where hwmon or platform didn't work for me. Using exec sensors for something as simple as CPU temp seems to add complexity to a simple task, but whatever works, works...(hopefully)