pinky-bar

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.
 
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.
 
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/)
Click to expand...

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
 
I have to give you thumbs up lme@. Haven't thought to add dvdrom/cdrom vendor and model name detection yet.
 
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
 
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.
 
FYI: On an Core i7 I have:

Code: 
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! :)
 
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.
 
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:

Code: 
# &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

pic6.png
 
Sometimes there's also
Code: 
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
 
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:

Code: 
  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);
    }
  }
 
Just in case you don't have certain setups, on my random laptop:
Code: 
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
 
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.
 
You must log in or register to reply here.
Back
Top