Quick way to check for php syntax errors via CLI
Need a quick way to run through all php files in a directory (recursively) and see which ones have syntax errors? Here you are my friend:
find . -name "*.php" -type f -print | xargs -I file php -l file | grep -v "No syntax errors detected"
Another way to do this (which if you’re as familiar with find as I am — ie: not very) you could do this as well:
find . -name "*.php" -type f -exec php -l {} \; | grep -v "No syntax errors detected"
Set Default Username and Password for your MySQL DB
Tired of always having to enter your username and password to do anything on your mysql database? I would only suggest using this on your local dev box for security purposes, but admittedly, it’s a nice timesaver =]
Warning: this assumes you can vim. If you’d prefer, you can replace any instance of “vim” with “nano”
From the *nix CLI:
vim ~/.my.cnf
If it’s blank, feel free to insert the following (with your user credentials of course!):
[client]
user = 'user_name'
password = 'secure_password-moreso_than_that_pls...well...this_is_ok'
Save that puppy and now from your *nix CLI you shouldn’t have to worry about those precious few keystrokes when interacting with mysql anymore… on second thought, if your password looks like that above, use this. It’ll save you buckets of time =\
Quick way to remove all tables in MySQL DB through *nix CLI
Tablenator!
Here’s a quick time saver (if you dev like me, it’ll come in handy!) for when you just want to drop all of the tables in a database. Of course, test it first so you know what you’ll be dropping!
Test First:
for I in mysql database_name -u user_name -p -e 'show tables' | awk '{ print $1}' | grep -v '^Tables' ; do echo "Table: $I" ; done
Code:
for I in `mysql database_name -u user_name -p -e 'show tables' | awk '{ print $1}' | grep -v '^Tables'` ; do mysql -u user_name -p -e "drop table $I" ; done
Rundown
The basic formula is a BASH for loop that grabs all of the tables in the desired database, filters the output using a combination of AWK and GREP so we can use just a simple list, then drops each table separately.
USE THIS CODE AT YOUR OWN RISK! BACKUP YOUR DATABASE FIRST AND HAVE A RECOVERY PLAN IN PLACE! (trust a man known to fat finger things)
Make a Public SSH Key from your Private Key
Once you’ve found the private key you want to make a public key for (typically in ~/.ssh/ ), here’s the quick and easy command (in this example, we’re making a .pub for our id_rsa key):
ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
Exporting a MySQL Database
For a MySQL database export:
mysqldump -u username -p database_name > /tmp/dump.sql
^^ from the *nix command line
For a particular table in a database
mysqldump -u username -p database_name table_name > /tmp/dump.sql
^^ also from the *nix command line
You will then be prompted for the password for the specified user, shortly thereafter, you’ll have your db export (or as some folks like to call it, a “db dump” — gah! Hate that name… gross!)
Tired of always typing in your username/password when using mysql via the CLI? Check out how to set up a .my.cnf!
Import MySQL DB via CLI
mysql -u account_name -p db_name < /path/to/import/file/mysql.sql
^^ from the *nix command line
Sometimes you need to specify the host (typically it's either 127.0.0.1 or localhost) like this:
mysql -u account_name -p -h localhost db_name < /path/to/import/file/mysql.sql
^^ from the *nix command line
Now enter the specified account's mysql password and you're on your way!
In the instance you're having issues with your import, another way to import (will require access and proper privs), sometimes you just want it to run and not worry about errors (for instance when an insert or two in a dump are greater than the buffer). The handy function to just "make it work" (ie: NOT FOR PRODUCTION USE!!!) is source
in the mysql cli -- check it out:
mysql> source /path/to/db/export.sql;
^^ from the mysql command line
That'll treat the file as a list of commands and run each one individually. If a few of them don't work, it keeps moving on and finishes everything it can... now that's BLAMO
SQL Adding a Column to an Existing Table
Since I can never remember the syntax to add a column to a table, here it is:
alter table foo_tablename add column foo_column int(10) default null
alter table
– the actual commandfoo_tablename
– the table name we’re alteringadd column
– telling sql to add a column instead of some other alterationfoo_column
– name of the column to addint(10) default null
– the column’s qualities (it’s an int up to 10 digits long, can be null and defaults to null
Tada!!!
Prankin’
People leave their macs unlocked. When they do, punish them in the most humane way possible =D
Setting Crontabs
Here are some of my favorites (setting a crontab is as easy as `crontab -e`
):
Have their computer open their gmail inbox every 30 minutes. It’ll feel pretty random at first:
*/30 * * * * ( /usr/bin/open "https://mail.google.com/mail/?tab=wm#inbox" )
Or… every ten minutes, have their speakers verbalize something childish (yet HILARIOUS):
*/10 * * * * ( /usr/bin/say "Peepee" )
Scheduling jobs using at
at
is a great little program. If you have a little time to work, feel free to create a bash script to do your bidding, then queue it as a job using at
=]
Performance Issue Gut Check for MySQL
Sometimes MySQL performance can be difficult to hammer out. One of the quickest ways to get a good gut check is to have a look at the current process list. Check this out:
mysql> show processlist; +-------+------+-----------+------------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +-------+------+-----------+------------+---------+------+----------+------------------+ | 14302 | abcd | localhost | rohjay_one | Sleep | 3696 | | NULL | | 14958 | abcd | localhost | NULL | Query | 0 | starting | show processlist | +-------+------+-----------+------------+---------+------+----------+------------------+ 2 rows in set (0.00 sec) mysql>
Now, this is relatively uninteresting, but sometimes, you’ll find a list of active queries that have stacked up against your db. Some things that can really help you identify issues is by ensuring each different piece of your platform identifies itself uniquely.
Once that happens, you can see which queries from where are hanging on. Parts of your platform can stall and hold onto connections, queries can take an eternity, bad code can hold result sets in memory, etc… This should give you a good idea where to start looking!
Hope this helps =]