Fix cute battery by pulling out icon decisions

[adamk33n3r]

I don't have an osx or freebsd machine to test these changes on, but I think they will work. I've also added some code for battery info in WSL, which is the linux I'm using.

I'm open to feedback and fixes if those systems aren't working anymore.

[adamk33n3r]

I saw there were some linter errors, but most of them were caused by previously existing code so I'm not sure what to do about those. I did fix the couple I added.

[xx4h]

First of all, thank you for contributing to tmux-powerline 👍

Could you quickly describe the issue you're trying to solve? Will be easier for me to understand what you're trying to achieve 🙂

Regarding the linter errors you wrote:

I saw there were some linter errors, but most of them were caused by previously existing code so I'm not sure what to do about those. I did fix the couple I added.

The whole codebase is linted and there are just two possibilities for the linter to complain:

1. The upstream linter got some updates so that he now finds something new to complain about.
2. You changed something that lets it complain (either by changing the line itself or something related) 🥲

To ensure it is not 1., i let the workflow for the main branch run again, which reported back that everything is still fine.
So unfortunately it has to be 2..

[adamk33n3r]

Could you quickly describe the issue you're trying to solve? Will be easier for me to understand what you're trying to achieve 🙂

This is to fix the issue I described here cab0747#commitcomment-143145213. The changes in that commit broke the way the cute mode worked. That commit added BATTERY_MED to what the cutinate function expected to just be a number.

The whole codebase is linted and there are just two possibilities for the linter to complain:

1. The upstream linter got some updates so that he now finds something new to complain about.
2. You changed something that lets it complain (either by changing the line itself or something related) 🥲

To ensure it is not 1., i let the workflow for the main branch run again, which reported back that everything is still fine. So unfortunately it has to be 2..

Looking at the linter logs, here is an example. https://github.com/erikw/tmux-powerline/actions/runs/9997569635/job/27639336899?pr=435

Looking at line 73 in the diff on this PR, you can see I didn't even change that line.

And the ones that reference lines that I did change, are just because I moved the line around control blocks etc.

You can see it's the same code as before, I just moved it.

All that being said, I'm happy to fix any issues. I just find it weird that it's complaining about stuff I didn't even change, and especially that you have now said that you ran it on the main branch and it's fine.

Let me know what you think!

[xx4h]

If you read the error of the linter, you'll actually understand why exactly the change you mentioned will bring up the error.
Before your change, the variables were only being used inside of the subshell.

The SC????-Codes are ShellCheck codes, which you can look up here: ShellCheck Wiki.
In this specific case, SC2030 will tell you to checkout SC2031, which states:

var was modified in a subshell. That change might be lost.
Problematic code:

There are many ways of accidentally creating subshells, but a common one is piping to a loop:

n=0
printf "%s\n" {1..10} | while read i; do (( n+=i )); done
echo $n

Correct code:

# Bash specific: process substitution. Also try shopts like lastpipe.
n=0
while read i; do (( n+=i )); done < <(printf "%s\n" {1..10})
echo $n

Even though you don't introduced the subshell itself, you tried to use the var outside of the subshell (by moving the line out of the subshell) and that's what the linter is now complaining about, as you can not modify/create environment variables in a child process and have them be modified/created in the parent process as well. The solution provided by ShellCheck will remove the subshell and therefore you'll be able to use the variables as you're used to.

The export is not necessary here (as it is only needed if you want it to be part of the environment for subsequently executed commands), but it is also not an issue.

[xx4h]

Fixed with #447