# pinky-bar



## gozizey (Aug 22, 2016)

Gather some system information and show it in this statusbar program, not tied to any Window Manager, terminal multiplexer, etc. - https://gitlab.com/void0/pinky-bar


----------



## Murph (Aug 22, 2016)

gozizey said:


> Gather some system information and show it in this statusbar program, not tied to any Window Manager, terminal multiplexer, etc. - https://github.com/wifiextender/pinky-bar


Thanks for being inclusive of FreeBSD with your tool.

Remember that many people in FreeBSD land are allergic to typing `./configure`.    You may wish to consider submitting a port for it.  The Contributing to ports article and Porter's Handbook should point you in the right direction.


----------



## gozizey (Aug 22, 2016)

Thanks it means a lot to me. Feel free to suggest system information that tend to change over time and other people might find interesting to be obtained.


----------



## lme@ (Aug 22, 2016)

Thanks for this, I like status bars! 

You could use libstatgrab (https://www.i-scream.org/libstatgrab/) to gather the information for both Linux and FreeBSD (and maybe other OSes?) , then the OS-specific code-delta would be much smaller.


----------



## gozizey (Aug 23, 2016)

Thanks guys.

Most people assume that any "status bar" program has no other capabilities than taking some *stdin* info (which has to be provided by the user) and showing it.

The program started as status bar only for dwm back in februrary 2015 when I moved from openbox to dwm.
Wrote it in my very first day as dwm user and featured only 5 options at the time.
Half year later I was disappointed that the program had zero stars which meant a total failure to me and the development ceased. Shortly after that I went to work in Europe.
When I got back I saw that 3 people starred the program and that thing encouraged me to restart the development.



> You could use libstatgrab (https://www.i-scream.org/libstatgrab/)



Not going to expose each flaw, but https://github.com/i-scream/libstatgrab/blob/master/src/libstatgrab/network_stats.c#L429, some error checks are not presented, such as *net_ptr->ifa_addr* might be null - https://github.com/mcproxy/mcproxy/pull/1/files


----------



## gozizey (Aug 23, 2016)

I have to give you thumbs up lme@. Haven't thought to add dvdrom/cdrom vendor and model name detection yet.


----------



## Maxnix (Aug 23, 2016)

Nice work.  You could even add an option to monitor the swap usage.


----------



## gozizey (Aug 24, 2016)

Wanted to mitigate the sensors specific module naming in FreeBSD that plays role in obtaining the motherboard temperature, voltage and fans values with lm_sensors alternative, so I spend around 1 hour reading various man pages to learn how the api works and write the code afterwards.

Unfortunately lm_sensors is not available to the BSD world.

Does all the sensors modules values will always point to (do not include amdtemp/coretemp):

dev.MODULE_NAME.0.temp.0 - cpu
dev.MODULE_NAME.0.temp.1 - motherboard

Is there are any guarantees that the naming will be consistent across all the various sensors modules, the following example values are from *aibs*:

It will always point to
dev.MODULE_NAME.0.temp.0

neither to
dev.MODULE_NAME.temp.0

nor to
dev.MODULE_NAME.temp


----------



## gozizey (Aug 24, 2016)

Just finished my daily jogging sat down and wrote the swap function, it will retrieve the used swap in MB. Could test it only on a single drive with single swap partition. With this addition the program ran out of short options.


----------



## lme@ (Aug 24, 2016)

FYI: On an Core i7 I have:


```
dev.cpu.3.temperature: 51.0C
dev.cpu.3.coretemp.throttle_log: 0
dev.cpu.3.coretemp.tjmax: 105.0C
dev.cpu.3.coretemp.resolution: 1
dev.cpu.3.coretemp.delta: 54
dev.cpu.2.temperature: 51.0C
dev.cpu.2.coretemp.throttle_log: 0
dev.cpu.2.coretemp.tjmax: 105.0C
dev.cpu.2.coretemp.resolution: 1
dev.cpu.2.coretemp.delta: 54
dev.cpu.1.temperature: 54.0C
dev.cpu.1.coretemp.throttle_log: 0
dev.cpu.1.coretemp.tjmax: 105.0C
dev.cpu.1.coretemp.resolution: 1
dev.cpu.1.coretemp.delta: 51
dev.cpu.0.temperature: 54.0C
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.coretemp.tjmax: 105.0C
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.delta: 51
```

Thanks for working on this!


----------



## gozizey (Aug 30, 2016)

I'm going thru something in my life (it started a couple days ago) and don't want to much more in details. As temporary solution will provide a tarball source to pinky-bar https://bitbucket.org/betaNULL/infected-binaries/downloads/pinky-1.0.0.tar.gz

Stripped most of the linux code and snapshots. If there is a demand, I can upload the whole commits history dating back to june 2015 up to present days.

The sysutils/pinky-bar ports was submitted to the freebsd bugs page which you can browse and find it on your own if you want to use the Makefile instead.

Thank you everyone for the support and encouragement that you gave me.


----------



## gozizey (Sep 4, 2016)

Staring a new chapter in my life and with that I just opened a gitlab account and pushed pinky-bar. Among some of the changes is standalone pinky_curses program that takes stdin info and shows it with ncruses colours, the program is not tied to pinky-bar strictly so you can use it with/without pinky-bar as long as you format the stdin:


```
# &B - Blue , &M - Magenta , &Y - Yellow
while true; do echo "&BOh &Mhello &Ydear";sleep 1;done | ./pinky_curses
```

The ${HOME} page - https://gitlab.com/void0/pinky-bar


----------



## Juha Nurmela (Sep 5, 2016)

Sometimes there's also
	
	



```
hw.acpi.thermal.tz9.temperature: 0.0C
...
hw.acpi.thermal.tz0.temperature: 33.0C
```

Not a request. I do have the _dev.cpu.N.temperature_, just fyi.
Juha


----------



## gozizey (Sep 7, 2016)

Thanks for the report.

I'm currently using openbsd and trying to port the program. Their sensors api is neat as it doesn't require module naming to be used:


```
struct sensordev dev;
  struct sensor sens;
  int mib[] = { CTL_HW, HW_SENSORS, 0, SENSOR_VOLTS_DC, 0 };

  memset(&dev, 0, sizeof(struct sensordev));
  memset(&sens, 0, sizeof(struct sensor));

  size_t dev_len = sizeof(dev), sens_len = sizeof(sens);
  if (0 != (sysctl(mib, 3, &dev, &dev_len, NULL, 0))) {
    return -1;
  }

  for (mib[4] = 0; mib[4] < dev.maxnumt[SENSOR_VOLTS_DC]; mib[4]++) {
    if (0 != (sysctl(mib, 5, &sens, &sens_len, NULL, 0))) {
      return -1;
    }
    if (!(sens.flags & SENSOR_FINVALID)) {
      printf("%.2f\n", (float)sens.value / 1000000.0f);
    }
  }
```


----------



## Juha Nurmela (Sep 8, 2016)

Just in case you don't have certain setups, on my random laptop:

```
dev.acpi_tz.5.%location: handle=\_TZ_.BATZ
hw.acpi.thermal.tz5.temperature: 27.4C
```
Similar pairs for CPUZ, GFXZ, etc. Not all are working.

Juha


----------



## gozizey (Sep 11, 2016)

Thank you Juha, you are so kind. That's exactly what I stumbled upon in August 25-26 and wanted to mitigate with some sensors library. In linux as well in OpenBSD there is more than 1 way to obtain values from the sensors without using the module specific naming convention. Reading from "smbios" could be a starting point, but I'm not sure what's the U EFI equivalent to the smbios code that I have since I do not have any newer hardware made from 2013 onwards.

Sorry for the delays. I've been busy porting the program to OpenBSD in Wednesday and was almost done in the morning of Friday. Yesterday and today was days with high priority to port the disk io and battery related functions. All in all, only 1 option was not ported - the buffered ram.


----------



## Beastie (Sep 11, 2016)

@gozizey please update the first post to include the new page of your project instead of the dead Github link. Thanks.


----------

