变量和别名属于同一类别吗?

变量和别名属于同一类别吗?

这是一个术语/架构问题。

为了更轻松地控制系统,一些最基本的实现是变量和别名(有些可能会添加符号链接)。

变量和符号链接都“位于后台”,并且可以由用户调用(我猜“扩展”对两者都有好处)。

我问变量和别名是否属于同一类别,因为我想更好地命名包含它们列表的文件(第一部分是变量,第二部分是其中一些使用某些变量的别名)。

我不想给出一个更“标准”的名称,而不是像“background_data.sh”这样的通用名称,它可能类似于两者可能共享的组或类别。

答案1

别名、函数、变量等所属的“类别”是环境,如“shell 环境”中一样。

变量和别名是非常不同的东西,符号链接也是如此(它们是不是shell 环境的一部分,但是文件系统中的东西,独立于 shell)。

  • 变量,无论是 shell 变量还是环境变量,都以字符串的形式保存数据。

  • 别名是一种方便的快捷方式,可在交互式 shell 会话中使用,以节省键入经常重复的命令的时间。别名在与变量分开的评估阶段进行扩展。请注意,在脚本中,您很可能想要使用功能而不是别名,因为它们不仅仅是命令名称的简单文本替换1

  • 符号链接是文件系统中的一种特殊类型的文件,在访问时(宽松地说)会自动解析为路径。

至于如何调用您的文件;听起来像是一个应该被获取的文件(通过.任何sh类似 shell,或者在source具有该命令的 shell 中)来为某些应用程序或进程设置环境,所以我可以建议类似application-name.env或的东西process-name.env,可能吗?


1脚本中的别名让我有点恼火。正如我所说,别名是为了在交互式 shell 中提供方便,人们可能希望始终添加标志-Fls因此定义alias ls='ls -F'或类似的东西。但在脚本中,您可能希望更详细。造成这种情况的原因至少有两个(以下是个人观点):

  1. cprm在脚本中应该这样做。标准命令不应该被脚本中的别名覆盖,否则调试起来会非常麻烦。

  2. 别名用于交互式命令行(您一次又一次地键入它们,以提高速度和/或节省手指和双手)。脚本编写一次(并可能进行改进)。这允许您以其他人(或您自己在几周内)可以轻松阅读和理解的方式编写脚本,这意味着您可以在编写脚本时允许自己更加详细。好处是可维护性。

  3. 别名不能接受参数,至少不能像函数那样接受参数。这使得函数很多比别名更通用。例如,您创建的函数不仅可以通过在调用实用程序之前验证参数是否正确来调用实用程序,而且还可以确保结果按预期返回,而不是为命令设置别名。如果您愿意,函数甚至可以进行自己的命令行解析,并且这种方式可以作为脚本中自己的“实用程序”。

我正在为很多人参与的项目编写一些脚本,这是为了工作,所以这就是我的观点。

答案2

其他答案中解释了差异,我认为出于您的目的,文件扩展名rc会很合适:

它用于包含命令启动信息的任何文件。

它有不同的口味,如<appname>rc<appname>.rc<appname>-rc。众所周知的例子是/etc/inputrc~/.bashrc~/.vimrc

答案3

从技术上讲,别名是命令解释器使用的定义。设置变量和设置别名都是以下形式任务

虽然您可以设置、写入、取消设置和删除别名,但它们在语义上与 shell 中的变量不同,因为它们是全局的,并且除了存储值之外还执行其他操作。

相关内容