shall 内部命令 和 外部命令

本文介绍了UNIX系统的内部命令和外部命令的区别。内部命令是shell的一部分,执行效率较高;外部命令则是独立程序,功能更强大。文章还讲解了如何区分这两种类型的命令及shell的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    UNIX 命令有内部命令和外部命令之分。内部命令 实际上是shell程序的一部分,其中包含的是一些比较简练的UNIX系统命令,这些命令由shell程序识别并在shell程序内部完成运行,通常在UNIX系统加载运行时shell就被加载并驻留在系统内存中外部命令 是UNIX系统中的 实用程序部分,因为实用程序的功能通常都比较强大,所以它们包含的程序量也会很大,在系统加载时 并不 随系统一起被加载到内存中而是在需要时才将其调进内存。通常外部命令的实体并不包含在shell中,但是其命令执行过程是由shell 程序控制的。shell程序管理外部命令执行的路径查找、加载存放,并控制命令的执行。内部命令要比外部命令的反应时间快一些,内部命令不用启动一个子shell来运行

查看shell内部命令:[...]#man builtins

判断某命令是否是内部命令:[...]#type -a command

[...]#command --help   查看外部命令的帮助文件

[...]#help command     查看内部命令的帮助文件

 

    shell是用户和Linux内核之间的接口程序,如果把Linux内核想象成一个球体的中心,shell就是围绕内核的外层。当从shell或其他程序向Linux传递命令时,内核会做出相应的反应。

    shell是一个命令语言解释器,它拥有自己内建的shell命令集,shell也能被系统中其他应用程序所调用。用户在提示符下输入的命令都由shell先解释然后传给Linux核心。

    有一些命令,比如改变工作目录命令cd,是包含在shell内部的。还有一些命令,例如拷贝命令cp和移动命令rm,是存在于文件系统中某个目录下的单独的程序。对用户而言,不必关心一个命令是建立在shell内部还是一个单独的程序

        当普通用户成功登录,系统将执行一个称为shell的程序。正是shell进程提供了命令行提示符。作为默认值(TurboLinux系统默认的shell是BASH),对普通用户用“$”作提示符,对超级用户(root)用“#”作提示符。

        一旦出现了shell提示符,就可以键入命令名称及命令所需要的参数。shell将执行这些命令。如果一条命令花费了很长的时间来运行,或者在屏幕上产生了大量的输出,可以从键盘上按ctrl+c发出中断信号来中断它(在正常结束之前,中止它的执行)。

当用户准备结束登录对话进程时,可以键入logout命令、exit命令或文件结束符(EOF)(按ctrl+d实现),结束登录

    用户登录到Linux系统后,系统将启动一个用户shell。在这个shell中,可以使用shell命令或声明变量,也可以创建并运行shell 脚本程序。运行shell脚本程序时,系统将创建一个子shell。此时,系统中将有两个shell,一个是登录时系统启动的shell,另一个是系统为 运行脚本程序创建的shell。当一个脚本程序运行完毕,它的脚本shell将终止,可以返回到执行该脚本之前的shell。从这种意义上来说,用户可以 有许多 shell,每个shell都是由某个shell(称为父shell)派生的。

    在子shell中定义的变量只在该子shell内有效。如果在一个shell脚本程序中定义了一个变量,当该脚本程序运行时,这个定义的变量只是该 脚本程序内的一个局部变量,其他的shell不能引用它,要使某个变量的值可以在其他shell中被改变,可以使用export命令对已定义的变量进行输 出。 export命令将使系统在创建每一个新的shell时定义这个变量的一个拷贝。这个过程称之为变量输出。

<think>嗯,用户问的是软件需求文档中shallwill的区别正确用法。我之前记得这两个词在需求文档中有不同的使用规范,但具体细节可能需要仔细回忆一下。首先,shall通常用来表示强制性要求,也就是系统或组件必须实现的功能,而will可能更多用于描述未来的意图或行为,不具有强制性。不过,用户可能在实际文档中看到过混用的情况,所以需要明确两者的区别。 根据引用中的内容,特别是引用[1]提到形式化规格说明语言的语法语义,这里的需求文档需要明确的语义定义。引用[2]也提到需求条目化的重要性,每个需求应该是原子级的,避免歧义。所以使用shallwill的正确与否会影响需求的清晰度。在软件需求规格说明中,shall通常被用来指明系统或组件必须满足的条件,这是强制性的,而will可能用于描述系统的预期行为或未来状态,但不作为强制要求。例如,“系统shall在用户登录时验证密码”是强制性的,而“用户will在登录后看到欢迎页面”可能只是描述流程,但可能不具约束力。不过,有些文档可能误用will来表示需求,这可能导致开发过程中的误解。需要确保所有强制性需求都用shall,而will用于其他情况。此外,引用[3]提到负面投票需要提供替代方案或详细理由,这可能与需求评审过程相关,但shall/will的用法关系不大。引用[4]提到多人协作编写代码,这也间接说明需求文档的清晰性对团队协作的重要性,所以正确使用shallwill有助于减少沟通成本。可能用户在实际工作中遇到需求文档的撰写问题,或者正在学习如何编写规范的需求文档,需要明确这两个词的使用规则。需要进一步确认是否存在行业标准或常见的规范,比如IEEE标准中对shall的规定,或者某些公司内部的风格指南。总结起来,shall用于强制性需求,will用于陈述事实或意图。正确使用这两个词可以提升文档的准确性可执行性,避免开发中的误解。同时,需要提醒用户遵循项目或组织的具体规范,因为不同机构可能有不同的用词习惯。</think>在软件需求规格说明中,“shall“will”的用法区别直接影响需求的强制性语义清晰度。以下是具体分析: ### 1. **核心区别:强制性与陈述性** - **Shall**:表示**强制性要求**,用于定义系统/组件**必须实现**的功能或约束。例如: > 系统 **shall** 在用户输入错误密码3次后锁定账户[^2]。 - **Will**:描述**未来行为**或**事实性陈述**,不具强制性。例如: > 用户 **will** 在登录后看到个人主页。 ### 2. **语义规范与标准** - 根据IEEE 29148标准,需求文档应使用“shall”明确责任主体(如系统、模块)的**义务**,避免歧义[^1]。 - 错误示例: > 系统 **will** 提供数据加密功能 → 应改为“shall”以明确强制要求。 ### 3. **应用场景对比** | 场景 | Shall | Will | |---------------------|--------------------------------|-------------------------------| | 功能需求 | 定义必须实现的功能(如“系统shall保存操作日志”) | 描述用户预期行为(如“用户will收到确认邮件”) | | 非功能性需求 | 定义性能指标(如“响应时间shall≤2秒”) | 描述系统运行环境(如“服务器will部署在云端”) | | 接口需求 | 强制接口协议(如“API shall支持JSON格式”) | 说明接口用途(如“接口will用于数据传输”) | ### 4. **常见错误与修正** - **错误**:混合使用导致责任模糊 ```text 用户 will 提交表单后,系统 shall 返回成功消息 ``` - **修正**:明确责任主体 ```text 当用户提交表单时,系统 shall 在1秒内返回成功消息 ``` ### 5. **实践建议** - **条目化原则**:每条需求仅包含一个“shall”语句,避免“/或”连接多个要求[^2] - **一致性检查**:通过工具(如ReqView、DOORS)自动检测“shall/will”误用
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值