grep has tons of great options, like

-F = fgrep; no regex – way faster
-v = as mentioned in the article
-o = print only matched input, not the entire line
-C = context, print lines before and after the match; can also be used partially with -A (after) and -B (before)

Recursively grep a directory

grep -r "texthere" .

#grep

Sometimes you don’t have a…

Sometimes you don’t have a debugger handy, but you have a function acting weird and you want to know where it’s being called. You can find out using the backtrace, like this –

echo debug_backtrace()[1]['function'];

And send that to /tmp/php-errors by using error_log.

error_log( "called by: " . debug_backtrace()[1]['function'] );

Tail error logs in VIP…

Tail error logs in VIP Go containers like this –

[/chroot/var/www $tail -F /chroot/tmp/php-errors -F /tmp/php-errors

I like using the command…

I like using the command line whenever I can. I had a GUI for editing my hosts file for development work. but I really disliked it. Way too clunky. I found a ruby script that does the job more easily. It’s at https://github.com/markjaquith/Localdev and you can install it on your Mac with sudo gem install localdev

The command is “localdev”, but even that is too much typing for me. I aliased it to ld, and the “add” command to ldadd, but the script defaults to using localhost as the ip address. To make my sandbox ip the default, I needed to add it to the alias, and also get an argument in between “add” and the ip. bash_profile allows functions for that kind of thing.

alias ld="localdev"
ldadd() { localdev add "$1" 192.0.95.13; }

The command needs sudo access which you can get around by adding this line to the sudoers file:

$sudo visudo -f /etc/sudoers
shannon ALL = NOPASSWD: /usr/bin/localdev

Restart the session to make sure it takes.

It’s annoying to type in…

It’s annoying to type in your svn password every time you want to svn up.

Try running SVNAUTHCACHE=1 svn up -N ~/public_html on the sandbox. Thanks Paul Kevan for the tip.

I made an Alfred workflow…

It’s documented elsewhere that HSTS can make sandboxes act weird sometimes. You get the https “unsafe site!” warning error, except in this case, you can’t click the “I know what I’m doing” button to get past it. Here’s the field guide page about it.

In Firefox there’s a way around it using the Dev edition. In Chrome you can visit chrome://net-internals/#hsts and delete the domain in question from the HSTS set, but that’s kind of annoying.

I made an Alfred workflow for flushing the HSTS cache with a keyword instead. Triggers on “fl {query}”.

On GitHub

on alfred_script(q)

    tell application "Google Chrome"
        open location "chrome://net-internals/#hsts"
    end tell
    delay 1
    
	tell application "Google Chrome"
        execute front window's active tab javascript         
        "document.getElementById('hsts-view-delete-input').value='" & q & "';"
delay 1
        "document.getElementById('hsts-view-delete-submit').click(); "
delay 1
        delete tab (active tab index of front window) of front window
    end tell

	tell application "Google Chrome"
        open location "http://" & q
    end tell
end alfred_script

I thought there was something…

I thought there was something wrong with WP CLI tools because all of a sudden I was getting no output at all.

Last login: Tue May 30 09:24:45 2017 from 5.33.114.37
wpdev@wordpress.com:~$ wp
wpdev@wordpress.com:~$ wp --info
PHP binary:    /root/roles/nginx-php/usr/local/php7.0/bin.jessie/php
PHP version:    7.0.19
php.ini used:    /usr/local/php7.0/conf/php.ini
WP-CLI root dir:    /home/wpcom/public_html/bin/wp-cli
WP-CLI global config:    /home/wpcom/public_html/bin/wp-cli-wpcom/wp-cli.yml
WP-CLI project config:    
WP-CLI version:    0.13-alpha3
wpdev@wordpress.com:~$ wp shell --url=viptest.wordpress.com
wpdev@wordpress.com:~$ wp user list --url=viptest.wordpress.com
wpdev@wordpress.com:~$ 
wpdev@wordpress.com:~$ cd public_html/
wpdev@wordpress.com:~/public_html$ wp user list --url=viptest.wordpress.com
wpdev@wordpress.com:~/public_html$ 

There’s an error log you can view for debugging. I knew it existed but I forgot where. Thanks @kulash, it’s at /tmp/php-errors.

tail -f /tmp/php-error

VIP Go errors are at /chroot/tmp/php-errors.