Over 80% is running on some form of Linux – so does your Mac and you iPhone. Sometimes we have to get our hands dirty on the command line – it makes you feel like a proper hacker.
In 2011 I wrote an article about how to avoid emails from Dr. Web. In it I was discussing how to switch off these notifications, which are generated when the Dr. Web service updates itself.
Here’s an example:
/etc/cron.daily/drweb-update:
Dr.Web update details:
Update server: http://update.msk5.drweb.com/plesk/700/unix
Update has begun at Fri May 18 03:53:47 2018
Update has finished at Fri May 18 03:53:54 2018
Following files have been updated:
/var/drweb/bases/drwdaily.vdb
/var/drweb/bases/drwtoday.vdb
/var/drweb/bases/dwmtoday.vdb
/var/drweb/bases/dwntoday.vdb
/var/drweb/bases/dwrtoday.vdb
/var/drweb/bases/timestamp
/var/drweb/updates/timestamp
Sadly, as of 2018, there is still no way to switch these emails off via a tick box from inside Plesk. It was relatively simple though to redirect the output to /dev/null in Linux, thereby avoiding yet another email in our already overflowing inbox.
In the latest version of Plesk, the earlier approach is no longer working.
Instead, we can tweak the Dr. Web configuration file at /etc/drweb/drweb32.ini. In the Updater section, find the following block of code:
# CronSummary = {Boolean}
# Enables output of update session log to stdout.
CronSummary = yes
Now change the CronSummary value to no and restart the Dr. Web service. On CentOS it’s called drwebd:
systemctl restart drwebd
This will ask Dr. Web to not send us an email when he updates himself. The great thing about this solution is that we can still get command line output if we want to run the service manually.
However, if the service is updated in the future, those emails may re-appear because it’s likely that our configuration file may be overwritten. Only time will tell I guess!
The Apache web server has a convenient feature called Name-based Virtual Hosting. This function allows us to have a single LAMP Stack server configured on one IP address, but serve a different set of files depending on which domain is being requested.
This sounds more complicated than it is. Say we had example1.com and example2.com, both of which are to be separate websites, but both domains point to the same IP address. Apache’s Name-based Virtual hosting makes this possible. In fact, this feature forms the basis of 90% of this planet’s shared hosting business.
Let’s see how to do this in CentOS 6 and 7. (More …)
By default, CentOS 7 comes with support for PHP 5.4. Sadly that version has reached the end of its life in 2015and is no longer updated by the developers. If we want to stay up to date with the latest software, we may want to upgrade (if our applications are working with newer versions of PHP).
For CentOS users this either means to compile cutting edge versions from source and tweaking lots of scary system configurations – or dipping into the power of Software Collections. These are official pre-compiled packages by the software vendor, designed to run newer versions of software alongside those that are provided by default.
At the time of writing, PHP 7.2 is available but it’s not part of the software collections yet, so we’ll use PHP 7.1 with FPM support under Apache (as it’s the recommended way to do so).
I had an issue with one of my servers the other day: its power supply died unexpectedly during a scheduled restart. The poor thing never cam back up again.
Lucky for me, the data centre could simply swap out my hard disks and put them into another server. Although my data was save, the server wouldn’t connect to the network anymore – because it had a new MAC address. CentOS stores this value in two of its files, and when it changes (which is hardly ever the case), those files need to be updated.
Here’s how I fixed the problem. I did this on a CentOS 6 server, but it looks like the procedure is the same for CentOS 7. (More …)
Did you know you can run Commodore BASIC v2 on your Mac and Linux systems as a scripting language? It’s true – thanks to the marvellous efforts of Michael Steil and James Abbatiello. They’ve adapted the original BASIC v2 as featured on the VIC-20 and C64 with additional routines so that it works natively on modern machines. It’s ingenious!
For those who don’t quite know what to do with it, here are some instructions that’ll help you get CBM BASIC up and running on macOS.
Download
GitHub provides a convenient way to either clone a repository on your local machine if you have GitHub for Desktop installed, or you can download a ZIP file and unZIP it somewhere on your system. Once done, you should see a directory structure that looks exactly like the repo on GitHub.
Compile
You need a few utilities installed your your Mac to be able to compile files. Downloading Xcode will ptovide you with an excellent (and free) IDE as well as the command line tools needed to do that (gcc, make and several other goodies). You might be able to bring those components in using the Homebrew package manager.
Using your Terminal app, navigate to your unZIPped folder. It includes a MAKEFILE so there’s no need to mess with any parameters. Enter “make” at the command prompt, and after a few moments you should have a file called “cbmbasic” without an extension in the same directory. That’s the binary for your Mac.
To make it executable, we’ll have to tweak the file permissions – otherwise our operating system won’t be able to run it. We’ll do it using the chmod command:
chmod +x ./cbmbasic
You can test if it works by calling the binary without any parameters like this:
./cbmbasic
If all goes well you should see something like this:
For easy access, copy the binary over to your /usr/bin directory. That’s where common command line utilities are installed on Mac and Linux systems. The added benefit is that the path to that folder is already in your local $PATH variable, and as such you can simply type “cbmbasic” from any location when you’re on the command line.
Here’s how to copy the binary over (this will ask for your administrator password):
sudo cp ./cbmbasic /usr/bin
Using Direct Mode
When you run the binary it will bring up something like the standard BASIC command prompt we’re used to seeing on the Commodore 64. There are however a few important differences between a C64 emulator and this implementation:
this is NOT an emulator
cursor keys DO NOT work
all commands typed in must be CAPITALISED
Other than that, you can start typing like on a real machine. Be careful with certain POKE commands though as those may call system routines that might not be implemented.
LOAD and SAVE commands have been tweaked to reference the command line structure. They work just fine, but will load and save files in Commodore file format (which is not clear text ASCII – more on that later). For example:
The above displays the directory of the current folder, much like it was an attached floppy drive. How cool is that? You can reference folders using both LOAD and SAVE just as if you were on the command line.
You can also type in programmes and run them – however the cursor keys won’t work, so there’s no screen editing options. Programmes SAVEd from direct mode cannot be loaded from the command line, only from direct mode (i.e. when launching the binary without parameters).
To quit direct mode, hit CTRL+C.
Running Programmes from the Command Line
The real power of this implementation can be seen when we run files from the command line. Those files must not be SAVEd from direct mode, but instead are simple clear text files. The extension doesn’t matter, but for good practice, let’s store them as .BAS files (much like shell scripts are stored with the.SH extension, or PHP files would be stored with the .PHP extension… you get the idea).
You can write standard BASIC programmes use your favourite text editor (like vi from the command line), or try one from the “test” directory that’s provided with the repository.
Imagine we had a file called “hello.bas” that we’ve created with vi, looking like this:
10 PRINT "Hello World!"
To run our file, we can simply define it behind the binary like this:
cbmbasic hello.bas
This will greet us with the “Hello World” message on the command line.
Running Script Files
Alternatively, we can specify the full path to cbmbasic at the beginning of a file (she-bang notation) and run it just like any other script file. Observe please:
If the file was called “hello”, we’d need to change the permissions again so that the file can be executed:
chmod +x ./hello
Now we can run it like this:
./hello
Hello World
from CBM BASIC :-)
Sweet – but I can’t work out how to compile this on macOS…
Fear not – I’ve got a macOS binary that was compiled on 10.12 “Sierra”. You can find it in my fork of the project. Check out the “binaries” folder.
Does it work on Windows? Or on Linux?
I’ve tested compiling and running this puppy on CentOS 6 and 7 with roaring success. The above steps worked fine for it, so I’m assuming it’ll work on other Linux flavours just as well (the beauty of portable C code).
According to the author, it works fine on Windows too – however I have no idea how to compile source code on Windows, so you’ll have to figure that out for yourself. I hear good things about Visual Studio – if I work out how to do it, I’ll add it to the “binaries” folder on my GitHub Fork.
Can I write my own extensions to BASIC?
Apparently so – check our Michael’s site and repo for details:
Right now, if you run SYS 1 from direct mode first, you can use the SYSTEM command (followed by anything you’d like to execute on the command line in “double quotes”) as well as LOCATE (followed by an x and y coordinate to place the text cursor) and WAIT.
Have fun hacking BASIC and letting it run with the blistering speed of modern CPUs 🙂
In the GNOME desktop, there is no obvious way to tell which version you’re running by way of the GUI. Instead, we need to consult the command line and try out a couple of commands to find out more. Here’s how.
Let’s open a Terminal session and do some hacking.
GNOME 2.x
If you’re running GNOME 2.x (under CentOS 6 for example), you need to run the following command:
gnome-session --version
gnome-session 2.28.0
You may need to prefix this command with sudo, otherwise it will tell you that you’re alrady running a GNOME session.
Should the above not work, you’re likely on GNOME 3 (see next).
GNOME 3.x
GNOME 3 uses a different command, namely this one:
gnome-panel --version
gnome-panel 3.24.2
If you don’t know which version of the GNOME panel you’re using (which is likely), try both commands. One of them will work, the other one won’t.
Bulk renaming files can be done with the rename command. It shares many similarities with cp and mv, but its simplicity can be so staggering that its difficult to figure out how to use it.
If we just type “rename” at the command prompt, all we get is the message
rename
call: rename from to files...
While technically correct, what on earth does it mean? How do we use rename?
Let’s do a little exercise. Imagine we had a batch of files, perhaps something like “Title 101.mp4” to “Title 110.mp4”. Let’s create some empty files with those names in a test directory:
mkdir test
cd ./test
touch 'Title '{101..110}.mp4
ls
So far so good. Now we’d like to rename those files so they read “New Title 101.mp4” to “New Title 110.mp4”. Here’s how it works:
rename 'Title' 'New Title' *.mp4
Technically, this follows what the command showed us earlier: “rename from to files…”. Still I feel a little explanation is in order.
For the rename command to work, we don’t need to specify the full file name, nor that we want to rename a batch of files. The command will rename anything that it encounters. All it needs to know is which string to replace with which other string. Those are the first two parameters we give it, in our case wrapped in single quotes because we have a space character in our titles.
The third parameter tells rename where the files live that we want to rename. In our example it was here in the current directory, but it could be anywhere on the system. By specifying *.mp4, only files with that ending will be renamed, all other files will be left in peace.
I hope this helps to understand rename a little better.
Although many alternatives exist, I like using vi for all my command line editing needs. To save changes, I usually use SHIFT + Z + Z, exiting vi under most circumstances.
But sometimes, this trick doesn’t work because of write permission problems. In such cases, vi doesn’t close with the above command. Instead, we must either stash our changes in another file, or quit the session without saving. Here’s how to do that.
Quit vi without saving: :q!
Save current file under a different name: :w newfile
Shell Scripts (BASH Scripts) can access command line parameters using the the variables $1, $2, $2 and so forth, up to $9. In fact, more parameters can be accessed by using curly brackets, like ${10}, ${187} and so forth.
Here’s an example:
#!/bin/bash
if [[ $1 == "x" ]]; then
echo "Statement is true"
else
echo "Statement is false"
fi
If we run the script with like this
script.sh x
it will tell us the statement is true. Otherwise, it’ll tell us the opposite.
Note the whitespace around the evaluation: [[ ]] is actually a command (much like the == operator) and therefore needs to be surrounded with whitespace.
We can access parameters passed via the command line in our PHP shell scripts. Those are stored as an array in the variable $argv. Consider this:
#!/usr/bin/php
The first part of the script prints out all parameters that have been given, while the second part checks if the parameter was "x" or not. Note that the first item in the array ($argv[0]) will be the the first item on the command line, i.e. the file name and path to this very script. $argv[1] is the first parameter, $argv[2] the second, and so forth.
In 2011 I wrote an article about how to avoid emails from Dr. Web. In it I was discussing how to switch off these notifications, which are generated when the Dr. Web service updates itself.
The Apache web server has a convenient feature called Name-based Virtual Hosting. This function allows us to have a single LAMP Stack server configured on one IP address, but serve a different set of files depending on which domain is being requested.
By default, CentOS 7 comes with support for PHP 5.4. Sadly that version has reached the 
I had an issue with one of my servers the other day: its power supply died unexpectedly during a scheduled restart. The poor thing never cam back up again.
Add your voice!