Normal view

There are new articles available, click to refresh the page.
Before yesterday中原驿站

不能在中文目录右键打开 Cygwin 的解决方法

By: 胡中元
24 February 2020 at 12:54

Cygwin 是一个 Windows 下的 Linux POSIX 模拟器,通过它我们可以直接运行一个 Linux 终端,非常好用。

网络上关于如何添加一个 “在当前目录打开 Cygwin” 的右键菜单的教程有很多,但是这些方法都有一个问题,那就是不能在中文目录下正常工作,于是研究了一番,修复了这个问题。

探索

既然英文路径可以但中文不行,我最先想到的是使用 Cygwin 自带的 base64 命令,将 encode(path) 后的非中文字符串传给 Cygwin 之后,再 decode 得到包含中文的路径。然而不行,正确的 base64 传递到 Cygwin 之后 decode 却是乱码。

问题的原因很容易想到,那就是编码的问题。经过几次输出中间变量后验证了这个猜想:Windows 采用的是 GB2312 编码,而 Cygwin 采用的是 UTF-8. Windows 将当前路径作为参数传递给 Cygwin 主程序时,Cygwin 不能正确读取路径。

解决

修改 Windows 或者 Cygwin 的默认编码肯定是下下之策。解决该问题最终还是绕不开编码转换。我最终的思路为:

  1. 右键点击后,Windows 将当前路径作为参数 1 传递给 run_by_right_click.bat 入口程序
  2. run_by_right_click.bat 将路径写入 chere.path 文件(GB2312 编码),并运行 Cygwin
  3. Cygwin 运行后,将 chere.path 转换为 UTF-8 编码,读取后 cd

我的 Cygwin 安装目录为 C:\cygwin64,Shell 为 ZSH,如果你使用的是 Bash,有的地方与我的不同。具体步骤如下:

step1. 创建右键按钮

导入注册表文件 cygwin.reg:

Windows Registry Editor Version 5.00
 [HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin64_bash]
 @="打开 Cygwin 终端"
 "icon"="C:\cygwin64\Cygwin.ico"
 [HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin64_bash\command]
 @="C:\cygwin64\run_by_right_click.bat \"%V\""

step2. 编写入口程序

我们的入口程序 C:\cygwin64\run_by_right_click.bat

@echo off
 SET dir=%1
 REM 双引号删除
 SET dir=%dir:"=%

 C:
 chdir C:\cygwin64
 rem del /Q chere.path
 set /p="%dir%">chere.path
 bin\zsh.exe -li

bat 代码是真的难写。。。写这段代码我便踩了无数的坑。

step3. 完成目录跳转

在 Cygwin 内编写 ~/.zshrc,在末尾添加目录跳转命令:

if [ -e /chere.path ];then
     /usr/bin/enca -L zh_CN -x utf-8 /chere.path
     CPWD=/usr/bin/cat /chere.path
     rm /chere.path
     cd /bin/cygpath "$CPWD"
 fi

这里用到了 enca 用于自动编码转换,所以需要在 Cygwin 包管理器中安装这个软件。

over! 现在便可以在中文文件夹中右键打开 Cygwin 了。

为啥我要用 Cygwin

最后最后。你可能会说,为啥都新世纪了,你还在用 Cygwin 这种… 模拟器?原生 Linux/ 虚拟机 不好用嘛?WSL 不香吗?甚至 Powershell 不也不错?

那我还真觉得 Cygwin 秒杀上述所有的方案。首先,我只是想在 Windows 上安装一个代替 cmd 的 Shell 环境用于日常操作,并不需要高性能什么的,所以原生 Linux 系统、虚拟机、Docker 就不是解决同一个问题的东西。

至于 Powershell,虽说是比 cmd 好多了,但毕竟是另一套语法和体系,我不想学它也对它不感兴趣。Bash+GNU tools 那才是世界通用法则。ZSH 作为日常使用的终端也确实美观好用!

而 WSL 这东西确实很吸引人,性能比 Cygwin 强太多,几乎就是原生系统。然而!WSL 运行于内核态,与 Windows 平级,就算有文件系统的映射,WSL 也并不能直接当作 Windows 的 Shell 来使用的。看下面的图你就知道我在说啥了。

Cygwin+ZSH 很好用

图中,npm 和 git 是我在 Windows 中安装的 exe 包,而 ssh、tail、md5sum 是 Cygwin 中提供的 Linux 命令,直接相互调用无压力,这才是 Windows 中我想要的 Shell 的样子。可是 WSL 是不能这么做的,两个系统是隔开的。

在 OpenWrt 路由器上运行 UnixBench 基准测试

By: 胡中元
24 September 2017 at 18:33

我这基于 OpenWrt 的路由器可以说是超级强大,不仅仅是一个无线路由器,插上 U 盘可以变身为 NAS+下载机,可以运行 Python 小程序,甚至还有人在上面搭建 LNMP 运行 Owncloud。可以说是一台 VPS 可以干的事情我都可以在宿舍的路由器上实现,十分强大。

然而最近才了解到,这颗 580MHz 的 MTK7260A 仅仅是一颗智能路由器当中处于中低端的 CPU,说实话我是不信的,于是打算用 UnixBench 来客观测试一下这个小家伙的真实水平。

UnixBench 是基于 Perl 并拥有 30 年历史的基准测试软件,也就是跑分软件。通过运行一系列科学计算函数测试 CPU 性能,以及 OS 的任务执行效率、硬盘性能等。最终得到一个分数。

测试平台

路由器:Newifi Mini
OS:LEDE 17.01.2(一个 OpenWrt 的著名分支)
Linux Kernel:4.4.71
架构:MIPS
RAM:128M
ROM:16M

系统基本为纯净的 LEDE,除了正在运行着路由器的基本网络服务外,跑分时运行了一个 PPTP VPN Client 服务。

交叉编译及运行步骤

OpenWrt 的 libgcc 套件体积 22M 的样子,但正如上面所写,我的路由器 ROM 总共只有 16M,挂载分区什么的不是很有必要,于是我使用交叉编译 UnixBench。

简单介绍一下交叉编译的步骤吧:

1、找一台 x64 的 Linux 机器,按照 <https://wiki.openwrt.org/doc/devel/crosscompile> 步骤开始接下来的操作。必须得要 x64 的主机。

2、下载你的路由器当前系统当前机型对应的 DevPack,比如我的 LEDE 在这里下载的:<http://downloads.lede-project.org/releases/17.01.2/targets/ramips/mt7620/lede-sdk-17.01.2-ramips-mt7620_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz>,OpenWrt 请在 <https://downloads.openwrt.org/> 下寻找。

3、按照官方 Wiki 的步骤将编译器添加到环境变量。

4、下载 UnixBench 的源代码并解压:<https://github.com/kdlucas/byte-unixbench>

5、开始编译。这里注意官方 Wiki 有误,请使用 make CC=mipsel-openwrt-linux-musl-gcc LD=mipsel-openwrt-linux-musl-ld 命令使用指定编译器进行编译。

6、编译失败?根据提示删除 Makefile 中编译器无法识别的两个参数,即可完成编译。

7、将除了 /src 外的文件 scp 到路由器。

8、安装相关依赖:opkg install perlbase-posix perl perlbase-time perlbase-io perlbase-findbin coreutils-od,跑分完后即可删除。

9、尝试运行 ./Run,你会发现弹出错误,根据错误内容做出以下修改。

10、修改 ./Run,注释掉 use strict 和两处尝试执行 make all 的语句。

11、这时再运行 ./Run,就已经自动开始跑分了。虽然会有几个 Wrong 弹出,但是不要紧。

基准测试结果

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: : GNU/Linux
   OS: GNU/Linux -- 4.4.71 -- #0 Wed Jun 7 19:24:41 2017
   Machine: mips (unknown)
   Language:  (charmap=, collate=)
   17:01:34 up 13:01,  load average: 0.25, 0.49, 0.34; runlevel

------------------------------------------------------------------------
Benchmark Run: Sun Sep 24 2017 17:01:34 - 17:37:25
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        1261494.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                       24.3 MWIPS (9.9 s, 7 samples)
Execl Throughput                                452.5 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks            41.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks              18.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks           115.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              154847.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  51157.7 lps   (10.0 s, 7 samples)
Process Creation                               1260.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                     43.2 lpm   (61.1 s, 2 samples)
Shell Scripts (8 concurrent)                      6.5 lpm   (64.3 s, 2 samples)
System Call Overhead                         308931.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    1261494.8    108.1
Double-Precision Whetstone                       55.0         24.3      4.4
Execl Throughput                                 43.0        452.5    105.2
File Copy 1024 bufsize 2000 maxblocks          3960.0         41.0      0.1
File Copy 256 bufsize 500 maxblocks            1655.0         18.5      0.1
File Copy 4096 bufsize 8000 maxblocks          5800.0        115.4      0.2
Pipe Throughput                               12440.0     154847.5    124.5
Pipe-based Context Switching                   4000.0      51157.7    127.9
Process Creation                                126.0       1260.9    100.1
Shell Scripts (1 concurrent)                     42.4         43.2     10.2
Shell Scripts (8 concurrent)                      6.0          6.5     10.9
System Call Overhead                          15000.0     308931.8    206.0
                                                                   ========
System Benchmarks Index Score                                          11.3

感叹

总分 11.3 是什么水平呢,我用我的洛杉矶服务器也跑了一下,3.5GHz 的 E3 处理器,不过是共享主机,并且只有单核的使用权。得到的分数为 1245.

这说明,这个功率为 10W 不到的路由器综合能力果然很弱,哈哈哈。。。

不过就算再弱,竟然可以跑完整的 Linux 4.4,能够运行起 Python、Nginx、MySQL、PHP-FPM、SSHD、Samba、DNS 等等一系列服务,还非常的稳定,不得不让人对 Linux 竖起大拇指呀~

 


后来我又换了 K3 路由器,ARM 双核 1.4GHz,可以代表着当前家用路由的最高水平,我用它跑了一遍 UnixBench,结果见下一页。

❌
❌