操作系统:Windows XP,Windows 7 64位.
我们有一些相当庞大的cmd脚本,用于一些日常构建过程.这些脚本产生了许多其他(窗口化)进程.有一个控制cmd脚本,一个小的简单脚本,它启动主cmd脚本.小控制脚本的目的是在主脚本或其任何子节点失败的情况下进行清理.这很容易实现:主脚本及其所有子代都有窗口标题,以唯一标识符开头.当控制脚本确定主脚本及其所有子节点应该已完成时,它使用任务列表来查找任何挂起进程的窗口,通过:
tasklist.exe/FI"WINDOWTITLE eq UniqueIdentifier*"
这在XP中都非常好用.现在输入Windows7 64位.这里,如果主.cmd脚本或任何其他.cmd shell窗口尝试通过它设置其窗口标题
title UniqueIdentifier Followed By Descriptive Text
Windows7 64位请将其他文本添加到标题中(具体来说,"管理员:"或类似名称).不能依赖前置文本.所以现在我们想用
tasklist.exe /FI "WINDOWTITLE eq *UniqueIdentifier*"
但是这个失败并显示错误消息"无法识别搜索过滤器".使用我们的UniqueIdentifier作为后期修复的路线不起作用:命令
tasklist.exe /FI "WINDOWTITLE eq *UniqueIdentifier"
也导致相同的错误消息.似乎微软在过滤器中使用"通配符"的概念并不仅限于使用"*"作为终端字符.哎哟.
任何人都有工作吗？Pslist似乎不允许使用窗口标题进行过滤.
如何将哈希表转换为字符串数组？假设$ l_table是一个哈希表.如果我试试
$l_array = $l_table | format-table
然后$ l_array是一个数组,但是是一个"FormatEntryData"对象的数组.如果我做
[string[]]$l_array = $l_table | format-table
那么$ l_array是一个字符串数组,但字符串都是"Microsoft.PowerShell.Commands.Internal.Format.FormatEntryData".如果我试试
$l_array = $l_table | out-string
然后$ l_array是一个单独的字符串.我已经尝试了很多其他的东西,但没有任何作用,没有手动循环,我真的不想做.
显然,在PowerShell(第3版)中并非所有$null都是相同的:
>function emptyArray() { @() }
>$l_t = @() ; $l_t.Count
0
>$l_t1 = @(); $l_t1 -eq $null; $l_t1.count; $l_t1.gettype()
0
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Object[] System.Array
>$l_t += $l_t1; $l_t.Count
0
>$l_t += emptyArray; $l_t.Count
0
>$l_t2 = emptyArray; $l_t2 -eq $null; $l_t2.Count; $l_t2.gettype()
True
0
You cannot call a method on a null-valued expression.
At line:1 char:38
+ $l_t2 = emptyArray; $l_t2 -eq $null; $l_t2.Count; $l_t2.gettype()
+ ~~~~~~~~~~~~~~~
+ CategoryInfo …世界上为什么_mm_crc32_u64(...)这样定义？
unsigned int64 _mm_crc32_u64( unsigned __int64 crc, unsigned __int64 v );
"crc32"指令总是累加32位CRC,而不是 64位CRC(毕竟,CRC32不是CRC64).如果机器指令CRC32 恰好具有64位目标操作数,则忽略高32位,并在完成时填充0,因此没有使用EVER具有64位目标.我理解为什么英特尔允许在指令上使用64位目标操作数(为了均匀性),但是如果我想快速处理数据,我想要一个尽可能大的源操作数(即如果我有那么多数据,则为64位,尾部较小)并且始终是32位目标操作数.但内在函数不允许使用64位源和32位目标.注意其他内在函数:
unsigned int _mm_crc32_u8 ( unsigned int crc, unsigned char v );
"crc"的类型不是8位类型,也不是返回类型,它们是32位.为什么没有
unsigned int _mm_crc32_u64 ( unsigned int crc, unsigned __int64 v );
？英特尔指令支持这一点,这是最有意义的内在因素.
有没有人有可移植代码(Visual Studio和GCC)来实现后者的内在？谢谢. 我的猜测是这样的:
#define CRC32(D32,S) __asm__("crc32 %0, %1" : "+xrm" (D32) : ">xrm" (S))
对于GCC,和
#define CRC32(D32,S) __asm { crc32 D32, S }
对于VisualStudio.不幸的是,我对约束如何工作几乎一无所知,并且对汇编级编程的语法和语义缺乏经验.
小编辑:记下我定义的宏:
#define GET_INT64(P) *(reinterpret_cast<const uint64* &>(P))++
#define GET_INT32(P) *(reinterpret_cast<const uint32* …有谁知道如何从 powershell 脚本中禁用快速编辑模式？这个问题的“答案”不是答案：
（虽然可以通过编程方式设置注册表设置，但这样做不会影响当前会话）。
我查看了$host、$host.UI和$host.UI.RawUI对象，但找不到任何相关内容。
为了让事情更清楚一点，我不想更改注册表。特别是，我不想更改默认行为。事实上，只有一个脚本，而且实际上只有一个脚本分支，我需要在其中禁用快速编辑。所以我需要能够以编程方式禁用它。或者至少，能够使用命令行选项启动 powershell 以禁用快速编辑。
谢谢。
假设我们有以下目录结构:
~dir00
|-> dir10
| |-> dir20
| |-> file1.txt
|-> dir11
|-> file2.txt
现在,假设~dir00是当前目录.我本来期望这两个命令get-childitem * -recurse
并get-childitem -recurse
产生相同的结果.但是,他们没有.第二种行为是我所期待的.
我正在尝试编写一个小工具库,以便与我们的脚本化进程一起使用.我需要编写的一个工具是复制和备份文件集的工具.作为输入,我得到的东西告诉我什么文件/目录/等.复印.我无法知道用户可能提供的内容.它们可以提供诸如"*"的通配符,它们可以提供文件名,它们可以提供-recurse参数等.输入被馈送到get-childitem.当"路径"只是"*"时,get-childitem行为的不一致是一个大问题.为什么get-childitem在输入-path和-recurse选项时会突然丢弃第一级目录？(请注意,它只会删除第一级目录.) 有什么办法可以防止这种奇怪的行为吗？
现在,它变得更加古怪.如果我们将文件放在根目录中,那么文件结构就变成了
~dir00
|-> dir10
| |-> dir20
| |-> file1.txt
|-> dir11
| |-> file2.txt
|-> file3.txt
然后目录突然不被删除.要重现这一点,只需执行以下脚本:
cd $Env:temp
mkdir dir00\dir10\dir20 | out-null
cd dir00
mkdir dir11 | out-null
echo 'hello world 1'>dir10\dir20\file1.txt
echo 'hello world 2'>dir11\file2.txt
$list1 = get-childitem -recurse
echo 'Results of get-childitem -recurse: '
$list1
echo ''
echo 'Number of items:'
$list1.length …CRC 和类似计算（例如 Fletcher 和 Adler）的主要用途似乎是用于检测传输错误。因此，我见过的大多数研究似乎都解决了检测两个数据集之间小规模差异的概率问题。我的需求略有不同。
以下是对该问题的非常近似的描述。细节比这复杂得多，但下面的描述说明了我正在寻找的功能。这个小小的免责声明旨在避免诸如“当您可以通过我建议的其他方式更轻松地解决问题时，为什么要以这种方式解决您的问题？” - 我需要以这种方式解决我的问题，原因有很多，这些原因与这个问题或帖子无关，所以请不要发布这样的答案。
我正在处理分布式网络上的数据集集合（大小~1MB）。计算是在这些数据集上执行的，速度/性能至关重要。我想要一种机制来避免重新传输数据集。也就是说，我需要某种方法来为给定大小的每个数据集生成唯一标识符（UID）。（然后，我将数据集大小和 UID 从一台机器传输到另一台机器，并且接收机器仅需要根据 UID 请求传输数据（如果本地还没有数据）。）
这类似于使用 CRC 检查文件更改和使用 CRC 作为摘要来检测文件之间的重复项之间的区别。我还没有看到任何关于后一种用途的讨论。
我不关心篡改问题，即我不需要加密强度散列。
我目前正在使用序列化数据的简单 32 位 CRC，到目前为止，这对我很有帮助。但是，我想知道是否有人可以推荐哪种 32 位 CRC 算法（即哪个多项式？）最适合最大限度地减少这种情况下的冲突概率？
The other question I have is a bit more subtle. In my current implementation, I ignore the structure of my data set, and effectively just CRC the serialized string representing my data. However, for various reasons, I want to change my CRC methodology as follows. Suppose my top-level …
我有一个 Visual Studio“解决方案”，其中包含一个 Web 应用程序项目（以及一些其他项目）。Visual Studio“典型”设置似乎坚持认为二进制文件的输出目录位于项目源目录的根目录中。特别是，每次打开Web应用程序项目时，Visual Studio都会重置IIS虚拟目录的物理路径以指向项目目录。
这在很多层面上都是有问题的：
将 Visual Studio 解决方案中的所有项目配置为构建到干净地放置在源代码树外部的某个子目录中的 bin 目录是非常可能且非常容易的。确保 Web 应用程序构建将所有内容干净地放置在此目录中也很容易。配置 IIS 虚拟目录以指向此构建输出目录也很容易。然后，Visual Studio 未经通知、未经请求，通过任意更改精心配置的虚拟 IIS 应用程序的物理目录，使其指向源代码树的中间，从而搞砸了这一点。
如何才能阻止这种疯狂的行为呢？即，如何防止 Visual Studio 在每次打开 Web 应用程序项目时自动重新设置虚拟 Web 目录的物理路径？
这个问题在 Stack Overflow 上已经被问过很多次了，但我没有看到真正的答案：
对该问题的回答（IIS8.5 自动更改物理路径属性）仅表明如何控制 Visual Studio 进行重新指向的顺序。
这个问题和响应（Visual Studio在解决方案打开时创建IIS虚拟目录）只是确认了该行为。
对这个问题（打开项目更改 iis 设置）的回答是完全错误的，一些评论也是如此。
这些问题（Visual Studio 2012 更改 IIS 应用程序目录而不询问）、（Visual Studio 更改本地 IIS 配置）没有任何答复。
基本上没有人说做不到，但也没有人给出像样的解决方案。
在C#中,以下是有效的语法,这是有道理的:
string[] v = {"a","b"};
但现在考虑一下.假设我们定义
void method(string[] p) {...};
那么以下内容无效:
method({"a","b"});
这与上述不一致.
是否有技术原因阻止此处的方法调用是有效的语法？也就是说,语法的解释是否存在歧义？或者是否存在内存管理或持久性问题导致无法实现？
编辑:Eric Lippert在下面的回答很有意思 - 但它回答了设计的"原因",我实际上没有问过(事实上这个问题最初是关闭的,因为看起来好像我在问他的那种答案).
LB的答案可能确实不是最初的"原因"这种语法是不允许的(根据Eric L.评论).然而,截至目前,LB的回答肯定是正确的技术原因,为什么不允许这样的语法,这实际上是我问的问题,所以我选择LB的答案是正确的(尽管老实说这是一个很难的选择. ..).