cish 开发构想

不点

下面这个英文帖子讲了 proc 和 sys 的区别，以及来龙去脉。尤其是讲了，进程信息仍然留在 proc 当中，不像是要挪到 sys 里面的样子。在别的地方看到有人说 “proc 过时了，已经被 sys 取代了”，这是误导。澄清了这一点，我们就可以放心地用 proc 来处理进程信息、实现作业控制了。不过，proc 也有 “不兼容性” 的弱点 —— 非 Linux 的操作系统有可能不支持 proc。某些早期的 BSD 支持 proc，但后来不再支持了。然而，我没打算支持 BSD；我只打算支持 Linux。因此，这就不算是个问题了。

What is the difference between procfs and sysfs?

不点

前些日子整合了具有 “job control” 的 tsh。然而，它运行的 child 好像没有正确收养，而成为孤儿。

本次实现了后台运行 child（用命令结尾的 “&” 来表示后台运行），但没有 “job control”（即，没有 fg、bg、jobs 等命令）。试试看，会不会有 “孤儿” 或 “僵尸” 出现？

不点

学习线程知识，找到这本书：

Modern Operating Systems (3rd Edition)
https://www.amazon.com/dp/0136006639/?tag=stackoverflow17-20

不点

今天试验了一下，可以用 C 语句来实现 “后台执行某个 C 语句块”：

1. if (pid_t cpid = fork ()) { if (cpid == -1) {perror("fork");return 1;} return 0;} else for (;;exit(0)){ for (;;){sleep(5); puts("OK");} }

复制代码

上述语句很长，但只有结尾处的这个语句块是我们想要在后台执行的：

1. { for (;;){sleep(5); puts("OK");} }

复制代码

而它前面的一长串代码：

1. if (pid_t cpid = fork ()) { if (cpid == -1) {perror("fork");return 1;} return 0;} else for (;;exit(0))

复制代码

可以看成只不过是个 “前缀” 罢了。如果把这个前缀定义成某个宏，比如就叫做 bg：

1. #define bg if (pid_t cpid = fork ()) { if (cpid == -1) {perror("fork");return 1;} return 0;} else for (;;exit(0))

复制代码

那么，本帖开头的那个长语句就可以简化了：

1. bg { for (;;){sleep(5); puts("OK");} }

复制代码

---

---

---

【更新】bg 命令已经被 bash 等 shell 使用。因此换成 “cb”（意思是 Child in Background）。cish 启动时，已经自动添加如下宏定义：

1. #define cb if (pid_t cpid = fork ()) { if (cpid == -1) perror("fork");} else for (;;exit(0))

复制代码

1. #define cf if (pid_t cpid = fork ()) { int status; if (cpid == -1) {perror("fork"); 1;} else if (-1 == waitpid(cpid, &status, 0)) {perror("waitpid"); 1;} else status;} else for (;;exit(0))

复制代码

其中 cf 是 “在前台启动子进程” 的意思。注意区别：当不使用 cf 时，是在当前进程中运行 C 语句块。当使用 cf 时，是在子进程（即子 shell）中运行 C 语句块。

cb 和 cf 的共同点是，它们都要启动子 shell。不同之处是，cf 在前台运行子 shell，因而需要等到子 shell 结束后才能继续运行后续的语句。cb 是在后台运行子 shell，无需等待子 shell 结束，紧接着立即执行当前进程中的后续语句。

要想在后台子 shell 中运行某个语句块 {...}，只需在其前面添加 cb 即可。举例：

1. cb { for (;;){sleep(5); puts("OK");} }

复制代码

要想在前台子 shell 中运行某个语句块 {...}，只需在其前面添加 cf 即可。举例：

1. cf { for (int i=0; i<100; i++){sleep(1); printf("%d ", i); fflush(stdout);} }

复制代码

后台运行的子进程，如果在父进程（也就是当前 shell）结束之前就结束（终止、死）了，那么父进程会为子进程正确地 “收尸”。父进程每次执行一个新命令时，就要检查是否有子进程退出（死掉），并为死去的子进程收尸。但如果子进程在父进程结束之后还活着，则它将成为 “孤儿”，Linux 内核会让 init 进程 “收养” 它，并在它死去时为它收尸。

不点

发现 cling 支持 asm。试试 nop 指令，没有报错。而用一条不存在的 nopp 指令来试验，则报错。这说明 asm 能够正常工作。

1. user@ttyd:~$ cish
   
2. [cling]$ asm("nop");
   
3. [cling]% asm("nopp");
   
4. <inline asm>:1:2: error: invalid instruction mnemonic 'nopp'
   
5.         nopp
   
6.         ^~~~
   
7. [cling]%

复制代码

gnuxwy

嗯，又来看不点大师的进展了，祝贺大师的找到了更合适的ladsh参考。。。

屮也觉得不必要拘泥于posix兼容，如果cish基本只在gnux平台上用，就用不着考考虑其他方面。
而且小而专的软件其实也挺好的，比如busybox这个实用工具，在嵌入式领域应用很广，典型的小而精。

不点大师搞cish，如果成熟了，作为教学shell就很不错。
既可在教学中示例写点C程序范例，又可示范学习使用shell的一些基本功能。。。

不点

前台进程，会话，控制终端，用户的关系

原创 2015年02月15日 16:57:24 https://blog.csdn.net/codinghonor/article/details/43836211

1、一个会话和一个控制终端一一对应
2、一个控制终端对应一个前台进程组
3、一个会话拥有一个前台进程组和若干后台进程组
4、会话中的所有进程都对应同一个控制终端
5、只有前台进程可以 read write 控制终端
6、控制终端收到一些特殊的信号字符，会发送相应的信号给前台进程组的进程
7、控制终端退出或者控制进程的退出，会发送 SIGHUP 信号给前台进程组

完整场景： 用户通过终端登录时，login shell 成为会话 leader 和控制进程，该终端被设置成为控制终端；login shell 是该会话的唯一进程，在该终端中执行命令，会将命令中的进程放入一个新的进程组（前台or后台）执行；当终端关闭时，内核发送 SIGHUP 给控制进程，即 login shell， login shell 发送 SIGHUP 给由 login shell 创建的所有进程组，如果 login shell 控制进程退出，则 kernel 发送 SIGHUP 给前台进程组中的所有进程（支持作业的情况下，也会发给后台进程组中的所有进程），SIGHUP 的默认动作是终止进程，所以 login shell 和相应的子进程都终止，控制终端和会话的映射关系解除。



不点

前台进程就是用户使用的有控制终端的进程

进程间关系：进程、僵尸进程、孤儿进程、进程组、前台进程组、后台进程组、孤儿进程组、会话、控制终端

https://lesca.me/archives/process-relationship.html

不点

是的，我一直在想，jobs、fg、bg 等作业控制命令，能否用外部命令来实现。就是说，不把 “作业控制” 当作 shell 的特色，而是当作操作系统（进程控制）中的一项固有功能。

假如 jobs、fg、bg 可以用外部命令实现的话，那它们就不该用内部命令来实现。为什么？因为权衡。那些使用频率很低的命令，不该占用 shell 的常驻内存资源，或者增加 shell 可执行文件的大小。

不点

下面这个网页讲述 nohup、disown 等知识，非常透彻，质量高。
https://unix.stackexchange.com/questions/3886/difference-between-nohup-disown-and

从上述网页了解到，正是由于 shell 在退出时向各个 jobs 发送 HUP 信号，才导致子进程退出的。如果 shell 不发送 HUP 信号，那么子进程就不会自动退出。

我觉得，是 shell 本身把这个问题复杂化了。

这不符合 unix 崇尚简单的理念。干一件事，只干这一件事，不要附带干很多事。干的事越多，水搅得就越浑，把本来简单的东西，一下子就派生出一堆复杂问题去处理，属于没事找事的范畴。

顺便谈谈对于 setuid 的看法。为了让 passwd 能够写入 shadow 之类的文件，就发明了 setuid 位，让用户能够更改身份，制造出一个巨大的漏洞，至少是个隐患，需要经常修补。

另一方面，真正需要强化和完善的地方，却又不作为。比如，rwx 这个权限设计过于简单，后来用 ACL 来打补丁，却不从系统层面直接加强 rwx 的设计逻辑。

不知

不点 发表于 2018-4-21 14:01
下面这个网页讲述 nohup、disown 等知识，非常透彻，质量高。
https://unix.stackexchange.com/questions/ ...

suid位确实有存在的必要，毕竟linux只是系统内核，如果没有suid位，应用就不能提权，只能降权，不方便使用（除非像windows那样留一个高权限的后台进程来提权）。而且suid位可通过文件系统的nosuid选项禁止，也不算太复杂，只要root用户不乱改，现在的发行版linux一般不会出现大的suid漏洞。文件系统的rwx设计的确有些简单。

不点

不知 发表于 2018-4-21 18:14
suid位确实有存在的必要，毕竟linux只是系统内核，如果没有suid位，应用就不能提权，只能降权，不方便使 ...

我的意思是说，一开始是什么身份，就一直保持什么身份，不要让其能够改变身份。需要提权时，都用系统调用。

比如，要修改口令，可以用系统调用来实现，不一定非得用带 suid 的 passwd（可执行文件）来实现。

用 suid 的好处是，系统设计简单了，不需要管很多事情了；也或者说是放权了（下放权力给那些 suid 程序了）。但坏处是每个 suid 程序都可能存在漏洞，都需要对其代码进行严密监视。假如某些复杂的程序有隐藏后门，那情况就很严重了。一般来说，漏洞会逐渐减少，问题不太严重。而后门是故意设置的，即使开源，也不一定能够被发现。我从 bash 混乱的代码结构，就想到这个问题了。不一定有人去认真检查 bash 的代码。它那么乱，检查者也会累死的。

如果用系统调用来实现，就好比什么事情都要让皇帝（系统内核）亲自过问，这对皇帝的要求很高，皇帝也很累。这是其弱点。而用 suid 程序可以分担内核的任务，减轻内核负担。确实，原则上讲，用 suid 是对的。

不知

不点 发表于 2018-4-21 19:32
我的意思是说，一开始是什么身份，就一直保持什么身份，不要让其能够改变身份。需要提权时，都用系统调用 ...

suid程序在运行时，uid其实没变，变的是euid，还是要调用setuid();才能完全改变自己的身份，而一般用户能调用setuid()设置为自己的uid，root用户可设置任意的uid。

不点

不知 发表于 2018-4-21 20:30
suid程序在运行时，uid其实没变，变的是euid，还是要调用setuid();才能完全改变自己的身份，而一般用户 ...

刚刚接触这些东西，理解得不深。还要靠大家多多帮助。谢谢。

不点

这个 cish 项目如果完成了，它的代码不会像 zsh、bash、dash 那么混乱。它会像 ladsh 那么清晰易懂，方便草根们去检查、检验和监视。

不点

通过这段时间的摸索，基本弄清了 job 和进程组的关系。job 是一个进程组，但进程组不一定是个 job。

bash 的 disown 命令能够把一个 job 甩出去，让它不再拥有 job 号码。job 和进程组没有本质差别，大概也只有 “是否拥有 job 号码” 的差别罢了。

如此说来，“作业控制” 也基本上可以脱离 shell 而独立实现（即，用外部命令来实现）。当然了，不使用 job number，而使用进程的 starttime 来区别各个 “job”（进程组）。

jobs、fg、bg 等功能，或许可以集成到 ps （外部命令）当中。

准备让 cish 在退出时就直接退出，啥事也不干（不向进程组发送 HUP 等信号）。如果有特殊情况需要向某个进程组发送 HUP 信号，那可以通过 .cish_logout 等文件来实现（用 kill 之类的命令）。

另外，作业控制也只在交互操作时才有用（脚本中基本不使用），而且使用频率很低。在现代 “多窗口” 虚拟终端的情况下，有没有 job control 在本质上都不影响啥事。

不点

搜 signal 的手册，顺便搜到这个：

http://man7.org/linux/man-pages/man2/signal.2.html

       According to POSIX, the behavior of a process is undefined after it
       ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
       kill(2) or raise(3).  Integer division by zero has undefined result.
       On some architectures it will generate a SIGFPE signal.  (Also
       dividing the most negative integer by -1 may generate SIGFPE.)
       Ignoring this signal might lead to an endless loop.

提到 “整数除以零” 有着 “不确定” 的结果，在某些架构下，它将生成一个 “浮点异常” 信号。最大的负数除以 -1 也可以生成这个信号。忽略这个信号可能导致无限循环（我理解为：它会反复执行除以零的操作，反复生成这个信号）。

在 cish 下试验了一下，最大的负数除以 -1 没有产生 “浮点异常”，但算出的结果是错的（而除以 -2 的结果是正确的）。最大的正数除以 -1，其结果是正确的。

1. 
   
2. [cling]% 0x80000000
   
3. (unsigned int) 2147483648, 0x80000000
   
4. [cling]% (int)0x80000000
   
5. (int) -2147483648, 0x80000000
   
6. [cling]% -2147483648/-1
   
7. (long) 2147483648, 0x0000000080000000
   
8. [cling]% (int)-2147483648/(int)-1
   
9. (int) 0, 0x00000000
   
10. [cling]% (int)-2147483648/(int)(-1)
    
11. (int) 0, 0x00000000
    
12. [cling]% (long)0x8000000000000000/-1L                       <----- 这个计算出问题了，其它计算结果都没问题
    
13. (long) 94575873763376, 0x00005604295c2830               <----- 这结果显然不正确。
    
14. [cling]% (long)0x8000000000000000/-2L
    
15. (long) 4611686018427387904, 0x4000000000000000
    
16. [cling]% (long)0x7fffffffffffffff/-1L
    
17. (long) -9223372036854775807, 0x8000000000000001
    
18. [cling]% (long)0x8000000000000001/-1L
    
19. (long) 9223372036854775807, 0x7fffffffffffffff
    
20. [cling]%

复制代码

不点

这几天在思考、权衡 “如何实现重定向” 的问题。

作为一个参考，Cling 本身有 “重定向” 的功能：

1. [cling]% .1> /dev/null      <----- 将标准输出重定向
   
2. [cling]% ls                      <----- 果然输出结果看不见了
   
3. [cling]% pwd                <----- 再确认一次，这个输出结果也看不见了
   
4. [cling]% .1>         <----- 将标准输出恢复为原先的状况
   
5. [cling]% ls            <----- 此时输出结果出来了：
   
6. a.out*  build_deb_script/  clone.sh  inst/   ladsh1.c  ladsrc/   obj/   src/      src.diff.gz   src.new/  src.tar.gz      tsh.c
   
7. build*  cish@              flush.c   jobs.c  ladsh4.c  Makefile  pid.c  src.diff  src.diff.old  src.old/  ssh_NOTICE.txt  utils/
   
8. [cling]% pwd        <----- 确认一次，这个输出结果也有了：
   
9. /home/user
   
10. [cling]%

复制代码

【2018-05-02 更新】写了一个函数 redir() 来执行重定向。功能与上述 “.>” 元命令等价。举例说明它的用法：

执行 redir ("/dev/null", 1, 0); 之后，标准输出就重定向到 /dev/null 了。
执行 redir ("", 1, 0); 之后，标准输出就恢复原状了。
执行 redir ("/dev/null", 2, 0); 之后，标准错误就重定向到 /dev/null 了。
执行 redir ("", 2, 0); 之后，标准错误就恢复原状了。
执行 redir ("/dev/null", 3, 0); 之后，标准输出和标准错误就重定向到 /dev/null 了。
执行 redir ("", 3, 0); 之后，标准输出和标准错误就恢复原状了。

第三个参数是个 bool 值，当它为 true 时，表示 “追加”，当它为 false 时，表示 “覆盖”。

需要说明的是，cling 目前只有输出重定向功能，没有输入重定向功能。

不点

快讯——

告诉大家一个不幸的消息（也许是令人振奋的消息）——早已有人基于 cling 开发 shell，叫做 ccsh：

ccsh - a C++ shell
https://github.com/cpp-ftw/ccsh

这是我刚刚在搜 “error: ‘UserInterface’ in namespace ‘cling’ does not name a type” 时顺便搜到的！

太恐怖！假如我不搜这个出错信息，我就不会知道早已有这个项目！

它的 readme 里面没有提到 “基于 cling”，这可能是我以前没有找到它的原因——我以此来安慰一下自己。

gnuxwy

居然已经有人搞出cling之上的ccsh啦！
这下不点大师要看看这个ccsh与你的cish相比较而言的设计和实现思路怎样了。。。
总的来说，氏好事耶，有更类似的项目源码可供参考，那氏很有借鉴意义的。。。

不点

gnuxwy 发表于 2018-4-30 16:11
居然已经有人搞出cling之上的ccsh啦！
这下不点大师要看看这个ccsh与你的cish相比较而言的设计和实现思路 ...

还没编译通过   

大家赶紧都来攻克这个编译难题呀！——毕竟编译完成之后，我们立马就有 shell 可用了   

gnuxwy

那个网址氏要翻墙才能访问的吗？
反正屮上不了那个网站。。。什么编译错误呢？可以晒出来大家探讨下。。。

不点

gnuxwy 发表于 2018-4-30 16:58
那个网址氏要翻墙才能访问的吗？
反正屮上不了那个网站。。。什么编译错误呢？可以晒出来大家探讨下。。。 ...

无需翻墙，你再试试。

我把 git clone 出来的上载一份到这里。请下载附件。

不点

编译成功了，show 一下   

这是在本地虚拟机下编译成功的，费了好大牛劲！

编译过程乱得很，出错很多，我已经记不得是如何解决那些错误的了。编译结果很依赖我的目录结构，只能在这台虚拟机下使用，因此目前还无法上传到网上供大家使用。

接下来需要研究它的代码，看看能否融合到 cish 中。

1. deb@debian64:~/ccsh/build$ ./ccsh
   
2. ~/ccsh/build $ pwd
   
3. /home/deb/ccsh/build
   
4. ~/ccsh/build $ ls
   
5. cc    CMakeCache.txt  cmake_install.cmake  Makefile  test
   
6. ccsh  CMakeFiles      lib                   sample    ui
   
7. ~/ccsh/build $ ll
   
8. Command not found: ll
   
9. input_line_5:2:2: error: use of undeclared identifier 'll'
   
10. ll
    
11. ^
    
12. ~/ccsh/build $ 5
    
13. Command not found: 5
    
14. (int) 5
    
15. ~/ccsh/build $ 5 * 9
    
16. Command not found: 5
    
17. (int) 45
    
18. ~/ccsh/build $ * 9
    
19. Command not found: CMakeCache.txt
    
20. input_line_9:2:2: error: indirection requires pointer operand ('int' invalid)
    
21. * 9
    
22. ^ ~
    
23. ~/ccsh/build $
    
24. 
    

复制代码

不点

确认了一次，搜不到 ccsh，不是我笨。

刚刚分别用 cling shell 以及 cling shell c++ 作为关键词在 google 搜，翻了几十页，也没找到 ccsh 的踪迹。倒是能搜到我在 reboot.pro 上贴的有关 cish 的信息。

不知为何 google 现在大不如前了。类似情况好像出现过很多次了。难道 google 受美国退步的影响了？

不点

直接搜 ccsh cling 倒是能够找到 ccsh 的项目页面。

如果只搜 ccsh，会出现一个叫做 CCsh 的工具，它把 sh 脚本转换成（编译成）可执行文件（它不该叫做 CCsh，而应该叫做 sh2exe 之类的）。

ccsh 的名称除了与 CCsh 工具相冲突以外，没有什么缺点。这是个好名字。

不点

昨天编译成功之后，测试方法是错误的，就是说，没有真正体现出 ccsh 的特色。

ccsh 实现的 ls 命令是这样的：需要敲入 ccsh::ls() 才行。乍一看这不是一个方便操作的 shell。但 ccsh 却以其特别的方式实现了 IO 重定向。

比如，“<” 是标准输入重定向，">=" 是标准错误输出重定向。

上述这些设计与 bash 很不相同。我领会到，一个 shell 未必非得兼容现有的 shell，甚至也不一定要符合 POSIX 规范。

ccsh 的设计思路，以及代码，自成一体，好像不太容易吸收到 cish 中。

ccsh 的开发整整停止了一年。期待着 ccsh 能继续活跃开发。

1. deb@debian64:~/ccsh/build$ ./ccsh
   
2. ~/ccsh/build $ ccsh::ls()
   
3. cc    CMakeCache.txt  cmake_install.cmake  Makefile  test
   
4. ccsh  CMakeFiles      lib                   sample    ui
   
5. ~/ccsh/build $ ccsh::ls() > "/dev/null"    <------- 重定向到 null 之后，输出结果看不见了。
   
6. ~/ccsh/build $ ccsh::ls() > "/dev/tty"      <------- 重定向到 tty 之后，输出结果又显示出来了。
   
7. cc    CMakeCache.txt  cmake_install.cmake  Makefile  test
   
8. ccsh  CMakeFiles      lib                   sample    ui
   
9. ~/ccsh/build $

复制代码

不点

用 google 搜 “dup2” 搜到这篇文章，是入门的好材料：

Linux 管道编程技术：dup 函数，dup2 函数，open 函数详解
https://blog.csdn.net/zhouhong1026/article/details/8151235

gnuxwy

嗯，好几天没来无忧了，今日过来瞧瞧，看到不点大师把ccsh的源码搬过来了。
于氏就下载解压试编译下，里面没找到编译说明的文档，随意用cmake弄了下，就开始报错，看来不氏一下
子就能解决这些编译拦路虎的。。。过几天闲点，再试试看能否搞定编译问题。。。

cish可以借鉴下ccsh的源码，但未必就要和ccsh实现shell的思路一样，软件，方便实用就行。。。

不点

gnuxwy 发表于 2018-5-4 23:14
嗯，好几天没来无忧了，今日过来瞧瞧，看到不点大师把ccsh的源码搬过来了。
于氏就下载解压试编译下，里面 ...

发现我俩有许多共同看法，缘分。

在 2000 年以前，我就有开发输入法的打算，也开始收集汉字和词库了，但后来没能继续。当时我发现 “智能狂拼” 的整句输入很先进，梦想着自己能做个更智能的输入法：每个字只需敲拼音的第一个字母，候选句子中检查语法，不符合语法规范的都滤掉，最后候选的句子就不多了（差不多是唯一的），也就是说，用拼音即可盲打了，无需使用五笔输入法。但是，很遗憾，自己水平不够，很多基础知识没能掌握，就不了了之了。你透露了你也想做输入法，我俩在这点还真是 “英雄所见略同”。

从你在本主题 “cish 开发” 的发言来看，还真是与我的想法基本吻合，我能感受到你对这个项目的诚意支持。