[Python 3] Console Battery Monitor In Python [Using BAT0]

I never took up Lua, despite having a Lua-based Window Manager (AwesomeWM), I've been able to feel my way around with the help of some friends as well as a bit of googling. "Implementing a battery monitor into the wibox seemed wasteful," I thought. "Why not create a terminal battery monitor for the good of learning?"

And so I did.

Here's what the output looks like:

Here's the code [Image]:

Here's the code again[plain text]:

#!/usr/bin/python
# The full charge.

cf = open('/sys/class/power_supply/BAT0/charge_full')
cf = int(cf.readline().strip('\n'))

#The current battery charge

cn = open('/sys/class/power_supply/BAT0/charge_now')
cn = int(cn.readline().strip('\n'))

st = open('/sys/class/power_supply/BAT0/status')
st = st.readline().strip('\n')

# Creating the Percentage
   
percent = (cn / cf) * 100
   
#  Creating the Rounded Percentage
   
percents = str(percent)[0:2]
rpercent = int(percents)


def batMon(cf, cn, st):


    # Testing Whether or not it is Charging
    if rpercent == 20 and st != "Charging":
        print("\n!!!! Battery is low! Please charge it now!!!!")

    print("\n[Charging]: %s" % st)

    # Printing out the total Voltage to the console
    print("[Total Charge]: %d" % cf)
   
    # Printing out the current voltage to the console
    print("[Current Charge]: %d" % cn)
   
    # Printing out the Rounded and the actual percentage
    print("[Round Percent / Percent]: %s / %.2f" % (rpercent, percent))




if __name__ == "__main__":
    batMon(cf, cn, st)

This was a pet project of mine for a while. I just recently decided to get into it. It's released under GNU GPLv3.

Why I've stepped away from "Automated" AUR tools.

I've recently decided that I no longer have any interest in using things like yaourt, pacaur, etc... Because I find that it gives way to me spending less time actually reading the PKGBUILD and coming to a much more rounded (and/or experienced) understanding of what it is to "build" a package. I want to spend more time actually figuring out how the PKGBUILD's work so that later on when I'm trying to figure out what broken, where and why, I'm not stuck scratching my head and sounding like an idiot.

"Why didn't it install?"

"'Dunno, kind of thinking that it had an error in the script."

"What script?"

"'Dunno, the one from the AUR."

"Uh-huh.."

It's also a bit annoying, when the PKGBUILD is trying to install a dependency that doesn't really exist [Don't believe that AUR PKGBUILD'S ever have this problem? Try installing lmms-vst...], and after waiting, what seems like an hour, for it to all install, you read: "Aborted...; Restart?" Very much frustrating. Besides, it would make me feel a bit proud to one day be able to determine what's wrong with it before I ever install it, on top of the fact that pacman makes it easy to build and then install a package, I simply don't see a need for two different package managers on my system anymore, it simply doesn't make sense to me and makes me feel like I'm turning "lazy." Which is a good and a bad thing. Good because, well, convenient, fast, less time debugging, less time thinking about what's inside the package. Bad, for some of the same reasons that it's good, and also because when breaks happen, it sucks to do it the "Winblows" way and uninstall and reinstall the package over and over again...

Now, I have nothing against it if someone else wants to do that, and I highly recommend a package manager like yaourt, pacaur, or something else along those lines if you feel that you won't be able to get the job done somehow with the extremely simple system of:

cd /path/of/dir/that/PKGBUILD/is/in
makepkg -s
pacman -U *pkgname*-*pkgver*-.tar.xz

Now that I think about it, I might make a bash script that'll simplify the last two parts for me, but the reading of the build itself is the important part to me, actually understanding how the differently designed scripts are built... ust to hammer in my point, one more damn time.

[Python][Tidbits]Building A Python Module For "Personal" Use

My module has three different functions. Though, I feel that three functions is too many. It would seem that by using *kwargs, between the parenthesis I cannot create any other kind of parameter. *Sigh* I guess I'm going to have to either rebuild it, or edit the README. My goal is to minimize the code and maximize the performance. The construction of a Module that would be used "strictly for personal use" is not a bad thing here or there, but in excess, you'd pretty much spend more time writing modules, less time actually getting some things done. And that can be fun, but not when you're tried for time, or on a deadline.

You're better off googling around for code that someone else created, read the API, and then move on.

As a side note, I've recognized an issue in a scripting style that I've used just recently, the problems very easily being solved by reading over the Python 3 documentation, which I've only done about once or twice, but not as heavily as I have recently. Built-in String methods. Everything in Python is an object of a class, in this case: str(). A few good ones are:

.startswith():

This tests for a specific set of characters at the beginning of a message. It's case sensitive, so be careful. It returns true.

.endswith():

Tests for the end of a statement, this can be useful, though is restricted as far as case is concerned. Returns True.

.upper():

Makes all of the letters inside of the string uppercase.

.lower():

Makes all letters in the text lowercase.

Pro Tip:

When I first started out, I used to make massive, and ugly logic:

yesorno = input("Y\n ")
if yesorno == "Y" or yesorno == "y":

somecommand()

else:

 someothercommand()

Now I just:

yn = input("[Y\n]: ")
 if yn.lower() == "y":

somecommand()

else:

someothercommand()

It's just neater, easier to read, and far less code.

.capitalize():

This capitalizes the first letter in the first word. I used it here to capitalize a name. Good for possibly forms that would require name data.


.casefold():
.

Similar to .lower() but instead removes all case specifications in general.

They can also be compounded.

I hope these thoughts were useful. To read more about string methods, visit the Python Documentation.

[Xorg][Tutorial] Dvorak Keyboard Map Settings In System-Wide[Archlinux]

Yet again, I've discovered an even better means of setting the keyboard layout to dvorak. Much more simple than anything that I've yet discovered. The Archwiki is such a useful place to be when you're searching for answers for a long time problem!

As root, create the file /etc/X11/xorg.conf.d/10-keyboard.conf.

Then simply add this text to the file using your favorite editor [Mine being Vim]:
 

Section "InputClass"
    Identifier             "Keyboard Defaults"
    MatchIsKeyboard       "yes"
    Option               "XkbLayout" "dvorak"
EndSection

Then restart X (or logout and back in) and you're finished!

It even works for slim [Logging in with DVORAK at long last is possible!]:

Taring and Untaring .tar, .tar.bz, .tar.gz, etc... [Tutorial][Novice]

For those lacking time (or patience), the tl;dr (too long; didn't read) is at the bottom.

Tar -  The GNU version of the tar archiving utility

This is the command line application which we'll be learning today. It's a rather simple application, really, most tend to somehow mentally overcomplicate it. Remember that just using man [command] will usually yield the man(ual) page for a terminal command!

A "tar archive" itself is those little files that have extensions like .tar, .tar.gz, .tar.bzip, .tar.bzip2, and etc. How we handle each of them will change depending a bit on what our needs are.

 

 Alright, let's go right into our little black box, of course!

 Now inside the plg directory in myhome folder (short for playground), I've shown what's inside the current directory, as well as the farm directory

 

And here we go, we're actually creating a tar archieve! It's as simple as that. The switches can be broken up as: tar -c -f, but it's just easier to go tar -cf, as long as the tar archieve is right after the -f switch [Which specifies the archive of choice], there's no problem.

Want proof of what's inside? No problem, the -tf switches list everything! "But what about if we modify a file?" Do we have to 're-tar' all over again? No problem, -uf will only update the files in the archive that have been modified... Or created! When we add 'v' we can see everything that happens when it happens!

"But now how do we extract the tar?" Simple as that! tar -xvf the_tar_you_want.tar and it's done in record time!

 "What about .bz files?" What about them? To create them, just add a lowercase j anywhere in the primary switch! 

-jcf -jcvf -cjvf -cvjf... 

You get the idea!

 

 

 It's just intense how just adding a single letter changes everything and leaves it the same!

 Wow! Even .tar.gz files we can create! There's nothing to it with the -z switch added on!

And- You get the idea!

Hopefully, this tutorial was helpful enough for especially newbies to linux, as far as the tar command is concerned. I see a lot of these tutorials out there, but not many that actually use images of the prompt, step by step.

tl;dr

tar -cf creates regular .tar archive

tar -tf  lists what's inside the tar archive

tar -xf untars the regular .tar archive

tar -uf updates the tar archive with the newer versions of files, as well as adds new files that didn't exist before.

Adding j (in any order to -cf like -jcf, etc...) allows us to perform any of these things on .tar.bz files, z (same as j) allows these on .tar.gz, capital J (same as j and z)  allows it on .xz files.

Programming in C.

As of recent, I've decided that I would take the dive of going right into C programming. It isn't that I'm giving up on Python, that couldn't be far from the truth, it's that I feel that I would be able to understand much more in the software world, knowing C, before I would attempt to conquer using Python alone. I feel there is a gap in my knowledge, in other words, that can only be filled by learning C and perhaps later C++.

C is a bit different than what I'm used to, but I always get excited when I learn new Syntax. For a person who doesn't like change, this might be a bit of a struggle at first, but if you sit down a bit and calmly go over a tutorial or two online, then you should have no problem getting right into the groove of it all.

Pros:

C is incredibly fast. It tends to be speedier than Python, I believe, when it is executed. And that is an incredible bonus, over most, if not all, programming languages. 

C has a lot to offer. It seems to be incredibly modular.Looking at most standard C programs online, a C program doesn't come with builtins like Python does without calling "#include <stdio.h>", and while that may seem like a bit of an issue, it can actually be a plus when the program you're writing does not require certain builtins that Python comes preinstalled.

Cons:

C can be a bit difficult to understand. The learning curve for learning how to program in C verses how to program in Python is a bit steep especially if you're a beginner. I'll say that because I learned to program in Python, and because I took the time to research specific terms, as well as reading my Python Programming book, that I understood specific terms used while studying C. Searching the internet for these terms mentioned will help even the newbie understand some of even the most diverse jargon, though the reality is, does one have the time or want to apply the effort? Sure, it'll help in the long run, but humans can be impatient creatures. C is now, considered a Low-Level Programming language, though at one point it was considered otherwise.

C programs can become quite massive. It's true that takes about ten lines of Bash to program something that would need ten thousand lines of C. If you're one to get lost inside of your projects, and eventually wander out after haplessly searching for the path, you're not so fortunate to get hooked on C programming. There's nothing wrong with hard work and effort, but this is not so much a language for convenience.

C is a complied programming language. I'm sure some will come at me with daggers waving about how this should not be on the cons list, but hear me out. The write, compile, test/run process can be cumbersome to some, while to others it could be considered "a life saver" because, after all, if there is an error in your code, the compiler catches it.