请记住, 的实现不止一种mv
。在mv
由完全相同的源作为OSX或Solaris等一个你在Linux上使用的不是 ,但它是希望他们都以同样的方式行事-这是点标准。可以想象,一个mv
实现可以为此目的添加一个选项,尽管因为它很容易处理,所以它可能不值得,因为非常小的好处被一个更严重的负面后果所抵消:编写的代码利用了这样一个非- 实现的标准选项不会在使用标准实现的另一个系统上不断移植/表现。
mv
是由POSIX标准,这明确地捆绑其行为的rename()
系统调用。在 ISO C 中, 的行为rename()
不是很具体,很多事情都由实现决定,但在 POSIX 下,您会注意到潜在的ENOENT
错误,表明“ new的路径前缀的组件不存在”,描述了要执行的行为以明确的方式预期。这比歧义好,把这些细节留给实现,因为后者会损害可移植性。
为了保护设计,在脚本上下文中,默认情况下在无效目标路径上失败可能比假设它只需要创建要好。这是因为路径本身通常可能来自用户输入或配置,并且可能包含拼写错误;在这种情况下,脚本此时应该会失败并向用户指示他们输入了无效路径。编写代码的人当然可以选择实现不同的行为并创建不存在的目录,但最好由您负责这样做而不是相反(负责确保mv
调用不会创建以前不存在的目录)。
归档时间: |
|
查看次数: |
16273 次 |
最近记录: |