curl：(7)在ms:坏文件描述符之后连接失败

Question

当我在Mac上的iTerm2终端上执行它时，我的本机curl命令不再工作了。我使用zsh，但是即使在普通bash中，它也不能工作。奇怪的是，当我尝试本地终端应用程序时，相同的卷曲版本都适用于zsh和bash，没有任何问题。下面是当我尝试访问google.com时得到的输出

*   Trying 108.177.15.138:80...
* connect to 108.177.15.138 port 80 failed: Bad file descriptor
*   Trying 108.177.15.100:80...
* connect to 108.177.15.100 port 80 failed: Bad file descriptor
*   Trying 108.177.15.113:80...
* connect to 108.177.15.113 port 80 failed: Bad file descriptor
*   Trying 108.177.15.139:80...
* connect to 108.177.15.139 port 80 failed: Bad file descriptor
*   Trying 108.177.15.102:80...
* connect to 108.177.15.102 port 80 failed: Bad file descriptor
*   Trying 108.177.15.101:80...
* connect to 108.177.15.101 port 80 failed: Bad file descriptor
* Failed to connect to google.com port 80 after 48 ms: Bad file descriptor
* Closing connection 0
curl: (7) Failed to connect to google.com port 80 after 48 ms: Bad file descriptor

当我用Homebrew安装另一个Curl版本时，在iTerm2中执行它没有任何问题。有谁知道问题可能是什么吗？可能是iTerm2的权限问题。

卷曲

curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.5 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

卷曲(HomeBrew)

curl 7.82.0 (x86_64-apple-darwin21.3.0) libcurl/7.82.0 (SecureTransport) OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.2 libssh2/1.10.0 nghttp2/1.47.0 librtmp/2.3 OpenLDAP/2.6.1
Release-Date: 2022-03-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets zstd

Mac OS X

12.3

iTerm2

3.4.15

Answer 1

由于某些原因，当iTerm位于/Applications文件夹中时会出现问题。如果将它移动到/Users/<Your Username>/Applications，它在/Applications以外的任何文件夹中都能正常工作。

另一个有趣的事实是，它甚至足以重命名应用程序以使其工作。例如，iTerm.app不工作，但iTerm 2.app工作得很好。

它可能与iTerm或系统本身都相关。测试版的iTerm也有同样的问题。

我还无法确定发生这种行为的原因是什么，也无法在iTerm存储库中找到相关的票据。