Different versions of shell commands like PHP, Vi – find the true location of Mac/Unix commands, aliases and links

Sometimes it can be a challenge to uncover what terminal command is actually being run on Mac / Unix / Linux systems. Over time, old aliases, links and the repeated installation, upgrading and removal of software can lead to existing and even untouched default commands either unable to be found or running a different version than expected.

Recently we have been using Homebrew to swap in and out multiple versions of PHP (5.4, 5.6, 7.1 etc.) on Macs. Whilst great for quickly testing and developing across versions, this makes it possible to have strange occurrences, like the $ which [command] returning a different version of the software to the one which the shell actually executes!

The following location mismatch demonstrates the problem:

# Problem: Command or Software (in this case php)
# Reported as missing or runs at different location


$ php -v
-bash: /usr/local/bin/php: No such file or directory


$ which php
/usr/bin/php


# WTF ???

Different locations are being referenced by $ which [command]  and the shell.

To fix the discrepancy, use the $ hash [command] to refresh the shell’s command location cache:

# Result before hash command
$ command -v
php /usr/local/bin/php

$ hash php
$

# Result after command
$ command -v php
/usr/bin/php

# Same version recognized everywhere
$ which php
/usr/bin/php

$ php -v
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

Great, order has returned to the universe and which is again pointing at the correct place. Keep in mind if you do replace (or re-link) the php at /usr/local/bin/php it will be executed instead of the /usr/bin/php, but now all commands should agree on the file’s location.

Debugging Aliases

The above situation can be particularly tricky when dealing with aliases.

If we define an alias and confirm it can be executed, the $ which [alias] and ls commands bizarrely return nothing! Where is the alias going? To find where and what the alias is actually running, utilise the $ type -a [command] command:

# Create alias and watch the confusing behavior
$ alias phpv='php -v'
phpv
PHP 5.5.36 (cli) (built: May 29 2016 01:07:06)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies


$ which phpv
$


$ ls -l phpv
ls: phpv: No such file or directory


# The type command reveals all (-a)
$ type -a phpv
phpv is aliased to `php -v'

Debugging Links

Links act slightly different again. As discovered in this blog post, vi links to vim on a mac, however the which, type -a and command -v commands only shows the link name, not the target:

# These commands give information on links (ls -l is most useful)

$ which vi
/usr/bin/vi

$ type -a vi
vi is /usr/bin/vi

$ command -v vi
/usr/bin/vi

$ ls -l /usr/bin/vi
lrwxr-xr-x 1 root wheel 3 21 Aug 15:29 /usr/bin/vi -> vim

Here we can see that although ls -l was useless for aliases and commands, it is good for showing where links point to.

Although only a summary, these quick commands give a few pointers for when a command either cannot be found or a different version than expected is executing. If you’re still struggling to locate an executed command or know of other handy tips, please leave a comment.

Please share if you find our free website useful, it really helps us produce more tutorials!

Advertisements

Make mysql databases default to UTF8

By default MySQL databases are created with one of the latin charsets – as if globalization never happened – and just asking for future internationalization and charset issues. UTF8 is the generally accepted way forward (for now) and there are few occasions that it isn’t the best charset to use.

Ideally, some sort of framework config system will take care of this but otherwise for existing MySQL databases, you can find out their current charset by entering the MySQL terminal and typing:

SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name = "myDatabase";

The problem is changing the character set of an in-use databases can be troublesome and you have to remember to specify UTF8 as the charset every time you create a new database. Also many database tools (e.g. PHP’s Doctrine) do not currently support creating a database with a non-default charset.

The best solution is to set the default charset to UTF8 straight after installing mysql and avoid the problems before the occur. This can be done simply by modifying /etc/mysql/my.cnf (note my.conf may be located elsewhere) and adding the following lines to the [mysqld] section:

collation-server = utf8_general_ci
character-set-server = utf8

Then restart the MySQL service:

sudo service mysql restart

Now new databases will now be created using the UTF8 character by default.

Saving a root owned file in vim when not opened using sudo

A very common Linux administration annoyance can be opening a file in vim, making loads of changes, going to save and quit the file (using :wq) only to receive the message:
E45: 'readonly' option is set (add ! to override)
But as only root can write to the file, this won’t work either. Before pulling hair out, try this handy little command:

:wq !sudo tee %

Apt-get not finding packages

On a freshly installed Ubuntu system, apt-get may not have bothered to download its list of packages. This can lead to the confusing position of ‘E: Unable to locate package X‘ on almost everything. Fix this by entering:

sudo apt-get clean
sudo apt-get update

Packages should then be visible and installable via the usual command:

sudo apt-get install X

If you’re not sure on the package name, search for it using:

apt-cache search X

If you still cannot find the software you’re after you may of course need to add additional repositories.

Quickly get memcached working in Python Django

As with most frameworks, the Django framework for Python can make use of caching to greatly improve performance for many common requests. Here we will look at using memcached as it enjoys good Django support and production use although there is also Redis support which definitely improves on memcached in some aspects such as data persistence.

  1. The first step is to install memcached on your server:
  2. RedHat Linux:

    yum install memcached

    Ubuntu / Debian Linux:

    apt-get install memcached
  3. Let Django know how to access memcached:
  4. In Django’s settings.py file, add the following line:

    'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache'
  5. Load the cache within your application
  6. from django.core.cache import cache
  7. Save the value to the cache
  8. cache.set('exampleValue',exampleValue)
  9. Retrieve the value from the cache
  10. exampleValue = cache.get('exampleValue')

The beauty being that exampleValue can be anything from a computed / database retrieved value to large blocks of static text or a URL etc.

The only problem with caches is they don’t always contain the data you expect, what if the value got flushed or hasn’t yet been stored? Lets rewrite step 5 to handle the event of the value not being available in the cache:

exampleValue = cache.get('exampleValue')
if not exampleValue:
     exampleValue = exampleValueLookup
     cache.set('exampleValue',exampleValue)

Here we see the value exampleValue being retrieved with a backup regeneration if the value has not been set. In a real application this would usually be encapsulated in a getExampleValue function or somewhere appropriate.

libssh2 vs phpseclib

As tempting as it can be to make use of the simple include library which is phpseclib, it is better (if possible) to install the libssh2 module. Libssh2 it grants PHP access to your system’s OpenSSL implementation rather than relying on phpseclib’s own version which is reason alone to use libssh2 despite phpseclib being undeniably more portable, faster and offering enhanced debug facilities (there’s nothing to stop you switching to phpseclib purely to debug pesky issues or writing code first in phpseclib then porting to libssh2).

Whilst OpenSSL has come under attack recently with exploits such as Heartbleed, it remains one of the best tested and trusted security suites around. Major exploit discoveries like Heartbleed and Shellshock (with its openSSH attack vector) demonstrate the need for systems to be patched as soon as possible.

By using libssh2, any patch to the system’s OpenSSL implementation will be automatically applied to your PHP applications. On a related note, unattended-upgrades / yum-cron should always be enabled to ensure you are patched against exploits as they are released with a seemingly increasing regularity.

On a Ubuntu / Debian libssh2 can be installed via the command:

sudo apt-get install libssh2-php

On Red Hat based systems, use:

yum install libssh2

You then need to add the module to your php.ini file with the following line (place it after all the other extension loading calls):

extension=ssh2.so

Then finally restart apache.