wordpress架构升级

PHP7发布已经有一年了，但是我的博客依然还跑在apache + php-5.3上呢，当时我的yum源里面之后这个，图省事儿，就这么用了； 后视图将架构改为 nginx+php-fpm(php7)，查看wordpress（下文称wp）源码，发现wp只支持mysql，不支持pdo_mysql，但是mysql模块已经被废弃了，就放弃了。

php7的是拿wp做过性能测试的，所以，wp肯定支持php7，所以肯定有解决办法

wordpress 升级指南

曾经我的博客在墙外的时候，升级博客非常简单，就是点击升级就行；后来，把博客迁到了墙内，然后看到博客升级提示，点击升级总是失败，未知所以然。

后怀疑下载不到升级包所致，参考官方文档，下载安装包，手动升级，虽然也搞定了，但是颇为麻烦，后每每看到升级提示，就懒得升级。

今，终于忍无可忍，思得一计：如果给wordpress配个代理，或许升级就方便多了；

对我来讲，研究代理久已，做个代理还是分分钟的事儿的，于是乎，说干就干，通过 shadowsocks + privoxy  做了一个代理，然后通过环境变量 HTTP_PROXY 和 HTTPS_PROXY 告知wordpress走代理，然后就可以一键升级了，欧耶

od 输出字符对照表

 

ctags 学习

ctag识别关键字的时候，一般不会把中划线（-）作为单词的一部分；对于bash脚本，函数名中是可以含有中划线的，这时候使用ctag就不能把含有中划线的关键字识别出来。

其实，ctag是可以定义语言，定义识别的正则表达式的，可以定义在 ~/.ctags 中，如下定义一个bash语言：

这样，再执行ctags -R . 的时候就可以识别含有中划线的函数了，如下：

 

ctags默认根据文件后缀猜错适用的语言的，如果文件没有后缀，可以强制指定适用的语言：

也可以通过 –languages 来指定只扫描指定的哪些语言

bash vs sh

一般来讲，/bin/sh 都是软连接到bash的，所以，你基本上会认为 /bin/sh 和 /bin/bash 是一样的； 但事实是：不尽然

bash中有判断当前文件名的逻辑，如果是sh 就 xxx， 如果是bash 就 ***，如：

使用bash执行脚本时，函数名允许含有中划线（如： hello-world），sh执行时不允许； 注意，使用中划线定义的函数，如果要unset时，则需要使用-f选项，如： unset -f “hello-world” ； 因为如果没有-f选项，unset会尝试unset对应的变量，但是这是个不合法的变量，所以，直接退出， -f选项直接unset对应的函数

使用bash执行脚本时，支持Process Substitution , sh 执行时不支持

 

是不是感觉有些不爽？

还有呢，有些版本的 /bin/test 和 /bin/[ 就是同一个程序，根据文件名的不同执行不同的逻辑

 

参考： https://stackoverflow.com/questions/5725296/difference-between-sh-and-bash

当通过sh的方式使用bash时，基本等同于：

虽然显得很posix，但是很多好用的东西不支持：(其中删除线部分，似乎说的不太对，也或者是我理解的不对，所以删除了)

This question has frequently been nominated as a canonical for people who try to use sh and are surprised that it’s not behaving the same as bash. Here’s a quick rundown of common misunderstandings and pitfalls.

  • If you run your script with sh scriptname, or run it with scriptname and have #!/bin/shin the shebang line, you should expect POSIX sh behavior.
  • If you run your script with bash scriptname, or run it with scriptname and have #!/bin/bash (or the local equivalent) in the shebang line, you should expect Bash behavior.

Having a correct shebang and running the script by typing just the script name (possibly with a relative or full path) is generally the preferred solution. In addition to a correct shebang, this requires the script file to have execute permission (chmod a+x scriptname).

The Bash Reference manual has a section which attempts to enumerate the differences but some common sources of confusion include

  • [[ is not available in sh (only [ which is more clunky and limited). 
  • sh does not have arrays.
  • Bash has process substitution with <(cmd) and >(cmd).
  • Some Bash keywords like local, function, and select are not portable to sh.
  • ~ refers to $HOME only in Bash (and more generally ~username to the home directory of username).
  • Bash has many C-style syntax extensions like $'string\nwith\tC\aescapes' and the three-argument for((i=0;i<=3;i++)) loop, += increment assignment, etc.
  • Bash has *.{png,jpg} and {0..9} brace expansion.
  • Bash supports coprocesses with <> redirection.
  • Bash supports <<<'here strings'.
  • Bash has significantly extended facilities for shell arithmetic (though still no floating-point support) and variable substring manipulation.
  • Many, many Bash-only extensions to enable or disable optional behavior and expose internal state of the shell.

Remember, this is an abridged listing. Refer to the reference manual for the full scoop, and http://mywiki.wooledge.org/Bashism for many good workarounds; and/or try http://shellcheck.net/ which warns for many Bash-only features.

Unfortunately, Bash will not warn when you try to use these constructs when it is invoked as sh.

 

总结：

知道bash和sh有差异就行了，记住所有的差异没有意义