DEV Community: gjorgivarelov

Datasets to practice on while studying data science- and would spreadsheets be considered a stepping stone?

gjorgivarelov — Tue, 11 Oct 2022 04:17:09 +0000

Hi,
So where would one find a dataset or three while self-studying data science to practice on? And if there are any, would their size be an obstacle for the consumer-level laptops and desktops that are typicaly used today?
I am looking for datasets to populate Google or Calc Spreadsheets with while aquiring a bit of spreadsheet literacy before taking on data science courses. And by the way, would you consider knowing spreadsheets as an essential skill to have before starting to use more complex data storage and manipulation tools?

Everybody is a developer

gjorgivarelov — Mon, 09 May 2022 19:44:41 +0000

If you are able to write as much code as necessary to print "hello world" in a terminal, you are a developer.
We've all encountered at some point apps that we deemed useless. Not the purpose of the app, not its importance in that moment of our lives when we installed it, it is the uselessness of the app when we attempt to employ it for the advertised functionality of the app and that functionality simply isn't there. And I also am not aiming at crash-prone apps, this is about apps that open just fine, stay on the screen fine as long as you are trying to use them but do not provide you with the functionality they were advertised to provide and that made you install the app on your personal device.
I was recently forced to use an app from that Big Time Telecom Inc to open a new type of account for the purpose of transferring my old account to this new type, with the accompanying new benefits. Advertised functionality, better than the old one, let's get it. Here opens a data collecting form asking for contact information of the primary owner. Fine, so I enter the required info and instantly get refused "this info is not of the required type of account". The required type is the type I wanted to transfer to. But I can't transfer without opening the new type of account first. But I can't open that new type of account because my old type isn't the new type. Somebody got paid to write this nonsensical code. Somebody over there got paid to write this dysfunction. If those people that wrote that app call themselves developers, then anybody and everybody is a developer. Grandma and her toddler grandchildren? Yep, developers! Teenagers at the mall? Developers they are!

Pyscript! Finally!

gjorgivarelov — Fri, 06 May 2022 06:32:35 +0000

For all of us who have had it with server side/client side programming languages separation and have had it with having to learn at least one language from both sides of the fence, our day has come!
If Java could have JavaScript as its web client programming language offspring (both languages actually not being related and naming the clientside scripting language after Java as a marketing gig aside), why can't the all-mighty Python have its own client side scripting language offspring called (aptly) Pyscript?
Despite the Pyscript project being in its very alpha stage of development, things look very, very promising. The two most exciting parts in its current stage of development (for Python developers at least) are the abilities to inject output of Python functions into HTML elements (provided you already tagged them with id=) and to enclose actual Python code at its full power within tags. Provided, any additional packages needed for that code to work are imported within the HTML's <head> tags, within <py-env>. Oh what could be imported? Well, how about matplotlib? Or NumPy?
What a great Cinco De Mayo this is! Head over to PyScript's project home on GitHub and get as excited about this project as I am now.

Permanently add a kernel boot parameter in RHEL 8

gjorgivarelov — Thu, 30 Dec 2021 09:25:47 +0000

In this post, I will describe how to permanently add a kernel boot parameter to either one of the kernels you have on offer to boot or to all of the kernels on your machine.

I recently wrote a post on how to change the root poassword on your RHEL 8 installation, where an important part of the whole procedure was adding a kernel boot parameter before the user boots a certain kernel. Adding a boot parameter at the end of linux16 line at the boot menu for a chosen kernel is a temporary solution that won't survive a reboot. Sometimes you'll be required to add a boot parameter that will be a permanent part of the kernel boot sequence. That need may arise if you added some new hardware component to your system after you installed and configured Linux on it. Or you are installing some software and part of the requirements for the successful installation is permanently enabling some kernel parameter at boot. Recently for example, while enabling virtualization on my RHEL 8 system, I was warned that I needed to enable a kernel boot parameter that wasn't enabled by default and on which virtualization depended.

Some great news

Although the "permanently enable a kernel boot parameter" may suggest a complicated procedure full of uncertainty, the good news is that it's not that difficult at all. And can be done while you are already running the kernel on which you need to enable that parameter.

The grubby tool- enable a kernel parameter for the currently running kernel

grubby is a useful tool when dealing with many issues connected to the boot procedure. In this case, this tool will help us enable that kernel parameter we need enabled at boot. Just tell it first for which kernel you need the parameter enabled, as well as the name of that parameter (become root first):

grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="some_parameter"

And for all the kernels on your system? grubby can do that too!

grubby --update-kernel=ALL --args="some_parameter"

What if... you wanted to actually turn off a kernel parameter so that it won't be available at boot?

grubby to the rescue again:

grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="some_parameter

And yes, reboot will be needed for the change to take effect.

Keyless entry (into your remote server)

gjorgivarelov — Sun, 19 Dec 2021 19:12:59 +0000

Most fairly recently built cars come with the feature called "keyless entry": the car would sense the presence of the key fob in your pocket and lets you open its door without having to manually unlock that door. In this article, I'll describe how to set up keyless entry to your remote server, so you won't have to type the password every time you try to access that remote server's shell. The process also relies on keys, but these are called ssh keys.

Is it all convenience?
Sure it is convenient to not have to type passwords to every remote server you need to log in to, but there's more than just convenience, sometimes setting up keyless entry is a requirement. Most obvious example is Ansible. If you plan to use that automation technology, setting up keyless entry is a must for everything else to work. Ansible is agentless, you don't need to install an Ansible-specific agent on the client but you must enable paswordless login.

Assumptions
I will assume you need to enable passwordless login on the remote server running some UNIX-like operating system (Linux, BSD, MacOS) and that you are using a client to log in that also runs such UNIX-like OS. I will also assume both machines have SSH up and running.
I am deliberately shunning Windows, after 11 versions of it and into the third decade of the 21st century Windows users are still required to install third party software to enable communication via SSH... ?!

The actual commands:
It's really simple, providing you already have proper credentials to log in to the remote server and have tested those credentials are valid.
First, create the key to be exchanged on your own server:
ssh-keygen
You'll be asked where to put the newly created key, agree with the default location offered. If you don't like the location, now's the chance to enter your own custom location but you'll need to account for that customization later, when you try to use passwordless login.
You'll be also asked to set up a passphrase. For trusted servers, on trusted connections, you can comfortably skip setting up passphrase.
Now that the key to be exchanged is created, it is time to exchange it with the remote server:
ssh-copy-id user@some.ip.address
where you swap the "user" with the actual username under which you are logging in onto the remote server and the "some.ip.address" with the actual IP address or the FQDN of the remote server. You'll be asked to enter password for that user on the remote server, and this is the last time you'll be entering that password. Once you enter the password, providing that's the right credential for that user on the remote server, the key is received and stored at the remote server.
You'll now be asked to use SSH to log in to the remote server to verify everything works as expected:
ssh user@some.ip.address
and you are logged in, no password asked for! And for the life of that remote server, or at least the key that was exchanged with it, this will remain enabled when you ssh into your remote server.

Just a bit of background on using SSH keys for passwordless entry:
When you used ssh-keygen, you actually created two encrypted files using the default RSA cryptosystem: one of those two files is called a public key and the other is called private key. That public key is what is being sent to the remote server. Private key is used to authenticate the public key received. The remote server will, upon receiving that public key from your machine, create its own private key based on the public key it received from you, so now logging in is automated, no need for your intervention with passwords, one machine presents its key, the other verifies the key is trusted and you are admitted in onto the remote server.
One cool thing you may want to try out, now that the passwordless login is set up, is to execute a command on the remote server and receive the feedback from that command on your own terminal. In this example, I'll keep it harmless and execute ls on the remote server but receive the feedback from that command on my own terminal all the while I am NOT logged in to that remote server:
ssh user@some.ip.address ls
and I'll get the contents of the home directory of the remote user "user".

Permissions. Yes, it is important.
Those keys that enabled passwordless login are now priced posession, keep them out of reach of malicious users on your own LAN. Recommended permissions on the private key are 600, meaning owner has read/write permissions but no permissions are given to anyone else on that server. Public key's permissions should be a bit more relaxed, having in mind that the remote server needs to read that file- set them to 644 (read/write for the owner, read/execute for the group to which owner belongs and for everyone else). You can always access those keys and verify their permissions, they are stored in your home directory, in the hidden .ssh subdirectory, and the public key is named id_rsa.pub. Use the ls -al command on .ssh subdirectory to verify permissions on those files.

Congrats, you just made logging into your remote server far more convenient now onto... Ansible!

Change the root password of your Linux server

gjorgivarelov — Fri, 17 Dec 2021 20:47:40 +0000

It just so happened: you needed to switch to root while working on your server but you forgot your root password. Or you inherited a Linux server without any documentation on it, not even login credentials. Or you read the list of exam objectives for Red Hat Certified System Administrator and you saw the root password recovery as one of the objectives. Or just for funzies, you wondered how could you change the root password since you stopped liking the current one. Read on, this post will walk you through the procedure of changing the root password of your Linux server, no need to know the old password.

What distro?

This post is written for and tested on RHEL 8. The procedure, with possible slight variations, should work on any other Linux distribution.

Any introductory walkthrough before the steps are shown?

No. I won't bother anyone with the boot sequence, BIOS, LILO, GRUB, GRUB2, associated config files... I think those terms are explained by so many other bloggers/Linux enthusiasts/IT professionals online already, it would be beyond redundant if I embarked to repeat the same explanations here.

So here we go, step zero:

Reboot/turn on your Linux server and interrupt the boot process by pressing the arrow keys once the boot menu appears.
The part of the boot process where at least some control is handed to the user is when a list of available kernels is offered to the user to choose which one to boot. By pressing the arrow keys the timer that counts down number of seconds before loading the default kernel is interrupted, the system gets a signal to pause the process and you get the chance to either choose a different kernel to load or edit boot parameters to the kernel you plan to load.

Step one, press "e" and locate the "linux" line of the list of kernel boot parameters:

Once the kernel loading sequence is paused, highlight the kernel you wish to boot (typically the default kernel you usually load to later work on your system and to which you want to change the root password to) and press "e" (stands for "edit"). You'll be shown a list of kernel boot parameters for the highlighted kernel, right below the list of kernels. Locate the line that starts with "linux". Depending on the distro and its version, this line may start with "linux", "linux16", "linux($name-of-kernel-arch-version)" or some other variation of these terms. Get to the end of that line and enter
rd.break
This is an instruction to the boot loader to enter a special shell that is used to recover a system that has trouble booting. One of the advantages of this shell is that the typical user hierarchy of a fully functional Linux system (with root on its top) doesn't apply, you are instantly given root powers while in this shell, without the need to enter any passwords. This will enable you to use the
passwd
command to change the password of the root user without being asked for its password, something that would happen if you tried that same command on a fully booted system.
So once you added the instruction to the boot loader to drop you into the rescue shell (rd.break at the end of the "linux" line), it is time to proceed to that shell. Press Ctrl+x and you'll get to the rescue shell.

Step two: remount /sysroot as read/write, arrest it (yes, you are the sheriff now, it's the shell where you can only be root) and change the password:

You've been dropped in the rescue shell, you see you are root user (the # at the end of the prompt) and now you need to remount the /sysroot as read/write. And here I probably lost you: why /sysroot and why read/write mounting? It's not as if I am mounting a USB or a DVD, right?
The /sysroot is the actual kernel image you need to load, this is the image of the fully functional system you want to later load and work in. It isn't loaded yet, but it is accessible only if you remount it- and once you do that you'll get the chance to introduce changes to the /etc/passwd and /etc/shadow files while having full root powers without ever entering that root password you actually don't know. I deliberately mentioned USB and DVD here, imagine the kernel you need to load with the changed root password is a USB flash drive or a DVD disc you want to play- there has to be some sort of hardware that will read the data on the USB or the DVD and then present the data to you in the Files application or play that movie from the DVD you just inserted. Something roughly similar happens with the /sysroot kernel image- it needs the hardware resources of your system in order to play the movie you want to watch (that is, the fully functional system that you want to work in later).
The mount command with remounting in read/write mode option:
mount -o remount,rw /sysroot
Note the syntax, it is "-o" the letter and not number zero and the comma between "remount" and "rw" with no spaces between.
Congrats, you got the gates of the system wide open for you to ride in as the sheriff! On to making your first arrest now!

The next command you want to issue is to put that newly mounted and available for editing kernel image /sysroot in jail. Why? What's the offense? Convenience.
It is inconvenient to always type the full address of some resources when you need to access them often and those resources live in the same parent directory. Putting their parent directory in chroot jail means changing the point of reference: instead of typing the full path to the resource every time you use it, repeating their parent directory each time, just put the parent directory in jail and that way that parent directory in your view becomes the root directory of the system.
So let's jail the /sysroot:
chroot /sysroot

Notice how the prompt changes, it is shorter now but retains the # symbol at the end, meaning you still the sheriff :-)
Finally time to do what you came to the rescue shell for: change that password! How?
Simply type passwd and notice how you aren't asked for old password, nor for any other form of authentication neither for the name of the user you are changing the password for. You are now root for all intents and purposes, you are in the root shell and you are changing the root password. The only thing you'll be asked to do now is to enter the desired password and repeat it.

Step three: the sheriff vs the secret police. Win this duel by issuing this command

touch /.autorelabel

otherwise the secret police (SELinux) wins. If the secret police wins, your system will still boot but you won't be able to log in: not with your regular user password, not with the new root password nor with any password.
SELinux labels every resource on your Linux system with various labels and uses that same systems to label processes. Once the secret police, lurking in the shadows (hence secret), nabs a process that tries to access a resource to which that process has no business accessing (and that's decided based on those labels), the secret police stops that process, issues an alert on the screen and logs the offender and its offense in the proper logs. The very presence of the hidden file "autorelabel" forces SELinux to appropriately label the resources critical to successful logins so that at the end of the kernel loading process you'll successfully be able to log in as root with your shiny new password. The touch command plays a roll of file creator, it creates an empty file (among other things this command is capable of, although the original intent was to change the timestamps of files).

Step four: exit, exit, exit.

You are done and done here, after
touch /.autorelabel
and paying attention to the syntax before you press ENTER (slash dot autorelabel), keep typing "exit" to first exit from the jail and then from the rescue shell itself so that the kernel loading process continues.
Warning will show up: SELinux needs time to complete the relabeling process, which is a great sign- success is on the horizon. After secret police does its job relabeling every resource, you'll be presented with the normal terminal login, try to log in as root with your shiny new password, confirm it works, and congrats: you've successfully changed the root password.

Some may call this procedure "recovering the root password" instead of "changing the root password", notice how you aren't recovering anything. That old password, once you forget it and did not record it in some external resource, is gone forever. The new password takes effect at the very exit from the rescue shell.

Remotely access your Linux server’s GUI from your local network

gjorgivarelov — Thu, 16 Dec 2021 22:48:19 +0000

In this post, I’ll describe how to enable remote connections to one’s Linux server’s GUI from other clients on the local network (LAN). If you were instead looking for a way to connect from outside your own LAN, it will most likely involve using some paid VPN service but this post should be useful to you even in that scenario, since you’ll need to first enable remote access on the server for everything else to work.

Which distro?
I am using a recently acquired desktop that I turned into an RHEL server, particularly version 8.5. It goes without saying that this is quite possible with any other Linux distribution, the only difference is the package managers used and location of sharing preferences used to enable desktop sharing. In my experience, I found this same process easiest on Ubuntu.

What will you get at the end?
Ability to work on your server’s desktop from another client just like you would be if you were physically present in front of that server. One possible turnoff would be scaling the resulting image you receive from the server: elongated, too tiny, tiny letters and this usually happens due to difference in resolution between the two devices’ graphics.

For starters:
RHEL 8.5 already comes with the Sharing Preferences dialog (found in Settings) a Remote Viewer (of varied usefulness) and without a need to install vnc server(s).

It’s not as easy as many tutorials describe
Official Red Hat guide describes the whole process very casually: open a menu, switch few things to “on” and you’re done. For one, if you have a combination of Wi-Fi and Ethernet adapters on your server, the dialog that makes it all happen will make available only the Wi-Fi connections. This might throw you off if you have all your clients connecting to the server via an Ethernet LAN. And you may think this is why remote desktop connections don’t work. Disregard this and just switch to “on” at the rolling menu of available networks. Remote desktop access will work even if you turn your client’s Wi-Fi off.
And then, it’s the importance of turning encryption off on the server. Again, a casual mention in the official guide: open the terminal and use a gnome edit command to turn encryption off for remote desktops connections. That won’t help. You’ll need dconf-editor installed and then dig through its menus.

Finally, the steps:
In the Settings menu, open Screen Sharing, turn the slider to on, set up some simple password for the connection, in the list of available networks choose whatever network has a slider by its side and turn that slider to on.
Assume the root powers on your terminal and open the port for remote VNC connections: port 5901
firewall-cmd —-add-port=5901/tcp —-permanent firewall-cmd —-reload
Also add your Ethernet NIC that connects your server to your LAN to your current firewall zone:
firewall-cmd —-add-interface=enp5s0 —-permanent firewall-cmd —-reload
Notice how we’re not setting zones to which we’re setting the interface and port as trusted: I’m assuming you already set your server’s firewall zone to “home”- the zone in which all devices on your LAN are trusted.
Lastly, install dconf-editor on the server and then open it, go through org -> desktop->gnome->remote-connections and turn the switch to off.
No need to reset any service nor your server: connections from your clients requesting access to your server’s desktop should work.

Installing RHEL on bare metal in 2021

gjorgivarelov — Mon, 13 Dec 2021 06:43:18 +0000

Enticed by the holiday's tech sales offerings as 2021 nears its end, I recently purchased a Dell Inspiron desktop for the purpose of installing a Linux distro on it- in particular Red Hat Enterprise Linux 8.5. The price was great, I was tired of virtualizing RHEL on my laptop, and despite my previous negative experience with installing Linux on cheap but new hardware, I decided to dive into the task and give this conversion a try. The configuration is more than decent for what I want from that machine and after all, Linux itself isn't exactly a needy customer when it comes to hardware resource. "Well maybe things have improved over the years"- I thought. And yes they did, but not as much as I've expected.

Not as easy as "shrink the Windows partition and then run the installer"
Commodity hardware, like the Inspiron desktop and its equivalents with other PC maker brands, is still under Windows' tight grip. If you want a PC with RHEL or Ubuntu pre-installed on it and shipped to you, you'll have to spend more. It won't be the cheapest laptop or desktop on the store shelf. It is almost guaranteed that cheap but new configuration will ship with Windows on it. I was not able to find an option on Dell's website that'd customize the pre-installed OS on Inspiron. That option was available on their higher-end configurations though, but if one wanted RHEL pre-installed, Dell wanted to charge yearly susbcription right from the start. Even without the subscription, those configurations cost at least 50% more than I spent on my Inspiron and the monitor.
Many a tutorials that I found online give that simple advice for dual booting Linux on a Windows machine: while in Windows, shrink the Windows partition and then run the Linux installer and it'll all be fine. That advice isn't bad if all you need is dual boot Windows-Ubuntu or Windows-Fedora. For any other distro, you are at the mercy of the BIOS maker.

Before you buy, ask "can I disable SecureBoot?"
SecureBoot is a technology that, explained in very simple terms, allows only securely signed OS images to boot on your PC. That looks great in theory. In practice, Windows is the only OS blessed by SecureBoot to run on PCs. The only Linux distros with that blessing are Ubuntu and Fedora.
You'll be out of luck if you bought some new but cheap configuration with SecureBoot on it if you want to install Linux that isn't Ubuntu or Fedora and the option to turn off SecureBoot in BIOS simply doesn't exist. Not all makers will expose that option to you. And good luck asking customer service that question. I honestly haven't asked, and got a PC with an option to turn off SecureBoot by pure luck.
If BIOS allows you to turn off SecureBoot and you went and turned it off, you aren't done with BIOS yet.

AHCI is your friend for painless Linux installation on new hardware
RHEL won't install if the storage on that PC is handled by BIOS in RAID mode. It won't be even seen by the RHEL installer. If there's an option in BIOS to turn the storage handling to AHCI mode, do turn to AHCI. There may be a warning popping up about Windows possibly not booting up after that switch to AHCI. My intention was never to keep Windows on that machine, so I galantly disregarded it. Your case might be different.
All you have to do now while in BIOS is to set up the boot order to prioritize boot from the installation media rather than from the hard drive and _now _you are done with the BIOS.

There are obstacles but people adapted
There's a considerable body of online knowledge on how to deal with obstacles that PC makers put to keep Windows on cheap hardware in the name of security. Years and years worth of testimonials of people buying cheap PCs, converting them from Windows to Linux boxes and reporting back on issues they encountered. So have your still functioning personal computing device firmly by your side- be it another PC, a laptop or your smartphone- read those testimonials and try to learn from those people's experience.

Why not dual boot
It was probably still possible to arrange dual boot Windows-RHEL on my new Inspiron, after I resolved the issues with SecureBoot and RAID. And I honestly gave Windows 11 a chance. I patiently waited, for days, for the updating process to finish. One update after another, the longest actually being the BIOS update. It may have been the internet connection that slowed things down (wireless router in a different building that I don't have access to) but after all was done (actually when I got back a bootable machine, updates were not done) and I started exploring Windows and saw how underwhelming it is- nothing honestly that sets it apart from other OSes, no distinguishing feature that no other OS can do, nothing that compels one to reach out for Windows and say "I want this OS!"- after all these years... that was what Microsoft came up with: a gateway to an MS Office subscription, an obligatory antivirus tithe and Edge as the new browser (and probably the slowest of all). No thanks, and bye. Windows is not for me, I guess.

That was my own experience, yours may differ. You may have even found some better solutions to issues involving conversion of cheap Windows PCs to Linux. I am looking forward for your comments.

A developer tries to explain regular expressions

gjorgivarelov — Thu, 04 Nov 2021 17:57:56 +0000

As a developer, at any given time, you have quite a few projects that need your attention and the deadlines are looming. With pressure on, you'd rather dedicate your time to those projects and possibly add even more on your to-do list than turning your focus on a time-consuming study of an infinitely nuanced craft with opaque explanations.

Some of us learned to shy away from regular expressions, some learned to use them, some even use them with enthusiasm. Hopefully this post will help us all turn into regex enthusiasts. Ideally, it is the aspiring developer that is reading this and before he or she commits to studying regular expressions.

Why do regular expressions need to be explained through metaphors familiar to developers?

Sure, the route of rote memorization of regular expression features (and the subsequent loss of what was learned) may be the easiest approach to learning regular expressions. Memorize what each token stands for, make notes and at time of need, go back to those notes to "refresh" the skill you "learned" (basically, re-learn it).
Instead of going through the typical pace of a regular expressions tutorial, where there's a list of regex features and ensuing explanations of each, let's try to understand regular expressions and as a result of that understanding use them later almost without effort. The goal is to avoid memorization and subsequent loss of what's learned. Imagine you have to look up in your notes the meaning of the question mark in regular expressions- its meaning changes with the context it is used in! How much time would you have saved if you innately knew the meaning of the question mark at that given moment! But if one could put the seemingly opaque craft in a context familiar to a developer, we'll all save ourselves from the resentment of learning and using regex.

Declarative programming metaphors and regular expressions

Going through the list of regular expressions' features, it would seem like its almost all declarative programming. Data is represented through tokens and is filtered according to particular tokens used in that given pattern. You don't have to construct the logical engine that will sift through the data, that's already done for you- in a similar way that HTML tags' meanings are already defined and rules are already set on how the browser will render the tagged data. String anchors, word boundary, character classes, these are obvious equivalents to tags in declarative programming. Not so obvious: quantifiers, the negation operation and groups.

One could even go so far as to construct a rudimentary DOM by naming/numbering groups of tokens. Want to limit how far can you iterate through that given DOM? Sure, that's what the flags are for (global, multiline, case-insensitive and others). Nesting tags? Well that's what the groups are for.

Imperative programming metaphors and regular expressions

Declarative programming metaphors cover a lot of features of regular expressions but if you prefer imperative programming, you aren't left alone as far as regular expressions. Albeit this may be the only feature that is equivalent to an if-then loop, it can be used to great effect when processing text with regular expressions: the lookaround.

Or actually lookarounds. Because you can look in front or you can look behind. Meaning: only look for match in strings that meet the following condition. Looks a lot like an "if-then" loop, doesn't it? I was so happy to learn about and use this feature, the "if-then" loop is a very familiar territory to anyone that has even tried to learn coding. You could instruct your machine to look for matches in front of the condition or behind that given condition. Perhaps you are called to match anything but a given condition? Negative lookarounds to the rescue. Meaning: see if a string doesn't match a given condition, and only if doesn't do you look further for matches.

Another imperative programming metaphor in regular expressions is the direction of execution. And we are all familiar with the top-down direction of execution, as we were taught imperative coding. Regular expressions also have their own direction of execution, and what is that direction becomes most obvious with one of the simplest of matches: a literal character followed by a quantifier. It's what's IN FRONT of the quantifier that decides what will be matched in the text you are rifling through. Imperative programming has the top-down sequence of execution, regular expressions have their "what's in front of the token is what'll match" direction.

I hope this post I wrote eases some of the resentment both aspiring and accomplished developers might have when trying to grasp and successfully use regular expressions during their work. Instead of writing a bonus paragraph on equivalents of logical and bitwise AND, OR and XOR in regular expressions by myself, I will leave such writing to you dear readers, write a comment on that subject in the comment section. Logical OR would be the pipe symbol. But what about AND? Or XOR?

P.S.

I highly recommend taking Bonnie Schulkin's course on regular expressions on Udemy, I must admit that I have been shying away from regex for years as my notes on the subject of regex kept stacking up, until taking her course on this subject, and I learned a lot about regular expressions during that course.