@julyclyde #14 然而你的这个想法和 #3 体现的想法是矛盾的，如果你认为 curl 应该“按文本”输出，那也和 GitHub Web API 输出的是 CRLF 还是 LF 没有关系，因为此时你认为的 curl 的行为会让用户无法感知 HTTP 传输的到底是 CRLF 还是 LF 。

@julyclyde #11 是你对 shell 的期待有误，Unix 风格 shell 的管道完全是二进制的，任何对数据的解读都是程序完成。

Re: “OP 的假设就被推翻了呢”
为什么你会觉得 OP 的假设是自然的？那明明是《我比 GitHub 做 Web API 的员工更懂 HTTP 之口嗨 Windows 用户真时髦》最新一期。

@julyclyde #3 curl 不参与编码解析，自然是 HTTP 给什么就返回什么，否则（若是 curl 参与编码解析的话）你把 curl 传入管道的时候会出现非常糟糕的状况。

@NoOneNoBody #14 您没有理解 PowerShell 的类型系统和传参逻辑，$PSScriptRoot 和 "$PSScriptRoot" 是完全一样的，下面两条命令只有运行效率的区别，没有效果的区别：

cd $PSScriptRoot
cd "$PSScriptRoot"

如果当前脚本的完整路径是 C:\Path with Space\My Script.ps1 ，那么 $PSScriptRoot 是一个字符串，长度是 18 ，内容是 C:\Path with Space ，你写

cd $PSScriptRoot
cd 'C:\Path with Space'
cd "C:\Path with Space"

三句话的效果完全一样，而且和

cd C:\Path with Space

效果不一样，因为后者会被理解为想要传入三个参数，分别是 'C:\Path' 和 'with' 和 'Space'。

而你写的

$var = Split-Path -Parent $MyInvocation.MyCommand.Definition

之后

cd "$var"

和 cd $var 的效果是完全一样的，因为 $var 已经是字符串了，此外 cd "$var" 依然有通配符的问题，正确的写法是 cd -LiteralPath $var 。

@mylovesaber #1 不太确定您的结论是如何来的，但是据我所知使用 CR LF 标记大多数行结尾是 HTTP 规定的，而且是自古以来。

@tyx1703 #38 yan 是 ian 为了方便切分音节的写法而已，拼音字母 y 的使用规则是：音节开头的 i 、ü 改写为 y 、yu 。

iê（拼音规则是 ie ）和 iên （拼音规则是 ian ）的区别在于是否是鼻韵，也就是叶、烟的区别。

根据 OneDrive 的 OneNote 文件大小统计，是 6.65 GB 。但这个数据应该是不准确的，因为很多笔记并不是存在 OneNote 里面。

@momocraft #2 编译器并不是 shell ，楼主的意思是为什么不建立一个和当前 shell 的另一个副本。

MSDN 我告诉你

@1054850490 #4 不确定怎么会出错，因为 Set-Location 当然是支持空格的。根据我的脑波调试，你可以尝试考虑下面两个情况：

1. 你的宏软件没有设置正确，导致 PowerShell 脚本的路径有空格的时候根本不能打开脚本，和脚本的 Set-Location 是否成功没有关系。
2. 你的脚本所在的路径包括中括号 []，这是 PowerShell 通配符之一，因此使用 -Path 会失败。

当然，第二个问题即使现在不是你遇到的问题，也应该避免，在不使用通配符的情况，应该尽量用 LiteralPath 提高性能并减少出错的可能。

Set-Location -LiteralPath $PSScriptRoot

第一个问题，你或许需要在 PowerShell 脚本的名字周围加上双引号，这和你的宏程序的具体机制有关。


@qwq11 #9 不应该假设启动脚本的时候会运行 profile 脚本，因为可以 -NoProfile 。


@LeeReamond #5 $PSScriptRoot 是字符串类型的变量，写成 "$PSScriptRoot" 没有任何效果，因为后者相当于是 [string]::Format("{0}", $PSScriptRoot)，得到的结果必然也是 $PSScriptRoot 自己。

@NoOneNoBody #6 和 PowerShell 当然有关，并不是所有的 shell 都是同一套语法。

取决于你这套系统到底要发挥什么作用，它看起来并不是要取代账本——中国的会计准则要求只用一种本位币，所有非本位币都需要汇率转换后记账，然后每个周期都做汇兑损益的调整。

如果是进销存管理的话倒还可以，你可以把所有非本位币都当成商品，因此任意时刻你的数据库都会显示每个 SKU 和每种货币存量是多少，然后你可以额外设置一个汇率用来显示（仅仅是显示）当前持有的非本位币的本位币价值。只有当你换汇的时候才真正锁定汇率（相当于你卖掉了非本位币）。

@ragnaroks #13 这个理解是错误的，公开的仓库可能是“保留所有版权”的，此时 GitHub 用户只能 fork 它、观看它，没有把它复制到其他网站上的权利基础。如果仓库具有合适的许可证，当然是可以把它复制到其它网站上的。

不太确定你的 alloc 是哪里来的（它似乎不是 C 语言的标准，也不是 POSIX 的一部分）。

取决于你考虑的抽象层级不同，这个问题可能无意义。例如如果你考虑 malloc ，那么它是 C 语言的一部分，不存在“操作系统分配了额外内存”的概念（当然可以猜想，C 语言的实现额外分配了内存，但这个问题处于 C 语言的抽象层面）。

如果你想问像 VirtualAlloc 之类的操作系统 API 导致实体内存的额外开销，这个问题恐怕也是不良定义的，因为操作系统可以采用复杂的数据结构维护内存分配情况，很难说每次调用带来的额外开销都是同一个数。

大概和延迟展开有关，参考
https://stackoverflow.com/questions/61207037/difference-between-dynamic-environment-variables-and-normal-environment-variable

或许你可以说说什么是你发了的“不该发的”，另外除了和支持人员联系没有办法解封。