1
charlie21 OP 别告诉我我是 linux 遗毒太深阿
|
2
charlie21 OP win 上用不着这个还是怎样 ... 如何配置 win 新系统作为一个开发机,环境变量什么的是最基本的吧
|
3
charlie21 OP 环境变量都配置不清楚怎么好意思说这个是开发机呢? 环境变量 污染,各种图省事就是让环境变量被污染,这是在 linux 下的血泪教训 ( 最后会折腾到 SDK 版本切换、虚拟环境,才罢休 )
|
4
charlie21 OP 像这种玩意,有没有利索一点儿的办法
https://www.javatt.com/p/54073 |
5
jin7 2019-12-15 15:13:16 +08:00
@charlie21 #4 不用这么复杂呀. scoop 默认都给你配好了, java_home 和 path, 这两个就够了. scoop reset jdk11/jdk8 切换 jdk 版本.(具体看你用 scoop 安装的 jdk 的名称)
path 在前面的更优先, 不是后面覆盖前面. |
6
charlie21 OP |
7
jin7 2019-12-15 22:51:05 +08:00
感觉很简单的事情 为啥还要找一套理论来安慰自己 🤔
|
8
jin7 2019-12-15 22:53:06 +08:00
上条瞎回复的.
每个人都有自己的使用习惯. |
9
charlie21 OP 从 MSDos 开始看 ... 对于 Windows 系统的 IT 自动化,脚本
Command shell ( 即 Command Prompt ; 4DOS 是 MSDos shell 的竞争品 ) -> powershell https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands Cygwin -> Git Bash https://hackaday.com/2019/06/10/windows-10-goes-to-shell/ (基本只能编译 C++ 这些需要编译链的东西,是一个 编译用的 toolkit ) https://stackoverflow.com/questions/42888024/git-bash-mintty-is-extremely-slow-on-windows-10-os 玄学 WSL bash https://docs.microsoft.com/zh-cn/windows/wsl/install-win10 # 貌似问题多多 还不成熟(可以从本地电脑配置的角度 使用。如果从软件项目的角度 (比如开发 ruby on rails 并 托管到 Linux 服务器) 希望得到完整的 Linux 支持 (而不需要访问 win 硬盘),建议使用 vagrant 或 docker 并把需要的目录作为卷 挂在进去 即可 ) https://docs.microsoft.com/zh-cn/windows/wsl/faq#what-is-windows-subsystem-for-linux-wsl 速度问题,中间层带来的速度问题 ( git status 的速度在无中间层的时候 反而比较快) 中间层带来的速度问题是很容易理解的:在 dev 的角度 对项目而言 在 win 使用 npm 必然会快于 在 wsl 里使用 npm,在 sysadmin 的角度 对系统维护而言 在 wsl 里 使用 Linux 工具链 必然会 好于 在 Git Bash 里 使用 Linux 工具链 ( 所以 wsl 更像是一个 win 系统管理员 的工具,而不是 一个开发人员的工具。然而 win 系统管理员 已经有 Command Prompt 和 powershell 了啊 ) https://stackoverflow.com/questions/50231989/running-git-commands-on-debian-ubuntu-on-wsl-is-really-slow-for-large-projects # 中间层的存在,有利于 低 IO 操作 速度问题 https://news.ycombinator.com/item?id=18783525 速度问题 https://github.com/microsoft/WSL/issues/4197 速度问题 https://github.com/microsoft/WSL/issues/4387 (还涉及了 当 虚拟机和宿主机不隔离时 会发生的普遍问题,比如 win 作为宿主机可能会去透过中间层去扫描 “虚拟机” 里面的新文件,在 wsl 使用 npm 的时候很明显,因为 所有的 wsl 系统的文件,都是对 win 可见的,它并没有一个自己独立的 不受 win 干扰的文件系统 as 虚拟机和宿主机隔离) https://github.com/Microsoft/WSL/issues/1932#issuecomment-407855346 # 扫描 https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/ https://superuser.com/questions/1110974/how-to-access-linux-ubuntu-files-from-windows-10-wsl # 实际上 按照 “虚拟机和宿主机分离” 的原则,在操作一个虚拟机的时候 大量违反此原则的操作 这是很危险的 (会对宿主机造成拖慢) 对于 虚拟机和宿主机的问题,应该把虚拟机和宿主机隔离。如果做不到隔离:如果 IO 操作很小,那么影响不明显;如果 IO 操作很大,那么 在 wsl 里因为某一个项目需要 处理上万个文件 等于你在宿主机 win 上处理上万个文件,这对宿主机的影响是很大的。(这是 还不如在 vagrant 里开一个虚拟机专门来做,然后 把 它压缩为 zip 再拷贝出来 通过 共享文件夹 给到宿主机 )(更不用提这样的性能对比了:在 win 使用 npm 必然会快于 在 wsl 里使用 npm ) 讨论 https://hashnode.com/post/windows-command-prompt-vs-powershell-vs-git-bash-cjhd5va7t0042mls2w3mnzkax 再次说明 大 IO 操作,最好不要透过中间层,这是常识 ... 上万个小文件 烦死你 ... 无中间层: windows 原生 linux 原生( vagrant ) 有中间层(性能必然极低): wsl。所以 如果追求性能(或不想受到中间层的 拖累),那么 尽量避免中间层。常识。仅仅在少量使用的时候用一用就 OK 了 --- 否则你会感受到虚拟机是怎么侵蚀宿主机的 最后,我的感想是,正如这里说的,wsl 很好,中间层技术很好,但它有它擅长的东西 也有它不擅长的东西,它不擅长的东西就是 涉及到大量文件扫描的命令行操作,比如 git, npm。这时,应该摒弃中间层,使用原生操作 (无论是 win 原生 or Linux 原生) git 操作的速度 在大量文件的 repo 时: vagrant Linux git 优于 win Git Bash ( Cygwin ) 优于 wsl,因为 后者是利用了中间层技术 https://news.ycombinator.com/item?id=18783525 - |
10
charlie21 OP 这个时候,Git Bash 是不可替代的。vagrant 是 比 wsl 在 IO 方面有优势的,wsl 仅仅胜出在 “虚拟机和宿主机不分离” 的方便性 ( 什么时候需要用到这个 ... ? )
|
11
charlie21 OP Windows Defender 拖慢速度
It makes file operations on regular Windows also extremely slow. For example unpacking the Go 1.11 zip which is 8700 files takes a second with my PCIe SSD with Windows Defender disabled. Enable it and the extraction time rises to several minutes. https://news.ycombinator.com/item?id=18783525 better prevents the executable itself from being scanned by real-time https://github.com/Microsoft/WSL/issues/1932#issuecomment-407855346 - |
12
FrankHB 2019-12-28 13:55:16 +08:00
环境变量?看着还就是 UNIX 遗毒。当年折腾系统的不要搞什么半吊子鸡脖 IPC 什么 shell 哪来这么坨破事……
日用要注意的无非是 export 改成 set,$IFS 钦定成分号,$xxx 变成%XXX%,不区分大小写,外加斜杠盘符 cmd 命令行长度限制 8191 之类的破烂。(当然你要倒腾 cygpath 混用什么的另说。) 实现上另外一个差别主要是存在注册表里,刷新起来那个呵呵…… %USERPROFILE%嘛,cmd 没这么幺蛾子。当然你非得用 bash 一样也有类似的,不过我都自己先整好%HOME%了。当然有的不认识$HOME 就很烦,常用的配置都 junction 链过去了…… |
13
FrankHB 2019-12-28 13:58:20 +08:00
你折腾全套开发环境那还折腾什么 Git Bash,上 MSYS2 pacman.conf 里加[git-for-windows]的源直接搞就是了。
|
14
c941968215 2019-12-28 14:30:45 +08:00
|
15
charlie21 OP 几个帖子
15 年 win 党使用 MacBook Pro 16 一个月感受 https://www.v2ex.com/t/632238 xshell 用腻了,微软的又没出,有没有过度的工具? https://www.v2ex.com/t/565879?p=1 git bash 折腾 :为 win10 打造 Linux 终端(非 wsl ) https://juejin.im/post/5bd5a08cf265da0add520772 https://github.com/xnng/my-git-bash cmder with Git for Windows : https://cmder.net |
16
FrankHB 2019-12-30 11:58:09 +08:00
@c941968215 没有。
但有一些相关经问题小结。 https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-operating-systems.md 环境变量冗余的问题其实不难理解:如果不需要依赖现在这样形式的 IPC,而和进程内引用变量一样使用,为什么还用得着强调所谓的环境变量? |
17
charlie21 OP windows env variable
in Windows Control Panel, choose System. Choose Advanced system settings. On the Advanced tab, click Environment Variables. Click New to create a new environment variable. 控制面板 - 系统 - 高级系统设置 - 高级 - 环境变量 win 与 wsl 环境变量共享(实际上很少遇到) https://www.v2ex.com/t/793055 golang goland wsl 2 https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows |