Here’s how to use simple variables in BASH shell scripts. It appears there are no data types, and everything’s a string (correct me if I’m wrong). We can define a variable by first setting it to a value, then later refer to that value with a dollar sign in front of the variable name.
Here’s an example:
Note that there are no spaces between the variable name, the equal sign or the value. Adding those will result in a runtime error.
Variables can be defined in upper or lower case letters, or a combination thereof.
BASH Variables have a global scope, unless they are prefaced with the local keyword inside functions (in which case, only said function will have access to its value).
I have recently installed PHP 7 from source on a fresh minimal CentOS 7 box. No previous version of PHP was installed, and I thought I’d give 7 a spin. There were a few pitfalls I hadn’t come across before, so here’s what worked for me.
Downloading and extracting the source code
It sounds crazy, but this was the hardest part of the whole installation! There were two problems I’ve encountered here.
The first was that PHP offer downloads via a mirror. A direct link may look something like this: http://php.net/get/php-7.0.12.tar.bz2/from/this/mirror. This means that if we were to download this file using wget, it would be saved as “mirror”. Now what we want.
So instead we can ask wget to give the download a different name using the -O parameter, like so:
This will save our file as php7.tar.bz2 instead. So far so good. Unpacking this file seems to be impossible. From what the internet tells me, this should be the correct way of extracting a tar.bz2 file:
But that didn’t work, not matter how hard I tried. All I ever got was a “non-recoverable” error. Which sucks. In the end I extracted the file on my Mac, created a ZIP archive and downloaded that instead. Unnecessarily cumbersome and idiotic, but worked. Finally I had them on my CentOS box.
Building the source code
Jumping into the extracted directory, the configure command can prepare the build. At this stage I encountered an error:
configure: error: xml2-config not found. Please check your libxml2 installation.
This can be fixed by installing the libxml2-devel package (NOT libxml2 as the error would have you believe). Let’s do that and run configure again:
yum install libxml2-devel
Now we can run make, followed by make test to see if the installation is going to go well. This will take a few minutes.
Feel free to skip “make test” if you’re in a hurry. In my case, after over 10.000 tests, PHP told me this:
Youmay have foundaproblem inPHP.
Thisreport can be automatically sent to the PHPQAteam at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
Thisgives usabetter understanding of PHP's behavior.
If you don'twant to send the report immediately you can choose
option"s"to save it.Youcan then email it to email@example.com later.
Perplexed yet unfazed, I continued on and installed PHP anyway:
And only moments later, PHP 7 was running on my CentOS system.
I was working on a CentOS 7 server the other day that had a LAMP stack installed. It was used to host only a single instance of WordPress.
Upgrading themes and plugins from the admin interface worked fine, but curiously, WordPress core upgrades did not. Instead, WordPress was asking for FTP details every time, which also prevented auto upgrades from being installed.
This didn’t make any sense because there was no FTP server installed on the box, nor had there ever been one. But it did indicate that WordPress had an issue with overwriting core files.
The first thing I checked was that the /var/www/html directory had the correct file and ownership permissions. It all looked correct, even though I did manually set them again just to make sure. Without success. WordPress was still asking for FTP credentials.
After some research, I found that there is a setting for how WordPress accesses the filesystem when it’s upgrade time. We can define it with a constant called FS_METHOD in wp-config.php. The ins and outs are explained in the codex, under Upgrade Constants:
FS_METHOD forces the filesystem method. It should only be “direct”, “ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change this if you are experiencing update problems. If you change it and it doesn’t help, change it back/remove it. Under most circumstances, setting it to ‘ftpsockets’ will work if the automatically chosen method does not. Note that your selection here has serious security implications. If you are not familiar with them, you should seek help before making a change.
(Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP. It is the option chosen by default.
(Secondary Preference) “ssh2” is to force the usage of the SSH PHP Extension if installed
(3rd Preference) “ftpext” is to force the usage of the FTP PHP Extension for FTP Access, and finally
(4th Preference) “ftpsockets” utilises the PHP Sockets Class for FTP Access.
So on this particular server, for whatever reason, WordPress did not choose the first method (direct), even though it should have. Defining this constant manually did the trick, all I had to do was add this line to my wp-config.php file:
// explicitly use direct mode and stop asking for FTP details
Now updates are working as expected. I’ve never seen this problem on LAMP stacks before. Guess you learn something new every day.
I’ve recently come across a tarsal files that used xz compression (namely the Python source code).
This means that my usual way of extracting a tarsal via the command line using the following command did not work:
gzip: stdin: notingzip format
tar: Childreturned status1
tar: Erroris notrecoverable: exitingnow
That had me stumped! Turns out that files with a tar.gz ending can be extracted this way (because the use gzip compression, specified by the z parameter). If tar is instructed to use this format on a tar.xz file, it fails.
The solution: specify the xz compression, using the capital letter J, like this:
[massive list of files goes here]
Another Linux mystery solved – thanks to Justin Solver for this tip!
I’ve recently bought a new Logitech K360 keyboard for my HP Z600 workstation. I also had a Logitech M325 mouse, both of which came with Unifying USB receivers. I could plug both receivers in, and both devices would work great.
However, I heard good things about these little receivers and wanted to free up a USB port, and thought I’d connect both devices to the same receiver. Apparently you can connect up to 6 devices to one receiver and store any spare ones inside the mouse or keyboard. Being an all-efficient belt-and-braces kinda guy, I tried my luck.
Turns out it was relatively easy to pair both devices to the same receiver, thanks to a small piece of software that can be found here, along with instructions on how to use it:
It all worked fine on my Windows 10 machine, until I wanted to use the mouse (not the keyboard) with my Mac. I know, it’s exotic, and perhaps I should have just bought another mouse. But there’s only so much space on my desk, and I really don’t need more clutter in front of me for just an occasional switch.
In this episode I’ll show you how to launch a Mac App from the Command Line, so that we can pass parameters. I’ll also explain how to wrap up such a command into your own app and add an icon to it, so that you can launch it from the dock with a single click.
This can be useful if you need to convince Google Chrome or any other app to launch with certain parameters and modify its behaviour somehow. In my example I’m using Blender, and I’m using a startup parameter to change its default render engine upon launch. The same principles apply to any app you need to launch with startup parameters.
The process is as follows:
find out the full path of the app you want to launch
try launching your app from the command line
now add parameters to the end of the launch command
create an Automator App
change its icon from from the generic Otto Icon to your desired app’s icon
In CentOS 7 we can use the systemctl command to select which mode the OS boots into. If you have a GUI like Gnome or KDE installed, it’s easy to boot directly into your preferred environment.
To find out what mode CentOS is currently using, use this:
This will give you one of two “targets”, either
multi-user.target (the command line), or
graphical.target (the Windows-like GUI)
To change from one to the other, use one of these commands:
What happened to runlevels?
In previous versions of CentOS, switching boot modes was achieved through runlevels. Those were saved in /etc/inittab, but this file is no longer used by CentOS 7 and above. However, the file still exists and contains a little extra info this matter, including how to change boot modes: