本文为 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点钟,通宵可不敢。所幸当晚没出什么问题。其实,在此前我在脑海里复盘了几次,认为不会出问题。
每年依然有那么几次是凌晨蹲点加班的,下班路过街道,依然感叹南宁的夜生活丰富多彩,一些黄金地段人声鼎沸,各式烧烤奶茶没一样落下的。
希望那次没接电话不会影响我的绩效。