Collection of Tint2 executors


Whatever your decision is, I’m going to take steps as below:

  • add -h | --help and -ALL argument for use in CLI
  • separate as another project
  • rename, e.g. to “psusysinfo” or any better name
  • give it an /usr/bin command
  • add, according to Python packaging guidelines
  • add PKGBUILD

In case you decide either to include the package into AL repo, or make another use of the code, I’ll be glad.


Nice work - and pretty good on resources (the 8.4 is your example):

That’s right there with a conky or polybar showing the same information.

10.2 MiB +   1.5 MiB =  11.7 MiB	polybar


Thanks for testing! I haven’t compared with competitors so far :slight_smile:

I also like placing components in any location:



The script has just been converted into a psuinfo command, and published as a separate project. To stay up to date, you may want to install the psuinfo package (AUR).

The script is located in /usr/bin, so please change the line in your executor(s) from e.g.:

execp_command = python ~/tint2-executors/ -N

to simply:

execp_command = psuinfo -N

Available components and other command arguments described on the project GitHub site (link above).


^ well done.

Is there a way to get more space between the components? I tried adding spaces i.e change "GB " to "GB " but there didn’t appear to be any effect.

Also, sharpening my python skills and added memory used as a percent. The numeric load average is a different executor.


I like the idea.

If it comes to the separator between components: I used a single white-space to save on the length of resulting line. Since you never know which way the components may be ordered in user’s command, each of them has initially a single leading and trailing space. As soon as building the output is finished, all double spaces are turned into single. The leading and the trailing space of the whole line are being stripped in a single code line.

I assume we’re talking about the psuinfo command / package. If so:

Obviously you may change the line mentioned above for personal use. However, the /usr/bin/psuinfo command will be overwritten at the nearest package update. You’d need to rename the command and from now on use your own version (or both). IMO - keeping up with package updates would allow us to benefit from changes proposed by the others.

What I suggest is to modify the command / package by adding an argument to force use of a custom separator, for instance -S<your-string-here> the -S<number> argument to define number of spaces to use between components.

If it comes to displaying memory as percentage: this could be another component, e.g. -Cc for used and -CC for free memory %. I could code it, but if you’d like to contribute and commit a change to the project, I would be happy.


Wish I could, but I code slightly better than I teleport so no real value added there for your project.


Ha ha! Python is the most friendly language in the world. And each possible question has already been asked and answered on StackOverflow. :wink:

OK, I’ll add what you’ve already invented to the command, but remember you’re still invited.


@PackRat Done, psuinfo 0.0.2-1 in AUR.

psuinfo [-C{components}] [-F] [-N] [-S<number>] [-T] [-all] [-h] [--help]

-Cc - used memory per[c]entage
-CC - free memory per[C]entage

-S<number> - number of spaces between components (-S2 by default)

I know you used Z character, but I preferred c for per[c]entage.



I just used that because I quickly noted it wasn’t being used.


Your aur package failed validity check:

~~ looking for new pkgbuilds and fetching them...
==> Making package: psuinfo 0.0.2-1 (Fri 09 Nov 2018 09:48:49 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found psuinfo
==> Validating source files with md5sums...
    psuinfo ... FAILED
==> ERROR: One or more files did not pass the validity check!
2018-11-09 21:48:49,934 - wrappers - makepkg - ERROR - makepkg query ['makepkg', '-cf', '--noconfirm'] failed in directory /home/doug/.cache/aurman/psuinfo

That something on my end, or in your package?


Looks as if your AUR helper saw old md5sum in PKGBUILD (cached somewhere?) Should be:


This could be omitted, but PKGBUILDs including md5sums seem more trustworthy.

I’ve just checked with Trizen, Aurman and pamac. Trizen and pamac succeded at once. Aurman, crashed at 1st attempt, installed at the second.


What an excellent project, thanks for sharing!

Just a suggestion but have you considered replacing the bash shebang in your shell scripts with a plain POSIX variant instead (where possible)?


^ It makes no practical difference in a stock Arch Linux system but preferring POSIX over bash (when the extra features provided by bash are not needed) would allow a lower resource overhead for those who symlink /bin/sh to a faster, less buggy shell (such as dash).


That’s what it looked like initially. I changed to the current state, having noticed that scripts refused to work on BunsenLabs. Also some headings in python scripts are unnecessary in python 3.7. However, is seems impossible to make everyone happy with one AIO project. I think I’ll do what you suggested. Possibly a separate branch for Debian could be considered. Actually it would need another maintainer, as I only run BunsenLabs on VM.


Yes, BunsenLabs is Debian-based and so links /bin/sh to dash — any POSIX scripts that call bashisms will fail in that environment.

You can check your scripts with — I had a quick glance and I think it’s only the gt comparator that is missing from POSIX (but I may be wrong).


Very well then. I’ll change what’s needed tonight, as I’m back home.


I made a small PR on one of the scripts with a few changes.


I noticed, thanks! Let me take a closer look.

If it comes to the tint2-executors package - it’s nothing but a helper, possibly shouldn’t have been added to the project at all. Users should take care of dependencies on their own, at least at current stage of development.


I don’t feel anyone should need to install any package just to do some floating point arithmetic.