2026年6月个人工作生活总结
本文为 2026年6月工作生活总结。
研发编码
360浏览器修改主页
360浏览器默认情况启动其主页，不太喜欢。遂改之。方法：
右上角菜单(像“三”的字样) - 设置 - 基本设置 - 启动时打开- 修改主页，按需要输入：
显示空白页： about:blank 显示新标签： chrome://newtab笔者习惯第二项。
linux 不同shell的兼容问题记录
某shell脚本，从文件中读取一行字符串，截取某一特定位置，然后判断，进行相关处理，但无法进入处理分支。简化后代码片段：
FOO_INFO为文件某一行字符串 FOO_TYPE=`echo $FOO_INFO | awk '{print $3}'` echo "看到的类型" $FOO_TYPE echo "字符串里的值------[$FOO_TYPE]" echo "----------------------------" if [ "$FOO_TYPE" = "3" ]; then echo "FOO_TYPE 等于 3" # 业务逻辑 else echo "FOO_TYPE 不等于 3，当前值: ($FOO_TYPE)" fi经测试，是不同系统的shell导致的。参考脚本所在系统为centos，使用#!/bin/bash，移植脚本目标系统为某国产桌面操作系统，使用#!/bin/bash。似乎是一样的，但实际不同。判断失败的原因是，FOO_TYPE多了\r\n符号，这是不可见的，但的确存在，因此实际变量的值并不是看到的3。解决方法很简单，在读取后去掉不可见的字符即可。但排查起来花费了好半天时间，一是固有认知影响了判断，二是设备调试起来有些麻烦。
修改前的日志：
看到的类型 3 ] 符串里的值------[3 ---------------------------- )OTYPE 不等于 3，当前值: (3修改后代码：
FOO_INFO为文件某一行字符串 FOO_TYPE=`echo $FOO_INFO | awk '{print $3}'` echo "看到的类型" $FOO_TYPE echo "字符串里的值------[$FOO_TYPE]" # !!!! 此处修改了 FOO_TYPE=$(printf "%s" "$FOO_TYPE" | tr -d '\r\n') echo "处理后的值------($FOO_TYPE)" echo "----------------------------" if [ "$FOO_TYPE" = "3" ]; then echo "FOO_TYPE 等于 3" # 业务逻辑 else echo "FOO_TYPE 不等于 3，当前值: ($FOO_TYPE)" fi修改后的日志：
看到的类型 3 ] 符串里的值------[3 处理后的值------(3) ---------------------------- set type 3 FOO_TYPE 等于 3tidb数据库就绪状态判断
某国产设备环境，开机后时，tidb数据库和程序先后启动，但经常出现程序无法连接tidb数据库的现象。经测试，tidb服务启动后，需要等待一定时间（约20秒）方可被连接。原脚本判断tidb是否启动方法：
echo "$(date '+%Y-%m-%d %H:%M:%S') check mysql(tidb) service" >> "$STARTUP_LOG" for ((i=10;i>0;i--)) do mysql_status=`systemctl status tidb | grep Active | awk '{print $3}'` if [ "$mysql_status"x == "(running)"x ] then echo "$(date '+%Y-%m-%d %H:%M:%S') check mysql(tidb) not ok" >> "$STARTUP_LOG" break else sleep 2 fi done sleep 2 ./foobar &由于tidb基本兼容mysql，因此在脚本里完全是将其作为mysql使用的。问题出现systemctl status tidb，该命令输出信息即使是运行状态，也不代表tidb可用。经查，发现tidb还开启了另一个端口10080，因此，可以通过检测该端口信息实现判断。修改后脚本如下：
echo "$(date '+%Y-%m-%d %H:%M:%S') check mysql(tidb) service" >> "$STARTUP_LOG" for ((i=10;i>0;i--)) do #mysql_status=`systemctl status tidb | grep Active | awk '{print $3}'` #if [ "$mysql_status"x == "(running)"x ] if curl -s -f http://127.0.0.1:10080/status > /dev/null 2>&1 then echo "$(date '+%Y-%m-%d %H:%M:%S') check mysql(tidb) not ok" >> "$STARTUP_LOG" break else sleep 2 fi done sleep 2 ./foobar &误删容器库目录的.o文件
俗话说，常在河边走，哪能不湿鞋。这不，为了在容器里编译更多程序，需要将本地虚拟机的一些库和头文件拷贝放到容器里。但误操作。
我需要将库拷贝到系统目录，但误操作拷贝了当前目录的所有文件，于是进入系统目录，删编译，过程如下：
cp * ../tmp/libx86/libaio.so.1 /usr/lib64/ [root@0df7e76a5f0e lib64]# rm *.o rm: remove regular file 'Mcrt1.o'? y rm: remove regular file 'Scrt1.o'? y rm: remove regular file 'common.o'? y rm: remove regular file 'crt1.o'? y rm: remove regular file 'crti.o'? y rm: remove regular file 'crtn.o'? y rm: remove regular file 'gcrt1.o'? y rm: remove regular file 'log.o'? y rm: remove regular file 'main.o'? y rm: remove regular file 'utils.o'? y上面出现的crti.o和crt1.o是系统文件，不能删除。这不，在编译时出现错误：
/usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory collect2: error: ld returned 1 exit status补救过程：
首先使用相同镜像开启另一个容器，进入容器，查看缺少的.o文件，将其打包。再在主机将容器的压缩包拷贝出来，再放到出现问题的容器里，解决。
我没有拷贝虚拟机的.o文件，因为这两个系统毕竟有差异，而使用相同镜像，保证了源头绝对的一致。
主要命令如下：
# ls /usr/lib64/*.o /usr/lib64/Mcrt1.o /usr/lib64/Scrt1.o /usr/lib64/crt1.o /usr/lib64/crti.o /usr/lib64/crtn.o /usr/lib64/gcrt1.o mkdir /tmp/ofile cp /usr/lib64/*.o /tmp/ofile/ tar zcf ofile.tar.gz /tmp/ofile/ # 主机拷贝操作 docker cp buildx86_1:/ofile.tar.gz .将本地文档文字拷贝到WPS在线文档保持标题编号的方法
问题：近几个月，不时地要写各项材料文字，由于在线文档比较卡，因此一盘先下载到本地，编写完毕后再拷贝在在线文件（而不是整体上传），但此时，拷贝后的文字标题编号却从1开始。
解决：本土新建文档，将完整的标题和正文拷贝到新文档，光标定位到标题，右键选择“项目符号和编号…”，选择“自定义列表”，选择“自定义…”，根据实际情况选择不同级别标题，设置编号。比如，实际起始的标题编号为2.10，则将级别1的起始编号改为2，级别2的改为10，这样新建文档的编号就与实际的一致，直接拷贝到在线文档就正常了。
WPS空间占用
看到新闻，WPS的缓存文档默认写到C盘，缓存占用空间大。间清理C盘更多是某钉数据，WPS看图缓存等等，在线文档的占用倒没太多感觉。但我的确不喜欢每次开WPS时，首页都强调高效办公，等待数秒后，刷新在线文档出来，还有很多应用中心。关闭软件后，云盘图标还在，每次要再次关闭。
但有一说一，云盘的确方便，如果管理得当，效率还是很高的。
线上问题与加班
月初某天深夜和凌晨，2位领导来电话，但我手机免打扰了，第二天早上才发现，后来打听了一圈，我没接电话，再打给另一同事，也没接听电话，再打给另一同事，接听了，于是同事和领导到单位处理了，是线上一个版本升级的问题。去年某天凌晨3点，我接了运维值班同事的电话，也是线上问题，但不是我负责的，但醒来就睡不着了。
后面买了黑色素，但也没办法改善睡眠，一是工作上的压力大，二是家里那堆杂七杂八的事，大的小的都不是省油的灯。
经此事后，手机不敢随便调了，我甚至还买了一个几十块钱的手环，专门用于睡觉随时响应。
月底，又到了线上版本升级的期间，在前一天，领导单独找我，问我有哪些措施，毕竟是大部分是自己负责的，回答也算得体，但领导还是强调，晚上要保持电话申请，如果运维同事有需求，要随时响应。后面与相关人员沟通，并侧面打探，晚班的运维人员技能和水平有待加强，因此，最终还得自己守着，当然，也只是守望到凌晨1点钟，通宵可不敢。所幸当晚没出什么问题。其实，在此前我在脑海里复盘了几次，认为不会出问题。
每年依然有那么几次是凌晨蹲点加班的，下班路过街道，依然感叹南宁的夜生活丰富多彩，一些黄金地段人声鼎沸，各式烧烤奶茶没一样落下的。
希望那次没接电话不会影响我的绩效。