To address your question of
why that happened: the cut(1) program (not a statement, BTW) will perform the same operation on all lines of input, so in the case of cut(1) doing something on two lines, the only thing I can think of is that grep(1) is for some reason spitting out two lines, because it finds a match on both lines; IDK why, because I'm not clear of the commands you ran. For
me, I just see the float number, and that should've been your result.
Here are some other ways to parse that data, where the final and best one uses just BASH via SYSFS:
Code: Select all
# Using AWK.
sensors -u | awk '$1 == "in1_input:" {print($2 " vDC"); exit(0)}'
# Using PERL.
sensors -u | perl -ae 'print("$F[1] vDC") if $F[0] eq "in1_input:"'
# Using your approach, but more accurately and reliably.
sensors -u | grep -Em 1 '^\s{2}in1_input:' | cut -d ' ' -f 4
# Using sensors(1) and BASH itself.
while read Key Value; do
if [[ $Key == in1_input: ]]; then
printf '%.3f vDC' $Value
break
fi
done <<< "$(sensors -u)"
# The most efficient approach, using just BASH.
# You will probably need to change the path.
read < /sys/class/hwmon/hwmon1/in1_input
if (( REPLY < 1000 )); then
printf '0.%d vDC' $REPLY
else
Left=${REPLY%???}
Right=${REPLY#?}
printf '%d.%s vDC' $Left $Right
fi
Koentje's solution was almost the best, but you probaly want the voltage,
not the millivolts, which, if you refer to the kernel
documentation, is what that file will store. My solution, shown above, handles the decimal point correctly, as long as it's under 9999 volts, which I'm sure it will never get to.
Ideally, I'd convert it properly (V = mV / 1000), but BASH doesn't support floating point arithmetic.
I recommend adding the most efficient approach (shown above) to a script, then having Conky just run that.
My benchmarks, each executed 100 times on an i5 4690K, if you're interested:
Code: Select all
# First method.
[I]terations = 100
[T]otal = 0.804s
T / I = 0.008s
# Second method.
[I]terations = 100
[T]otal = 0.808s
T / I = 0.008s
# Third method.
[I]terations = 100
[T]otal = 0.803s
T / I = 0.008s
# Fourth method.
[I]terations = 100
[T]otal = 0.821s
T / I = 0.008s
# Last method.
[I]terations = 100
[T]otal = 0.100s
T / I = 0.001s
And that's
including loading up the interpreter (BASH) each time. Honestly, everything but the last method is unreasonable, because sensors(1) is doing so much other crap that it's just wholly inefficient to use for this purpose. You're going to love the result from the last method, as it's so fast; you could literally spam it every few milliseconds.
