我的场景很简单 - 我从Mercurial 在线书籍并将它们粘贴到 Windows 命令提示符中。问题是书中的示例使用单引号字符串。当在 Windows 命令提示符上传递单引号字符串时,后者无法识别单引号之间的所有内容都属于一个字符串。
例如以下命令:
hg commit -m 'Initial commit'
无法在命令提示符中按原样粘贴,因为后者将其视为'Initial commit'
两个字符串 -'Initial
和commit'
。我必须在粘贴后编辑命令,这很烦人。
是否可以指示 Windows 命令提示符将单引号与双引号类似地处理?
编辑
根据 JdeBP 的回复,我做了一些研究。以下是摘要:
Mercurial 入口点如下所示(它是一个 python 程序):
def run(): "run the command in sys.argv" sys.exit(dispatch(request(sys.argv[1:])))
因此,我创建了一个小型的 Python 程序来模拟 Mercurial 使用的命令行处理:
import sys print sys.argv[1:]
以下是 Unix 控制台日志:
[hg@Quake ~]$ python 1.py "1 2 3" ['1 2 3'] [hg@Quake ~]$ python 1.py '1 2 3' ['1 2 3'] [hg@Quake ~]$ python 1.py 1 2 3 ['1', '2', '3'] [hg@Quake ~]$
以下是相应的 Windows 控制台日志:
C:\Work>python 1.py "1 2 3" ['1 2 3'] C:\Work>python 1.py '1 2 3' ["'1", '2', "3'"] C:\Work>python 1.py 1 2 3 ['1', '2', '3'] C:\Work>
可以清楚地看到,Windows 不会将单引号视为双引号。这就是我的问题的本质。
答案1
在 command.com 提示符中无法更改引号字符。但是,您可以使用 PowerShell,它接受单引号和双引号作为引号字符。它们的作用与 Unix shell 中相同。即,单引号不会扩展变量,而双引号会。
您可能仍会遇到引号内加引号的问题。例如,我在 Windows 计算机上安装了 strawberry perl。当我perl -e 'print time, "\n" '
在 PowerShell 中运行时,我看到的输出如下1321375663SCALAR(0x15731d4)
。我必须转义双引号才能使其按预期工作:perl -e 'print time, \"\n\" '
答案2
首先,命令提示符不是命令解释器。(命令提示符就是这样显示命令解释器。)其次,你的命令解释器、它发出的提示符和 Win32 控制台都有什么也没有与此有关。
在 Win32 程序中,将命令行拆分为“单词”——以 NUL 结尾的多字节字符串,C 和 C++ 语言中的程序将其视为传递给的参数数组main()
——是这些程序的运行时库的职责。在 Unices 和 Linux 上,shell 会进行单词拆分,因为操作系统实际上是按照参数字符串数组的方式工作的。Win32 的情况并非如此。在 Win32 上,操作系统本身按照命令尾: A单身的长字符串仍然包含命令行中最初输入的所有引号。(是命令解释器在将此命令尾传递给目标程序之前对其进行了一些处理,但这与分词无关。)
就您而言,程序的运行时库hg
正在传递此命令尾部:
commit -m ‘初始提交’
该程序编译的运行时库不知道您将单引号作为空格引用字符,因为这不是惯例. 该公约涉及仅有的在双引号中(以及双引号前的反斜杠)。
此约定内置于最初用于创建程序的编译器提供的运行时库中。如果要更改约定,则必须重新链接您希望以这种方式运行的每个单独的程序使用您自己制作的特殊运行时库,该库也可以识别单引号。显然这是不切实际的(除非这些都是 Cygwin 程序)。
一个更为实用的方法是做你已经在做的事情:认识到 Windows 不是 Unix,并在使用它们之前相应地调整示例。
答案3
我很确定你无法编辑 DOS 解析命令的方式。这是其基本编程所固有的。
我能想到的唯一加快速度的方法是保持记事本窗口打开并运行“查找和替换”——将所有单引号替换为双引号。然后从那里复制粘贴到 DOS 中。