[HN Gopher] Git Bash is my preferred Windows shell
___________________________________________________________________
Git Bash is my preferred Windows shell
Author : indigodaddy
Score : 68 points
Date : 2024-09-10 19:54 UTC (3 hours ago)
(HTM) web link (www.ii.com)
(TXT) w3m dump (www.ii.com)
| sevensor wrote:
| Its biggest advantage is how easy it is to convince corporate IT
| that you need Git for Windows, compared to msys2, Cygwin, or WSL.
| xeromal wrote:
| So Say We All!
| mid-kid wrote:
| This, corporate has been insisting on using ThreatLocker to
| block almost everything from running - Git For Windows is the
| only comfortable environment remaining, at least until I can
| convince them that this is stupid.
| NelsonMinar wrote:
| git bash is very cool. It's based on good ol' MSYS2 and MinGW
| which has always been a nice way to do minimalist Unix-like stuff
| in Windows.
|
| WSL2 is great these days and can interact fine with Windows files
| (despite what this article says). But it's a lot more stuff, a
| full Linux install in a VM.
| exac wrote:
| I just had an IDEA nx plugin crash my editor until it was
| removed because it can't handle WSL directories, so I would not
| say it can interact fine.
| okl wrote:
| Tip: Install the IDE inside WSL2. Should also run somewhat
| faster, especially any operation which has to do with many
| small files, at the expense of a tiny bit of latency in the
| GUI.
| gchamonlive wrote:
| > a full Linux install in a VM
|
| Really? I always thought the subsystem worked translating OS
| calls back and forth without virtualizing an entire machine. It
| sure has an entire OS, kernel and all, but not a virtualization
| layer. Maybe that was the case for WSL but not WSL2?
| akdev1l wrote:
| That was WSL1 and as a result had a bunch of unimplemented
| syscalls.
|
| Microsoft realized trying to keep up with the ever-growing
| list of syscalls on Linux is actually not practical hence
| they opted for the virtualized approach with an actual Linux
| kernel to achieve 1:1 syscall compatibility.
|
| They released that as WSL2. Technically the name is not
| accurate anymore as there aren't any "subsystems" at work
| anymore.
| jborean93 wrote:
| WSL1 used a concept called a pico process [1] and the pico
| driver that is associated with the process is forwarded the
| syscalls to translate to the required NT APIs. WSL2 is a VM
| running through Hyper-V but integrated in a way that mostly
| looks like a normal process. It was introduced to improve
| filesystem performance (on the Linux mounts) and avoid having
| to translate and maintain the syscalls required by Linux [2].
| The tech behind WSL1 is quite fun but WSL2 certainly has
| better compatibility and aside from FS performance between
| Linux and Windows is mostly a positive.
|
| [1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-
| pro... [2]
| https://devblogs.microsoft.com/commandline/announcing-wsl-2/
| dgunay wrote:
| WSL 1 worked that way. WSL2 is a full Linux vm.
| mschuster91 wrote:
| Yep, WSL1 was a translation layer. Extremely awesome but
| unfortunately dog slow for anything involving npm packages or
| large(r) PHP environments as all file accesses would go
| through the translation layer, the Windows filter chain (aka
| virus scanners) and then finally NTFS. WSL2 in contrast is a
| VM, which avoids all the slow paths in file accesses - all
| that Windows sees is a bunch of bulk block I/O to the backing
| file of the VM disk.
| rcarmo wrote:
| On the other hand, running Python, Go and .NET on it was a
| dream. Awesome development environment, and much more
| battery friendly, to the point where I still use it.
| JonathonW wrote:
| WSL2 is "just" Linux running in a Hyper-V VM (with some
| special sauce on top of it to handle things like interacting
| with the filesystem or doing Wayland and X11 graphics, plus
| containerization stuff to allow multiple distributions to be
| installed and run under one VM and one kernel).
|
| WSL1 was a completely different approach, adding a Linux
| compatibility layer to Windows itself. There, you never had a
| Linux kernel running at all-- Linux syscalls would call into
| WSL, which would talk directly to the NT kernel to do
| whatever that syscall needed to do.
|
| WSL1 didn't last very long (still present, but not actively
| being developed)-- turns out that reimplementing one
| operating system on top of another is a Hard Problem (see
| also: Wine). WSL2 avoids this entirely, and also avoids most
| of the impedance mismatches that you get when trying to
| reimplement POSIX on top of NT. WSL2 solved a whole bunch of
| compatibility problems essentially overnight that WSL1 never
| even got around to.
| wnevets wrote:
| > WSL2 is great these days and can interact fine with Windows
| files (despite what this article says)
|
| is that true when using Docker with WSL2?
| lmz wrote:
| Wsl2 mounts the Windows filesystem via 9p in the Linux VM, so
| exposing it to your Docker container is just a config issue.
| bena wrote:
| It's weird, I mostly associate git bash with VS Code because it's
| the terminal I use most often with it.
|
| It doesn't occur to me to use it outside of that context. I use
| the command shell or Powershell depending on what I need to do.
| AdeptusAquinas wrote:
| Huh, didn't know it was basically bash commands for windows - I
| thought it was a faked up linux environment.
|
| I mostly just use ubuntu under wsl2, though the file performance
| across the windows filesystem isn't the best.
| delta_p_delta_x wrote:
| > I like Git Bash because...
|
| > I'm more comfortable with bash commands than CMD or PowerShell
| commands (because I've been using Bourne shell (sh) and friends
| for more than 30 years).
|
| This is the only argument I'm willing to accept, and honestly
| it's the only argument the writer needs, really: un-learning 30
| years of experience to use something else even if the latter is
| objectively superior, would be a pain in the neck for _anyone_.
|
| That being said I believe that seriously attempting to use the
| native tools would help the author understand Windows at a more
| fundamental level.
|
| Also, this _does_ raise a few questions, though--if the writer
| has been using UNIX shells for that long, why are they using
| Windows at all? As I commented elsewhere, why shoehorn the whole
| set of UNIX core utilities and binary utilities onto Windows when
| the latter comes with its own shell, command-line utilities, and
| management tools? More importantly, the author going by the rest
| of their posts (assuming it was the same author) doesn 't strike
| me as the type (i.e. normie, for lack of a better word) to use
| Windows as a daily driver, but they seem to use it all the same.
| Therefore, why not an OS where these utilities feel more native
| and more useful, like Linux or one of the BSDs?
|
| In contrast to the author I've been using and programming almost
| nothing _but_ Windows (with a brief stint on Linux in university
| and now at work, but only for work), and on Windows I use
| PowerShell and if I really need to, CMD.exe (good riddance). As
| far as compilation goes, I use Visual Studio with MSVC and Clang-
| Cl, because they are the _only_ complete development environment
| for Windows--all the others (MinGW, Cygwin, MSYS2) are incomplete
| or worse in some way, or make life harder than necessary in some
| way.
|
| > I have experience using Windows PowerShell (powershell.exe),
| but do not yet have experience using the cross- platform
| PowerShell Core (pwsh).
|
| For the record, functionality between powershell.exe and pwsh.exe
| is almost identical, with some minor differences[1]. Additionally
| they differ in the .NET runtime they were written against (.NET
| Framework 4.8 for powershell.exe, and .NET 7 and later for
| pwsh.exe).
|
| [1]: https://learn.microsoft.com/en-
| gb/powershell/scripting/whats...
| jaaron wrote:
| > why are they using Windows at all?
|
| In my case:
|
| - I had 10+ years of experience in linux/unix development
|
| - Career change to AAA game development which is predominantly
| Windows based
|
| - Day to day do Unreal C++ developing in Windows with Windows
| toolchains
|
| - Still use WSL (and thus bash) for everything else, including
| DevOps related work, cloud/container development work, and
| personal notetaking/productivity via emacs+org-mode.
|
| So, some of us have reasons to co-exist in multiple OS's. I
| tend to write up scripts in Python if I can so that there's at
| least a chance that I can run them in both Windows + Unix
| environments.
| heavyset_go wrote:
| > _Also, this does raise a few questions, though--if the writer
| has been using UNIX shells for that long, why are they using
| Windows at all? As I commented elsewhere, why shoehorn the
| whole set of UNIX core utilities and binary utilities onto
| Windows when the latter comes with its own shell, command-line
| utilities, and management tools?_
|
| I'm a Linux user and developer who writes software targeting
| Windows.
|
| Tools like Git Bash and MSYS2 let me write _one_ set of build
| scripts that work across Windows, macOS and Linux, because all
| of the tools exist on the three platforms.
|
| I don't have a need to understand Windows on a more fundamental
| level, nor do I want to. I just want to meet my users where
| they are at, which is Windows/macOS/Linux.
| delta_p_delta_x wrote:
| Fair point. I've edited my comment to show my impression that
| the author uses Windows as a daily driver, rather than merely
| 'for work', which I think makes the cause for my confusion a
| little clearer.
| wilsonnb3 wrote:
| > Tools like Git Bash and MSYS2 let me write one set of build
| scripts that work across Windows, macOS and Linux, because
| all of the tools exist on the three platforms.
|
| Powershell is cross platform too these days, which makes this
| kind of a moot point.
| scintill76 wrote:
| > if the writer has been using UNIX shells for that long, why
| are they using Windows at all?
|
| Maybe the IT department policies force them to. At least that's
| why I use Windows but do most of my development in an ssh
| terminal to a Linux system.
| chiefalchemist wrote:
| At this point, this should be the industry standard. "Local"
| should be whatever you can SSH into. You can get as much
| hardware as you need, and you don't have to worry about
| anything private (i.e., customer information) and/or
| proprietary being on your lost / stolen laptop.
| kccqzy wrote:
| Perhaps the company is otherwise all in on Microsoft's
| ecosystem. Perhaps they use Outlook, Word, Excel and similar
| apps where the Linux version doesn't exist and the Mac
| version is an afterthought. So IT forces everyone to have a
| Windows system, and then give only the developers a separate
| Linux machine.
| grimgrin wrote:
| what about https://github.com/microsoft/terminal
|
| you use that too right? you better!
| delta_p_delta_x wrote:
| Without question. I was so glad when 22H2 allowed users to
| change the default console host to Terminal; it was the
| single biggest reason why I decided to stay on Windows 10.
| rcarmo wrote:
| I find this interesting because, well, I've used bash on
| Windows for _ages_ (literally before the EMWACs toolkit came
| out for NT 4.0, and I spent many, many years running Cygwin).
|
| I have to use PowerShell, but since it essentially wraps .NET
| services I very much prefer to either write C# (and have vastly
| more maintainable and testable code) or, when removing, invoke
| the APIs using a Unix scripting language. And these days I can
| write nice "portable" (ok, retargetable) binaries inside WSL
| and output a Windows build if I need to...
| wwweston wrote:
| > if the writer has been using UNIX shells for that long, why
| are they using Windows at all?
|
| Desktop applications would probably be the usual reason. It's
| all well and good if your application needs are covered by open
| source, but there's a fair bit of software with value add
| beyond open source that's never received a Linux version and
| WINE doesn't support well enough.
|
| Of course, as you say, then you have the problem of the
| shortcomings of various *nix environments for Windows. MacOS
| can be a great solution... if your app still runs under MacOS
| (currently I'm trying to figure out how to get Fireworks to run
| under a minimal windows or mojave VM).
| jiggawatts wrote:
| "When in Rome, do as the Romans do."
|
| I don't respect the attitude of doing whatever you've always
| done, even when working in a wildly different environment.
|
| Imagine how Linux people would react if there were endless blog
| posts about using VB6 scripts on Linux by running them under
| WINE because "that's what feels familiar."
|
| Sure, for a lark that's hilarious, but not if you share your
| work with anyone else for any reason, even open source.
| delta_p_delta_x wrote:
| > Imagine how Linux people would react if there were endless
| blog posts about using VB6 scripts on Linux by running them
| under WINE because "that's what feels familiar."
|
| Heh, that would be hilarious. In fact someone should come up
| with a Linux distribution that uses NTFS, PowerShell, comes
| with .NET, WINE, and no coreutils and blog about it.
| jiggawatts wrote:
| Hah... I just realised that all of the pieces are now there
| for a "Windows" distro that uses the Linux kernel instead
| of the NT kernel.
| hnlmorg wrote:
| > un-learning 30 years of experience to use something else even
| if the latter is objectively superior, would be a pain in the
| neck for anyone.
|
| It's " _subjectively_ superior".
|
| If there's one thing I can't stand in IT, it's people who think
| their personal preferences are equivalent to impartial facts.
|
| You disagreeing with the author's reasoning is evidence of just
| how subjective this topic is.
| delta_p_delta_x wrote:
| That was poor wording on my part--I should have used the
| subjunctive mood and written '... if the latter _were_
| objectively superior ... '.
| veltas wrote:
| mintty is a great TTY emulator for Windows
| amatecha wrote:
| Oh yeah, I've been using Git Bash for years, it's great. It's
| nice being able to use a set of basic cli utils I'm used to (gnu
| utils) which are bundled in (not sure if it's 100% exhaustive in
| that regard, but still enough for me to do everything familiar).
| And yes, agree with and have benefited from every single bullet
| point TFA mentions!
| indigodaddy wrote:
| mobaxterm has the basic cli tools as well perhaps even more so
| than git bash. For example it additionally has rsync and I
| think mc too
| pauliusj wrote:
| Coming from mac to windows, a big surprise was how ridiculously
| slow printf is on any of the ms terminals (cmd, powershell,
| windows terminal). Git bash does not have this problem when you
| are running something pretty verbose yet want to view the output
| in the terminal
| mid-kid wrote:
| My favourite shell environment for windows thus far is combining
| Git For Windows with scoop[1]. A simple "scoop install git" will
| get the environment installed, and give you a bash shell and full
| access to all sorts of windows-native utilities from scoop. Some
| would say I'd be better off with msys2 or cygwin, but the former
| is meant more as a development environment and lacks misc
| utilities, and the latter has what is possibly the worst package
| manager that is still in use (and generally less stellar
| integration with windows programs).
|
| [1]: https://scoop.sh/
| dietr1ch wrote:
| Same, but NixOS is my preferred Windows too.
| lynguist wrote:
| In this article I learned that _start_ is the equivalent of
| _open_ (from Mac). I didn't know _start_ before.
| righthand wrote:
| Honestly there are so many differences and little things on
| Windows that make using any of the CLIs not worth it. You will
| run up against gotchas developing on native Windows cmd,
| Powershell, git bash, and WSL. I left for Linux a long time ago
| and never have had to look back at the utter mess that is
| Windows. People stay on that platform for what? A graphical menu
| in the corner? Compatibility you don't actually need? Use a real
| shell and OS and save your sanity.
___________________________________________________________________
(page generated 2024-09-10 23:00 UTC)