C 更好的命令行界面

我开发了一个可以缓存多个包的应用程序。此应用程序的CLI界面如下所示

submit -z pkg1.zip -c pkgChecksum1 -t pkgType1 -s pkgSize1 -z pkg2.zip -c pkgChecksum2 -t pkgType2 -s pkgSize2 

submit --script an.xml

因此，本文提交了两个包pkg1.zip和pkg2.zip，它们分别具有校验和pkgChecksum1和pkgChecksum2，包类型为pkgType1和pkgType2，大小分别为pkgSize1和pkgSize2

我们还向应用程序提供基于XML的输入，如下所示

submit -z pkg1.zip -c pkgChecksum1 -t pkgType1 -s pkgSize1 -z pkg2.zip -c pkgChecksum2 -t pkgType2 -s pkgSize2 

submit --script an.xml

其中a.xml是

<?xml version="1.0" encoding="ISO-8859-1"?>
<packages>
<package name="pkg1.zip" checksum="pkgChecksum1" type="pkgType1" size="pkgSize1" />
<package name="pkg2.zip" checksum="pkgChecksum2" type="pkgType2" size="pkgSize2" />
</packages>

这是第一个CLI方法的功能等价物

---

我们正计划使其更加用户友好，是否有改进的想法？

您应该为CLI中的各种参数提供长选项和短选项。 比如说

submit --package pkg1.zip --checksum pkgChecksum1 --type pkgType1 --size pkgSize1 --package  pkg2.zip -checksum pkgChecksum2 --type pkgType2 --size pkgSize2

---

是否需要所有选项？或者是否存在类型、大小和校验和的默认值？ 如果没有默认值，您可以去掉标记，只需要四个一组的参数

submit pkg1.zip pkg1Cksum pkg1type pkg1sz pkg2.zip pkg2Cksum pkg2type pkg2sz 

本例中的另一个选项是使用标记，但提示用户缺少值

如果存在默认值（是否可以自动计算校验和和大小？），则允许选择覆盖：

submit pkg1.zip -t pkg1type pkg2.zip -t pkg2type -s pkg2szOverride

另一个可能有用的选项是

——现有缓存，它附加到现有文件（如果不存在则创建）。这会让用户将其分成几个部分
可管理命令行

   submit -a mycache pkg1.zip -t pkg1type -s pkg1sz
   submit -a mycache pkg2.zip -t pkg2type -s pkg2sz

根据评论，还有一个选项：

  submit -x pkg1.zip:2034 0x232D -y pkg2.zip pkg3.zip:123

其中-x、-y等是不同支持的“类型”的标志。因此，此行提交了大小为2034的pkg1，类型为X，以及一个校验和；类型为y的pkg2，未指定大小或校验和；和大小为123的pkg3，没有指定类型或校验和。
很难说您应该做什么。这取决于谁是应用程序的目标受众。两种可能的选择：

GUI界面，适用于不知道/害怕使用CLI的用户
交互式CLI，与此类似：
我想到的另一个选择是：

submit pkg1.zip:type:2034:0x232D     pkg2.zip:type2:2034:0x232D

我认为问题在于submit可以为每个参数管理多个选项，因此一次添加每个选项可以使界面更简单。重新记录每一个的类型、尺寸和尺寸应该不难。毕竟，似乎所有参数都是强制性的。这样，就不可能将一个包的选项与另一个包的选项混为一谈。
为什么XML中有一个未关闭的
标记？@svick:更正了这一点。谢谢。不需要校验和、类型和大小。没有默认值。参数没有顺序。因此，用户可以首先提供包名、大小、类型，然后提供校验和。这就是为什么我们保留标记来标识它们。至少，我不需要在包名称上使用-z，因为它们是必需的。校验和是包含校验和的文件，还是类似于0x1ab2的字符串？允许的类型是否为限制集？校验和是一个crc32哈希，类似于您提到的0x1ab2。该应用程序由超级用户使用，他们更喜欢CLI:）。交互式CLI很难自动化。这就是为什么交互式CLI是一个错误的选择，如果它是唯一的接口。但是，如果您已经有了其他易于自动化的接口，那么添加交互式CLI可能是一个好主意。但我喜欢你的想法，即为自动化和人工输入提供单独的界面。谢谢