这个任务需要我们拿到command的返回值，然而我们的command遇到问题直接user_panic了，出错时的返回值不详。
因此，我们目前的指令似乎没有能返回错误码的，需要我们修改所有command以使其能返回错误码吗，如果是，我们应该返回什么错误码
回复主题帖
现在还是在实现这个exit返回值的功能，我和同学都遇到了同一个症状的bug：管道符右侧指令输入错误会整个MOS都卡死，左侧输错和单条指令输错均不会。
我的实现是在exit里进程destroy前用ipc_send发同步消息，在wait()函数里用ipc_recv接收消息。
4005号进程是ls指令的子shell，4086号进程是ca（错误指令）的shell，上图waiting处是debug信息（见下），但是令人疑惑的是完全不知道4005号进程为什么会在开始执行ls前发生wait以及没有收到消息他为什么会继续向下运行到红框处。
4005号进程为什么会在开始执行ls前发生wait以及没有收到消息他为什么会继续向下运行到红框处。
你的实现为：
4005 waiting表达的应该是有进程在等待4005进程发送消息。然后后面的4005 spawn ls: started应该才是4005进程的spawn输出。
管道符右侧指令输入错误会整个MOS都卡死，左侧输错和单条指令输错均不会。
可以考虑一下进程在wait和exit使用ipc通信，进程与fs进程也是使用ipc进行通信，ipc对进程状态的设置对进程调度队列的影响以及进程调度队列的执行。
需要注意fs进程运行一个时间片其实最多只能解决一个请求。
这里卡死的原因应该是4806子进程结束返回的1到了4005进程spwan函数调用open函数进而调用fsipc_map函数的ipc_recv，导致open返回1，可是spawn中如果open返回值小于0才会返回该返回值，所以会使用readn读取二进制文件ls.b的内容，但是由于4806进程使用ipc_send时，并没有使用srcva映射到4005进程在fsipc_map中设置的dstva，导致readn函数此时访问空地址，从而卡死。
由于没有直接代码，我猜测原因是这样，如有疑问或者错误欢迎提出。
请问现在开放的shell自动测试的形式是怎样的。
我已实现前两个测试点要求的内容（条件执行与三个新增指令）。
自己验证了&&与||的逻辑基本没有问题，为何所有点都无法通过测试呢？
（手搓测试见下）
（无论是带不带那些调试信息（destroying env等）均无法通过任何测试点
ps：我修改了init.c，使得启动可以通过make && make run，应该无伤大雅。
可以参考下这个，评测基本都对应各自说明的内容。
请问助教 
但是评测所给的makefile里面并没有history.b，这是不是意味着正确实现为history.b的办法不可行呢
