[HN Gopher] Git Bash is my preferred Windows shell
___________________________________________________________________
Git Bash is my preferred Windows shell
Author : indigodaddy
Score : 203 points
Date : 2024-09-10 19:54 UTC (1 days 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.
| jfdjkfdhjds wrote:
| gitshell is a opinionated msys2 install. they just picked one
| of the variants and removed the package manager.
|
| this could serve as a wake up call to msys2 maintainers. every
| time i install it, i have absolutely no f ideia what the 6
| variant icons mean and I couldn't care less since all of them
| mostly work... (thankfully I don't use windows much to reach a
| point the difference matters?) it's very overdue they just pick
| one and keep the others with better names in a compatibility
| folder or something. also, a better name.
| sevensor wrote:
| If you're not sure, you probably want UCRT64. At any rate I
| used it to pull a rabbit out of a hat at work by building
| some software with it that didn't have an official windows
| build.
| 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.
| jamesfinlayson wrote:
| I feel similarly - I first learned about the shell with Linux
| and all my career has been with Linux, but at home I use
| Windows. I am making an effort to be better at PowerShell but
| if I just want to do something quickly, I already know how to
| do it with bash and I just want to get on with my day.
| 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.
| metadat wrote:
| Powershell had potential, but it didn't pan out. It's
| annoying and very challenging to remember all the one-off
| flags.
|
| With bash, you only need to learn 10 or 20 short commands
| and a few flag variants, over a gently long period of time.
| Then you're all set for 97% of cases likely to be
| encountered.
| ants_everywhere wrote:
| I just wrote a two line bash script to process some large
| csv files that Python/Pandas were taking far too long to
| process [0].
|
| A lot of people (myself included) tend to underestimate
| the power of the heavily optimized GNU utilities and the
| ability to manipulate them with bash.
|
| [0] It was two lines for readability. It could have
| easily been a single line.
| partdavid wrote:
| This is the opposite of how I see it. There's really
| nothing universal about flags, especially short ones, in
| different random utilities (what's -n mean? -f? file,
| filter or force?). Whereas in Powershell since there
| actually is some standardization, your knowledge about
| what -WhatIf or -Verbose do is actually pretty
| leverageable. And more powerful with the ability set
| default parameters and so forth. And the discoverability
| and help in Powershell is also standardized.
|
| So I get why unfamiliarity would make it not worth it to
| switch from whatever shell you prefer, but I don't think
| I can see your point about flags.
| doubled112 wrote:
| Powershell on Windows is great because there's a module for
| everything. I'd rather parse structured data.
|
| Powershell on Linux isn't worth is because I end up having
| to parse everything as text anyway, completely negating any
| benefit I can come up with. It doesn't feel as natural as
| the *nix tools to me.
| partdavid wrote:
| For what it's worth, I've had the opposite experience,
| maybe because I work in a different domain. Personally, I
| still think using Powershell functions and treating lines
| as string objects is an improvement over bash and its
| mini-languages, anyway; and most standard Unix commands
| have Powershell close equivalents. Some Powershell
| expressions might be abstruse but so is, say, awk; but
| when you've learned awk you only know awk; whereas the
| Powershell technique you used (calculated fields in
| select-object, for example) is permanently useful. I do
| spend a lot of my time with various random APIs so
| Powershell is pretty joyful compared to (say) curl/jq or
| yq-ish stuff. There was a real adjustment period, of
| course, getting used to a new shell; but it was the best
| thing about my experiment with Windows (discovering a new
| shell that I now use on my Unix-like systems, because I
| did not end up wanting to adopt Windows).
|
| So I'm curious what kinds of things you mean when you say
| you have to parse everything as text anyway. I suspect
| you've needed to a lot more of those kinds of tasks than
| I have.
| doubled112 wrote:
| Powershell's CSV, XML and JSON handing is my favourite
| Powershell feature. Completely agree with you that it
| beats a *nix shell and things like jq. If I was
| interacting with those all day I might be convinced to
| use it more.
|
| What I mean by parsing as text was more about actual
| commands.
|
| I wasn't expecting 1:1, but as an example, let's say I
| wanted to get a list of local users on a machine.
|
| On Windows I can use "Get-LocalUser". It returns an
| object with properties you can filter, output with a
| format, etc. Basic stuff that saves me doing any
| thinking. I like that. It's amazing how column titles add
| to the user friendliness.
|
| On Linux, Get-LocalUser doesn't exist, so I could run
| something like "getent passwd". It's only option is to
| return a screen of text. There's no structure yet, just
| lines and colons. Now I can (even though I shouldn't)
| grab fields with _cut_ , or _awk_ , and filter with
| _grep_ , and maybe output something pretty at the end
| with _column_. What does the 5th column mean again?
|
| So on the Linux side, I've never been very motivated to
| use it, since I often have to fall back to old ways
| anyway.
| partdavid wrote:
| Thanks, that makes a lot of sense. I can see a lot of
| similar cases especially for sysadmin things (systemctl,
| ifconfig, etc.).
|
| One thing that was nice about my adopting Powershell as
| my daily shell is that for the most part, I _could_ just
| use the same shell utilities as usual:
| getent passwd | cut -f6 -d':' | sort | uniq -c
|
| Like, there's no problem running that in powershell. I
| know people have talked about "mixing" strings and
| objects but, I have to say that for me I've rarely run
| into a problem with it?
|
| As you learn you can do a little more. Maybe you learn
| that group (group-object) can be used instead of the two
| commands at the end: getent passwd | cut
| -f6 -d':' | group
|
| And for me, the nice thing is that when you learn
| something like that, it's leverageable across all your
| cases. You learned something about your tool, not just
| about the passwd file.
|
| Is this better than bash? I don't think it's worse:
| getent passwd | %{ ($_ -split ':')[5] } | group
|
| But then you might notice that your data is a CSV (C for
| colon in this case) and you might leverage some of the
| CSV-handling which works well in Powershell:
| getent passwd | convertfrom-csv -del ':' -h
| 'user','pwd','uid','gid','comment','home','shell' | group
| -prop 'shell'
|
| Now you're cooking with structured data again. I think
| familiarity makes this kind of thing come naturally. And
| since these commands are pretty discoverable, because
| they're more consistent, and tab-completion and command-
| line editing are so much better than bash. It's easy to
| see how the above can be made terser by stashing it into
| utility function or a hashtable in your profile (e.g. so
| you could do "getent passwd | fields passwd" or something
| like that.
|
| Now, I'm not going to tell someone it's worth the growing
| pains and adjustments to switch. It's like switching
| keyboard layouts. And matters of taste might turn you
| off, understandable. But for me there have been real
| benefits, and on its merits, I do think it makes a better
| shell. And it would be nice (from my perspective) if the
| community did some more work around these use cases and
| making them nicer for people.
| doubled112 wrote:
| You learn all of that, find yourself logged into somebody
| else's server, and you only have bash again.
|
| Sorry, trying to be funny, not dismissive.
|
| I think shells in general could use some rethinking,
| considering they still feel pretty 80s.
|
| Familiarity (or my lack of) is likely a big reason I'll
| miss the obvious.
|
| Zsh fills in many of the same checkboxes while being
| similar enough you don't lose muscle memory when you find
| a bash shell somewhere.
|
| Maybe someday something else will take over. Windows has
| the advantage there, for sure.
| partdavid wrote:
| Oh, it's not dismissive at all. It's not just a real
| consideration, it's an overriding one. I switched my
| "daily driver" shell to powershell but I still write
| CI/CD scripts in bash, and docker entrypoints, and cloud-
| init userdata, and utilities, because it's niche enough
| to be too much to ask my coworkers and community folks to
| also switch.
|
| I do wonder about the muscle memory thing. I think having
| to create scripts in bash keeps my hand in enough that I
| won't lose it too badly. At least I hope so. I compared
| switching shells to switching keyboard layouts; something
| I also did, and something where it's been some effort to
| retain enough muscle memory to not completely flail when
| presented with another computer.
| notpushkin wrote:
| > Powershell on Linux isn't worth is because I end up
| having to parse everything as text anyway
|
| Does it at least integrate with DBus a bit?
| rastignack wrote:
| > Powershell on Windows is great because there's a module
| for everything. I'd rather parse structured data.
|
| It's also really slow for text processing, borderline
| unusable
| heavyset_go wrote:
| Bash + coreutils/busybox/etc are everywhere, I can take
| them for granted. I will have to jump through hoops to
| deploy Powershell outside of Windows.
|
| I also have no desire to use Powershell when I don't need
| to.
| dangus wrote:
| But they aren't on windows, so they can't be taken for
| granted there. You have to install git bash on windows.
|
| What's the difference between installing git bash on
| windows and installing powershell on Mac/Linux? I would
| argue that there is none.
|
| And obviously it's fine that you don't want to use
| PowerShell, I don't want to use it either. But personally
| I _also_ dislike git bash on windows. It doesn't feel
| like it belongs there, just like powershell doesn't
| really belong on Linux /Mac.
|
| If I had to write a build script for all three platforms
| I would just write them for their native environments. I
| wouldn't be all that willing to add another tool to be
| installed just to save myself the effort of simple build
| script.
| heavyset_go wrote:
| I can run an MSYS2 installer on a Windows VM once and be
| done with it. I will have to roll my own containers, for
| example, if I want to use Powershell elsewhere, versus
| just using vanilla or vendor-provided images.
|
| For my use case, I don't see the need to bend my builds
| around Powershell just to use Powershell. This plays into
| my other point about not wanting to dig into Windows
| fundamentals when I don't need to.
|
| > _If I had to write a build script for all three
| platforms I would just write them for their native
| environments. I wouldn't be all that willing to add
| another tool to be installed just to save myself the
| effort of simple build script._
|
| This was my initial approach, but it became too much work
| to maintain separate build systems, especially when it
| came to making changes over time. One change becomes
| three, along with three new opportunities for things to
| break in three separate ways.
|
| For what I'm doing, moving to Unix-y toolchains
| simplified builds and made it much easier to reason about
| it.
| dangus wrote:
| I totally get that your solution works for you and that
| is fantastic. I'm only questioning the pure logic behind
| it when you strip away opinion/preferences.
|
| You picking one OS that you're okay with modifying but
| the other one you're not. If we inversed that preference
| and said that I'm willing to modify my Linux containers
| but unwilling to install software on my Windows VM, the
| logic is the same.
|
| By the way, Microsoft publishes Linux images that already
| have PowerShell pre-installed.
|
| https://learn.microsoft.com/en-
| us/powershell/scripting/insta...
|
| So, technically, if your build scripts were 100%
| PowerShell you could have it where both Windows VMs and
| Linux docker images could be unmodified.
|
| Since your build scripts sound overly complex, they could
| possibly benefit from a scripting language that's got
| support for objects and object data pipelines, more
| advanced error handling, and more advanced object parsing
| than tools like sed and awk.
|
| Just playing "devil's advocate" here, the logic checks
| out.
| MichaelRo wrote:
| >> What's the difference between installing git bash on
| windows and installing powershell on Mac/Linux? I would
| argue that there is none.
|
| Big, big difference. My Windows laptop is basically a
| terminal to the Linux development server. I can install
| anything (within reason) on Windows, can't install shit
| on the Linux server unless I beg the IT admin for days
| and eventually he just says "no". He did install the "mc"
| (Midnight Commander) utility on it though and made my
| life like 100x easier. If MC were bundled with git bash,
| that would be something I would cheer for.
|
| And yeah, I use git bash too on Windows. For accessing
| the Linux shell through ssh when I remotely connect to
| the server and for convenience locally. Main workhorse
| are the "less" and "grep" utilities to examine logs. What
| am I goint to use otherwise, Notepad?
| dangus wrote:
| Just because you aren't familiar with Windows commands
| doesn't mean they don't exist.
|
| Microsoft actually gives you SSH without the need to
| install git bash.
|
| https://learn.microsoft.com/en-
| us/windows/terminal/tutorials...
|
| grep on windows is Select-String
|
| https://learn.microsoft.com/en-
| us/powershell/module/microsof...
|
| More command on windows:
|
| https://learn.microsoft.com/en-us/windows-
| server/administrat...
|
| What will you use to view logs, Notepad? Well, you could
| use the #1 most popular text editor that Microsoft
| happens to develop, VSCode. Or a wide array of Windows
| GUI software that isn't available on Linux, like
| Notepad++.
|
| The fact that your IT department has those specific
| policies in place and is inflexible with your developers
| isn't really relevant to this discussion. The truth is
| that if you wanted PowerShell on Linux it is trivial to
| install. Microsoft even publishes Linux images that
| already include PowerShell.
| grepfru_it wrote:
| Git bash has a terminal emulation problem. It's fixable, but
| annoying problem that breaks tools. I recommend Cygwin or
| more recently WSL.
|
| YMMV
| 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.
| makeitdouble wrote:
| > "When in Rome, do as the Romans do."
|
| Parent is obviously choosing the "Veni Vidi Vici" side of the
| coin. If they can pull it off, why not ? It's their machine
| after all.
| devnullbrain 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."
|
| Alternatively, we could ask why the POSIX-sphere produces
| enough power users impassioned to, interested in and capable
| of enabling their pet projects on a closed and hostile
| platform for blog posts like the OP's but the reverse does
| not.
| 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 ... '.
| hnlmorg wrote:
| Not just poor wording but I think you misunderstood the
| authors context too. Some of his comments were comparing
| git bash to other POSIX layers like WSL, rather than Bash
| vs PowerShell.
| delta_p_delta_x wrote:
| > I think you misunderstood the authors context too
|
| This I did not. The post was about Git Bash as a command-
| line shell for Windows and everything it entailed, I
| understood that and that's why I wrote the paragraph that
| followed.
|
| I was limiting the scope of my comment to the author's
| familiarity on Bash versus CMD or PowerShell because I
| considered that the cornerstone argument of the entire
| post. Everything else that the author mentions is
| expected by default in a *sh-type shell on a Unix-like
| OS; there's nothing special there. People wouldn't blog
| about being able to use `grep`, `ls`, etc on Linux; it's
| just everyday business.
| hnlmorg wrote:
| > > I think you misunderstood the authors context too
|
| > This I did not. The post was about Git Bash as a
| command-line shell for Windows and everything it
| entailed, I understood that and that's why I wrote the
| paragraph that followed.
|
| I literally just said he wasn't just comparing Git Bash
| with Powershell though. So you can't have understood
| their context if you took Powershell to be the
| "cornerstone".
|
| It's a bit of a muddled blog because he is constantly
| switching focus between "Git Bash" (the package /
| distribution; whatever term you want to describe it as)
| and Bash.exe (the shell).
|
| There are a lot of the comparisons are with things like
| WSL, for example when he discusses the underlying file
| system. And when he talks about the ease of installing
| and keeping things up to date. None of that was directed
| at Powershell specifically, nor even at all.
| delta_p_delta_x wrote:
| I think you're misunderstanding my comment.
|
| I said the cornerstone argument for their blog was 'they
| were familiar with Bash, so they don't use the shells
| that come with Windows', not 'they are comparing Bash
| with PowerShell'.
|
| Given that everything else is detailing what about Git
| Bash is familiar, which as far as I am concerned is
| everyday business. The author discusses things like
| Unicode and the other GNU coreutils. Again, this is what
| you'd _expect_ on a Unix-like.
| hnlmorg wrote:
| > I said the cornerstone argument for their blog was
| 'they were familiar with Bash
|
| That wasn't the cornerstone either. That was just the
| only argument of theirs you chose to accept:
|
| I quote:
|
| > This is the only argument I'm willing to accept,
|
| I do understand your point of view, I honestly do, but
| you're not being charitable to the author nor genuine
| when discussing it with me.
| amaccuish wrote:
| > I literally just said he wasn't just comparing Git Bash
| with Powershell though
|
| That's great that you think that, maybe delta_p_delta_x
| had a different takeaway. Why do you believe your opinion
| about what the cornerstone of the article is to be fact?
|
| > If there's one thing I can't stand in IT, it's people
| who think their personal preferences (or opinions) are
| equivalent to impartial facts.
| hnlmorg wrote:
| I appreciate what you're saying but the author literally
| named the software they were comparing. WSL was
| specifically mentioned, by name, in some examples.
|
| That's not subjective opinion of mine because it's
| literally printed like that on their site (you can read
| it for yourself too. It's the same site for everyone)
| wilsonnb3 wrote:
| In principal I agree with you but if there is one commonly
| used technology that is actually objectively inferior to the
| myriad of replacement options and is only still around
| because its been ubiquitous for decades, its bash.
| hnlmorg wrote:
| "Inferior" and "superior" are broad terms.
|
| Architecturally speaking, Powershell (and other modern
| shells) are a huge improvement. But that's only half the
| story.
|
| Syntax wise, I find powershell a step backwards. It's too
| verbose. Bash is too far the other way but if I'm using a
| REPL then I'd rather have something too terse than too
| verbose. Granted that's just my preference but we are back
| to subjective arguments.
|
| Ubiquity is another consideration. If you're writing
| multiplatform bootstrapping code then Bash is a better
| option than Powershell. And we are back to subjective
| arguments again.
|
| Broad terms are only true if you can agree on a specific
| context. But then they're no longer broad and instead
| you're relying on everyone agreeing to that narrow
| subjective definition.
| CrimsonCape wrote:
| As a thought experiment, Get-ChildItem is a poor choice
| of API. Instead, it should really just be Get<T> <args>
|
| Get<Folder> -path "C:\Users\Me\My Documents"
|
| Would return a match of type <Folder|nil>
|
| similarly
|
| Find<Folder> -path "C:\Users" -match "Me"
|
| Would return a match of type <Folder[]|nil>
|
| or
|
| Find<Any> -path "C:\Users" -match "Me"
|
| Would return a match of type <Any[]|nil> where Any is
|
| File|Folder|DotFile|Symlink
|
| In as few lines I provided a clean API which
| unfortunately doesn't exist in any one language but
| rather borrows from multiple languages, <T> representing
| C# generic types, File|Folder representing an F# union
| sum type, Any type a la Rust.
| throwaway2037 wrote:
| What is better than Bash shell? What I like most about it:
| It exists on every single Linux box that I use, so I can
| always run my Bash-specific shell scripts.
| addicted wrote:
| I used bash in college and then didn't use it for around 5
| years. And then I used powershell.
|
| And bash is still a lot better as a shell language. Powershell
| commands are long and annoying. If you remember all the aliases
| (most of which are annoyingly bash commands but hardly behave
| that way) then the parameters are long and annoying.
|
| Stringing commands together requires too much API digging
| because objects mean you need to run a variety of incantations
| on the results to know what members you need to pull out and
| what data format they have, etc. in Bash it's always strings
| and if you know a couple of useful string manipulation commands
| such as cut, that you probably know anyways for other reasons,
| you can get by with stringing most commands fairly trivially.
|
| Powershell OTOH is a lot better when I'm trying to write an
| actual reusable script. But at that point why wouldn't I just
| use something like Python anyways (or if it will be associated
| with a front end repo I will often just use nodejs since it's
| definitely installed). Python has much more usable comparison,
| control flow, etc operators, much bigger libraries, better
| multi OS compatibility etc.
|
| The only advantage really is using powershell
| commands/applications, so sometimes I will write my scripts in
| Powershell.
|
| But in Linux I will also sometimes write my scripts in bash for
| the same reason, so it's not really an advantage inherent to
| powershell, but the fact that it's the "standard" of the OS.
|
| I do like Powershell, but the problem with it is that it tried
| to be both a great scripting language and a great shell
| language, but the things that make it a good scripting
| language, such as verbose naming, objects, etc make it a worse
| shell language than shell languages designed to be shell
| languages first, and the things that it does to make it a
| useable shell language, makes it a worse scripting language
| than other scripting languages.
|
| On average it may be the best language across all environments
| and use cases. The problem is that for any specific environment
| and use case it's rarely one of the better languages.
| tdeck wrote:
| This is a very succinct dissection of the problems but I will
| add one more: PowerShell's frustrating behavior where any
| return value of a function call is part of the enclosing
| function's return value if not explicitly swallowed. I
| understand what they were going for by analogy with other
| shells here, but in my opinion in a language like PowerShell
| (with actual return values) this is unintuitive and makes it
| really easy to introduce bugs. The whole object pipeline
| thing they were going for feels like an evolutionary dead end
| that we shouldn't be saddled with.
| partdavid wrote:
| I agree, this is a place where the desired features are in
| tension. I will say that it took me a while to find it, and
| I don't find it limiting now that I understand it, but it
| was a real gotcha when I encountered it.
| partdavid wrote:
| I'm not sure I understand your point regarding having to look
| at the output of commands to know how to use them. At least
| with Powershell you have tab-completion suggesting your
| object members; you have to at least look at whatever flavor
| of semi-parsable text is coming from your command in bash to
| use cut or awk or whatever on it (and the semantics of what
| you're looking at are not discoverable, so you're likely to
| have to some API digging of your own). 'cut' and the like is
| sadly fragile for a number of reasons, and you generally
| won't discover them in advance (e.g. when the date "field"
| starts containing a year, sizes overflow or start being
| indicated with human-readable abbreviations after a
| threshold, which is exactly the sort of thing you can't tell
| by inspection). And bash's failure modes are really sharp.
|
| To be honest, something like $titled = gci
| *.md| ?{ (gc $_)[0] -like '# *' }
|
| seems short and less error-prone than the bash equivalent.
| Not sure what it would be. Something like
| titled=(); for file in *.md; do if head -1 "${file}" | grep
| -sq '^# .*'; then titled+=("${file}"); fi; done
|
| I think there's a lot of little gotchas in there, and not a
| little "API digging" for options, though it's simple in
| concept.
| tdeck wrote:
| > you have to at least look at whatever flavor of semi-
| parsable text is coming from your command in bash to use
| cut or awk or whatever on it
|
| Having to parse things is definitely a pain, at least until
| you get good at it. But the critical thing is that all the
| output is right there on the screen, and often in a format
| that's at least somewhat designed to be parsed. In
| PowerShell you have to go diving through the object
| hierarchy. That would be OK I guess if things were
| intuitive and the help and documentation were great but
| that's often not the case. And often the API semantics are
| designed for a different language altogether (C#) and the
| things you have to do to consume the API in PowerShell are
| ugly.
| lenkite wrote:
| Your "diving through object hierarchy" has a _consistent_
| command called "Get-Member". Not the same where you need
| to dive through several hundred text output structures
| for different commands and/or read man page options. I am
| sorry, but your statement is factually false.
|
| The simplest technique for analyzing the objects that a
| command returns is to pipe the output of that command to
| the Get-Member cmdlet. The Get-Member cmdlet shows you
| the formal name of the object type and a complete listing
| of its members.
| drums8787 wrote:
| I make a living writing software that's hosted on Windows. I've
| never felt as comfortable with the command line options on
| Windows as I do with macos/Linux. Git bash with vim was such a
| relief.
|
| It's an idiosyncratic mix of ergonomics and habit probably. I
| don't really care since I get the job done efficiently (more so
| than a lot of "Windows natives" I observe).
| ethagnawl wrote:
| In my experience, it really does come down to the ergonomics:
| the cursor, the casing, the forward slashes, whatever key
| combo is required to paste (shift+insert?).
|
| I'm sure PowerShell and friends are great but it's enough of
| a shift to not be worth the learning curve if it's an
| environment you're just dipping into to do the bare minimum
| required to make something work.
| fsckboy wrote:
| > _if the writer has been using UNIX shells for that long, why
| are they using MSWindows at all?_
|
| MSwindows is posix, why not?
|
| windows supports tons of software that is not available on
| unix. People have to work with other people, spouses,
| university colleagues, whoever, maybe those people use
| MSWindows
| ethagnawl wrote:
| > why are they using Windows at all?
|
| I'm a back-end developer/DevOps/Linux sysadmin who runs a small
| consultancy. I've been brought into a few Windows projects --
| primarily on-prem/interactive installations. The past few
| occasions because the client was using Windows because the FE
| was being built using TouchDesigner. (Not sure it's still
| Windows-only but it was previously.)
|
| So, it happens. Clients have many reasons for running Windows
| and depending on the project and its needs, I may accept the
| requirement or not. To use a recent couple of examples, if I
| can use GitBash, Docker, WSL and Python locally, then I'll
| probably take it on. If they're set on using PowerShell, C# and
| Azure, I'm probably out.
|
| That all being said, if the project is interesting or high
| profile enough, I'll jump through whatever hoops are put in
| front of me.
| sytelus wrote:
| PowerShell should be taught in university as example of how
| poorly designed system devoid of taste and aesthetic looks
| like. It's an ugly monstrosity that makes me puke every time I
| try to use it. The only reason some people might like it is
| because they have been tortured by Windows defaults for many
| years and finally they got used to this utter mediocracy.
| delta_p_delta_x wrote:
| It'd be good if you could actually justify why you think
| PowerShell is inferior to UNIX shells, instead of going on an
| impassioned but unsubstantiated rant.
| keithnz wrote:
| I think powershell is actually really well designed. Some of
| the syntax leaves a bit to be desired, but other than that I
| think it's really good. What do you think is poorly designed?
| devnullbrain wrote:
| > Some of the syntax leaves a bit to be desired
|
| That's quite poor design for a shell! It's like saying an
| OS is well designed except the mouse and keyboard input
| leaves a bit to be desired - because they were designed for
| scripting first and users second.
| throwaway2037 wrote:
| Years ago, I had a teammate that was always pushing me to try
| Cygwin. While I love a UNIX shell, Cygwin just felt... weird.
| The whole paths thing really turned me off. What pushed me to
| try it? He said to me: Why bother learning two shells (UNIX +
| DOS), when you can just use one (UNIX) everywhere? I couldn't
| find a good argument against it. I tried Cygwin, and,
| eventually (never?) got over the weirdness of paths.
| irunmyownemail wrote:
| "shoehorn"
|
| Git Bash is an elegant solution that brings some of the awesome
| Gnu utilities and does it on Windows terms and effortlessly. No
| shoehorn needed.
|
| WSL is handy (those times I'm forced to use Windows - which is
| still better than when I'm forced to use Mac) but you have to
| remember the whole time you're in WSL, you're in Linux proper
| and all things work as Linux, generally, sort of. Git Bash is
| the power of Gnu right on Windows.
| devnullbrain wrote:
| WSL also adds yet another restart loop to the already lengthy
| process of turning a fresh machine into a workable Windows
| development station.
| CoolCold wrote:
| My take here - when working with stable system, changing OS
| once a several years (last one was when changing laptops
| basically, so 4+ years in my case), I don't care much on
| _single_ reboots. For those who tirelessly do
| distrohopping, things may look different of course.
| beart wrote:
| The minor differences can be a major issue. Powershell 7 still
| doesn't come installed on any windows system as far as I know,
| so you are better off targeting Powershell 5, and unable to
| take advantage of the features offered by 7.
| devnullbrain 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?
|
| An answer that I haven't seen offered yet: because Microsoft
| spend billions trying to gain and retain developer marketshare
| 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/
| wilsonnb3 wrote:
| Any reason to choose scoop over chocolatey, which has been
| around forever, or winget which is included in windows these
| days?
| speilberg0 wrote:
| scoop generally installs to your local data, so most programs
| don't require admin access.
| beart wrote:
| Scoop favors portable installs and typically manages upgrades
| and migrations for you. It does support non portable tools
| but these live in a different bucket.
|
| Chocolatey, and to a greater extent, winget typically defer
| to the individual applications. In my experience they are
| more like glorified download indexes than actual repositories
| for managing software.
| amenhotep wrote:
| When I tried using chocolatey, you had to pay them in order
| to specify a default install directory rather than needing to
| include it explicitly in every command. I don't know if this
| is still the case but I formed a deeply held grudge over it.
|
| When I tried using winget, it mostly worked quite well, but
| occasionally would fail horribly. It'll happily detect and
| offer to upgrade programs that were installed outside winget,
| for example - great feature!! - except one time when I tried
| doing this it installed a new instance to a default location
| instead of upgrading in place, so now I had two
| installations. I don't trust it.
|
| Scoop is simple and sensible and just works in exactly the
| way I expect it to. With the exception of needing to install
| scoop-search.
| keithnz wrote:
| winget seems to have replaced chocolatey for the most.
| Chocolatey is a bit weird with their play to make money, I
| guess they want to milk it for as much as they can till it
| dies.
| dundarious wrote:
| Installing something with chocolatey means downloading some
| powershell script, with somewhat arbitrary contents, and
| running that to do all sorts of install, restart, migration,
| etc., logic, of varying quality, and with varying
| philosophies of what should be done "automatically".
|
| Installing something with scoop means downloading a
| declarative json manifest, with occasional, short pre-
| install/post-install levels of scripting (in all cases I've
| seen, it amounts to testing if a file is present, and copying
| it if so, etc.). The complexity that is tolerated for the
| scripting is much much lower.
|
| I've also found chocolatey to be less well curated, with some
| odd packages with simple names that come from random people
| who don't seem to do a great job at maintaining the package.
|
| scoop is preferable on every metric, IMO.
| microflash wrote:
| Scoop rarely pollutes Windows registry which is what often
| triggers the corporate blocklists. The portable install is a
| feature here, compared to chocolatey or winget.
| indigodaddy wrote:
| Oh snap you can `scoop install busybox` and get a bunch of nix
| builtins!
|
| https://paste.almalinux.org/2A
| 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.
| johnea wrote:
| Why not just ditch the "windows" part entirely, and work on an OS
| that's not designed for the purpose of exploiting you as a user?
| philipwhiuk wrote:
| Speaking personally, it's because the company only supports
| Windows for everything else.
| gruturo wrote:
| For a lot of people, this is your employer's choice and not
| yours unfortunately.
|
| I jokingly remark that most of my contacts with microsoft
| products are non consensual.
| cafard wrote:
| I was just using Git Bash to run grep...
| Tempest1981 wrote:
| And ripgrep
| JackMorgan wrote:
| As a long time personal and professional Linux user, lately my
| work has led me to work for companies that are Windows-only. I
| use git bash as my main shell on Windows. It just works for what
| I need, and in the rare cases I need powershell I just open that.
|
| Most of the windows-based programmers I interact with don't know
| powershell any better than I do. They use GUI tools for
| interacting with git and the filesystem.
|
| So for me, git bash for git and filesystem interaction is a
| superpower in these places.
|
| I could learn powershell, and I'm pretty sure it's much better
| than bash for scripting, but I'm almost never really scripting in
| bash anyway, I use tools like F# for that. Powershell seems fine,
| but it's less well supported on Linux and I don't really need a
| shell based language.
|
| So in the end, git bash keeps on working and I can focus my
| learning elsewhere. It's stable, still works the same way 15+
| years later, so no need to change.
| bena wrote:
| Powershell lets you install extensions and run commands against
| the clr.
|
| It's basically a clr repl.
|
| If you need to interact with windows/microsoft specific things
| (i.e. Active Directory), it's pretty convenient
| oldsecondhand wrote:
| Another thing to consider is availability: many companies don't
| even allow powershell for dev users.
| nikau wrote:
| Gitbash is handy for simple things, but it's a slug compared to
| wsl2.
| niobe wrote:
| Well I took a different route.
|
| Always beem 'forced' to use Windows as my workstation by a couple
| of specialty apps without Linux alternatives that need direct
| hardware access. But have always used linux on everything else
| (servers, even my media centre). Because I'm sometimes a late
| adopter of new tech, until recently I used cygwin as my normal
| command prompt. There were few downsides to that if you just need
| access to unix tools, except package management is a bit
| annoying. Well, discovered the MS Terminal and WSL this year, and
| happily moved off cygwin. More recently decided to switch over
| from WS1 to WSL2 but still evaluating the move.
|
| Now I have a unix "more native" environment AND a linux distro
| I'm familiar with. I've been accessing the Windows filesystem
| under /mnt for two decades so this is normal for me, and if
| filesystem access is slower, it's not a dealbreaker. All my
| existing scripts were trivial to update. The integration of WSL
| and VSCode is also pretty cool. It means my vs code environment
| environment is also working natively in my WSL distro.
|
| Overall can understand some lingering negativity about MS efforts
| in this dept but after years of rejecting all things linux and
| open source, in general the 180 from the top is much appreciated
| and it has kept me on Windows a while longer...so mission
| accomplished microsoft. Just gotta do something about those pesky
| apps I still need...
| yamapikarya wrote:
| i love windows terminal + git bash combo
| rr808 wrote:
| The reason I used to use Git Bash was to ssh to Unix boxes. Since
| Windows Terminal came out I dont use any more, Windows Terminal
| is much better.
| Ayesh wrote:
| The post is about the shell; Windows terminal is only... Well
| ... A terminal.
| jborean93 wrote:
| And ssh is a binary so isn't fully shell related :)
| fud101 wrote:
| its good but it has that bug with tmux that can be very
| frustrating.
| locusofself wrote:
| I started using Linux in 1997. I've been working at Microsoft for
| a little over 4 years. There are some annoying things about
| Powershell (verbosity and slow loading of tab completions etc),
| but in some ways it's vastly superior to bash, as it deals with
| structured data and not just strings you have to parse, and it
| has an extremely powerful standard library API (.NET) at your
| fingertips.
|
| I still love bash and use it as well. But the hate powershell
| often gets is misguided.
| irunmyownemail wrote:
| Bash rocks because it is about the user and the OS. Powershell
| is about one thing, Microsoft and the ugliness of ItS
| CumBerSomE-SynTaX Du-Jour is proof.
| lnxg33k1 wrote:
| I feel it's nice to have the power of choice, I can deal with
| structured data in bash as much as I need, whenever I need,
| with awk, but it isn't there when I don't
| skinner927 wrote:
| There was a time in Powershell's life when stdout redirection
| to a file (>) would write UTF-16, then that changed to UTF-8
| with BOM and now it's UTF-8 no BOM. During those times some PS
| versions would allow to change this globally, some would not.
| Even if you could change it globally, the names for the same
| encodings have changed.
|
| PowerShell 5.1 "UTF8" actually meant "UTF-8 with BOM"
|
| PowerShell 7 "UTF8" meant no BOM.
|
| If you read a file in PowerShell that does not have a BOM it
| decodes it as ANSI. Yes, ANSI, not Ascii. Which is a hilarious
| choice because you can't even write an ANSI file in PowerShell.
| The closest encoding you can use is "Default" which will use
| the system default but your systems default might not be ANSI.
|
| PowerShell is a hot mess. Go read the official docs for
| character encoding[1] if you don't believe me.
|
| I have CI scripts that have to use .NET calls[2] in PowerShell
| to write ssh keys to disk because it's impossible to write
| utf-8 no BOM (or ascii) with out carriage returns (\r) being
| inserted before every new line (\n) even when the incoming
| string didn't have them.
|
| File encoding is just ONE of the reasons I hate PowerShell and
| why it's so obviously clear people who were not qualified to
| design a shell, designed a shell.
|
| [1] https://learn.microsoft.com/en-
| us/powershell/module/microsof...
|
| [2] https://stackoverflow.com/questions/5596982/using-
| powershell...
| beart wrote:
| It's also worth pointing out that those Microsoft docs
| differentiate between the two major versions of powershell
| using the names "Windows Powershell" and "Powershell".
| delusional wrote:
| I also enjoy how the online manual pages doesn't even try
| to tell me which version it's about. It's all just
| powershell https://learn.microsoft.com/en-
| us/powershell/module/microsof...
| nullindividual wrote:
| The version picker is in the ToC on the upper left.
| wodenokoto wrote:
| I think MS has a team dedicated to confusing naming.
| unscaled wrote:
| The original project name was "Monad", but once it was
| nearing release, it got into the hands of the notorious
| naming prodigies in Microsoft marketing. Then it got
| changed to Microsoft Shell (MSH) and finally to Windows
| PowerShell. Great times.
| 7bit wrote:
| It did not get changed.
|
| Windows Powershell is up until 5.1 because it runs ONLY
| on Windows.
|
| Powershell 6 was named Powershell Core due to being built
| with .NET Core. It was not fully compatible with 5.1 and
| lacked some functions based on the WinApi.
|
| PowerShell 7 is still built on .NET Core, but has a much
| better compatibility with 5.1. They dropped Core because
| nobody cared and it's shorter and works equally well on
| all platforms.
|
| So Powershell is the v7 and Windows Powershell is the old
| 5.1. Nowhere is that confusing.
| pathartl wrote:
| Also worth noting that PowerShell is completely
| independent from Windows now. Not only can you install it
| in almost every other platform, since it's .NET you can
| embed the runtime in any .NET application. It's
| incredibly powerful.
| sp1rit wrote:
| > since it's .NET you can embed the runtime in any .NET
| application
|
| not actually "embedded", more like a bit of shim code
| that extracts the runtime into some temporary directory
| that then runs the actual code.
| unscaled wrote:
| I'm not sure if we should blame the designers of PowerShell
| (Jeffrey Snover and his team). If you followed the history of
| their project, it seemed like they had very good ideas, but
| it was very hard to get buy-in for anything CLI-oriented in
| Longhorn/Vista-era Microsoft[1]. They've all had experience
| with Unix shell and their ideas for object based pipes were
| truly innovative as far as I know.
|
| I can't speak for Jeffrey and his team, but I feel like a lot
| of their decisions came from trying to get corporate behind
| the shell and present it as a shell for Windows. They avoided
| picking political battles outside of their main goals (a
| modern shell to replace cmd.exe and the object-based pipeline
| model). What we've got are a set of decisions that aligned
| with Windows and Microsoft practices of that day and age:
|
| Microsoft is focusing on .Net as their general platform?
| We'll implement PowerShell on .Net.
|
| Windows's standard for Unicode text files is either UTF-16 LE
| or having a BOM for any other Unicode transformation? We'll
| do UTF-16 by default and always add a BOM if you choose
| UTF-8.
|
| Windows is using CRLF? Well, we'd pipe CRLF-delimtied text by
| default.
|
| Visual Basic and C# programmers expect functions to have
| names like "GetChildItem" instead of something like "dir" or
| "ls"? No problem, we will set the canonical command name to
| be a long, programming-language-like name and set up aliases
| that look (but don't behave) like Unix and cmd.exe commands.
|
| The result was not pretty, but I still appreciate the ideas
| we got from PowerShell. nushell took these ideas and
| implemented them in a more modern way.
|
| [1] https://corecursive.com/building-powershell-with-jeffrey-
| sno...
| cma wrote:
| Lots of explanations, but why can't you globally configure
| reading with no BOM if writing with no BOM is now the
| default?
|
| It doesn't seem like it could be for backwards
| compatibility, as now an old script that writes a file with
| defaults can't later read it with defaults?
| ozim wrote:
| Wait - you might just have helped me to fix my Invoke-
| WebRequest testing 3rd party api we have to integrate with.
| Unexpected character encountered while parsing error line 0
| position 0 seems like there is a BOM I wasn't expecting to
| send in my request and receiver definetly was not expecting
| to receive it.
|
| Edit: yup, just did small cmd line client and all works.
| Thanks.
| sevensor wrote:
| UTF8 with bom is a terrible idea. "Why does the name of the
| first column in my csv file not match?" is a question I
| answer at least once a month. It's as if they're trying to
| EEE plain text.
| 7bit wrote:
| > File encoding is just ONE of the reasons I hate PowerShell
| and why it's so obviously clear people who were not qualified
| to design a shell, designed a shell.
|
| I find that unfair towards their creators. They invented a
| truly innovational shell, whereas everybody else continued
| the text-based approach. The object-oriented approach is so
| much simpler when it comes to process results of Get-
| ChildItem (ls) or Get-Process (ps) when you get objects with
| properties, instead of just text. Especially when in text-
| based shells it matters how you call e.g., ps (aux or -efH or
| whatever).
|
| Now, I find your statement unfair, because in Linux world,
| you just create a new shell and whoever wants to use it, can.
|
| At Microsoft, a successor to cmd.exe had to be shipped with
| Microsoft, otherwise it would never have been adopted. Most
| big companies would never allow a third-party open-source
| shell on their Windows servers. Therefore, you must navigate
| a big ocean of politics and powers, guarantee nackwards-
| compatibility and meet expectations of thousands of
| companies. This inevitably leads to behaviour like encoding
| that is frustrating to use. Until you read the docs, which
| state quite comprehensively what you have to expect - as you
| discovered yourself.
| zo1 wrote:
| Hey let's not pretend like it's better in the world of
| Linux/Unix/etc. Now that is one hot mess of everything, just
| as much as Powershell. It's just those have things we're used
| to, and kinda learned to (mostly) abstract away without the
| presence of an over-bearing behemoth such as Microsoft which
| makes such a thing almost impossible.
|
| As a comparison (to most of us semi-knowledgeable windows /
| powershell users), ask any semi-knowledgeable Linux user
| about the difference between Ksh/Bash (or that weird one that
| Ubuntu pushed and aliased to one of the above for extra
| confusion). Or ask them if any of them remember how tf to use
| SED or AWK without looking up the docs because those damn
| things are made by satan in the depths of hell. Or how to use
| parameters inside shell scripts, and the various incantations
| they have to slice and dice the params.
| Yodel0914 wrote:
| I've used powershell a bit, particularly for scripting CI
| pipeline steps. No matter how much I use it, I can never
| remember anything about the syntax. I primarily use C#, so
| you'd think there'd be some affinity, but nope. It's like a
| black hole.
|
| I've written in a lot of different languages in my time and
| never had this issue with anything else. It's weird.
| rewgs wrote:
| Exact same here. I write roughly the same amount of
| Powershell as I do Bash, and yet to this day I feel like I
| barely know Powershell and constantly look up the simplest
| things, whereas loads of dark corners in Bash stick in my
| mind perfectly fine.
| Fire-Dragon-DoL wrote:
| To be fair, I have a similar problem with bash. There is no
| way to remember how to write a for loop for me
| devnullbrain wrote:
| Can Powershell tee a background task yet?
| cassepipe wrote:
| Nushell is plenty fast, works with structured data (also has a
| vi mode if you care, I do) and works equally well on Windows
| and Linux. You can install it with winget on windows and with
| cargo or the system's package manager on linux.
|
| https://www.nushell.sh/
| dblohm7 wrote:
| AIUI the verbosity is by design to make scripts more clear, and
| users are expected to use aliases to make cmdlets easier to
| work with interactively. But I assume that few of those aliases
| are actually standardized...
| klingoff wrote:
| Powershell introducing the English language to a shell at a
| time when everyone else was doing i18n is about 3 leaps beyond
| an annoying thing in the traditional Microsoft form of the
| time.
|
| You can do what ever you want for innovation but if you choose
| mindf*ck as your UI..
| WalterBright wrote:
| I constantly switch back and forth between Windows and Linux and
| it's always "dir" mixed up with "ls" coming from my fingertips.
| Grump grump grump
|
| Edit: I know I can use aliases and .bat files and whatever to
| make one look like the other, sort of, but then I learn some
| patchwork system and will be unable to use any other computer's
| login.
| SPBS wrote:
| I almost never used `dir` because `ls` is supported by
| PowerShell. Is there a reason you have to use CMD?
| WalterBright wrote:
| Mainly because it isn't the default.
| mixmastamyk wrote:
| I've made the dir and cls aliases on Unix for as long as I can
| remember. And keep dotfiles in git. Yes, computers out of your
| control won't have them, but better to have them 90% (for me
| 99%) of the time rather than 50%--which is just annoying.
| WalterBright wrote:
| cp and copy, and \ and /, etc. My sanity is preserved,
| however, by having the same editor on all the machines I use.
|
| Although I can't get copy/paste to work in a remote text
| putty window. Sigh.
| mixmastamyk wrote:
| Yes, many windows things accept /, as I'm sure you know.
| Have used the ssh command instead, easy install now but
| twenty years ago had to hunt for openssl/ssh for windows.
| Console/Winterm should allow paste, though console puts on
| wrong mouse button of course.
| WalterBright wrote:
| > many windows things accept /, as I'm sure you know
|
| I do know. But it isn't complete, whether it works or not
| depends on which command or program you're using. It's
| not really predictable.
|
| Posix programs ported to Windows have similar problems -
| they often remain case sensitive with filenames.
|
| At least all the programs I write work accept both \ and
| /, and are case sensitive on Posix and case insensitive
| on Windows.
| doctorpangloss wrote:
| Busybox for Windows is much better.
|
| - Paths look much better: C:/Users/doctorpangloss ==
| /Users/doctorpangloss == C:\Users\doctorpangloss.
|
| - The coreutils are just there.
|
| - Works flawlessly as an SSH or Dockerfile shell.
|
| - Fast and tiny. So small you can check it into git.
|
| - The maintainer is very responsive and fixes bugs quickly, even
| in upstream.
|
| git-bash has problems because of paths, terminal weirdness, and
| it doesn't use native Windows APIs for a variety of things where
| it should. /c/ this, /mnt/ that. It's not really possible to
| write multi platform scripts with it. With Busybox for Windows
| you can.
| esalman wrote:
| Git SDK for Windows is even more awesome, complete with a package
| manager for fetching more common unix tools with ease.
| dundarious wrote:
| git bash's main benefit being that it's a commonly installed
| variant of the wonderful msys2 system, then yes, I tend to agree.
|
| Another wonderful benefit of git bash, is that because it is so
| commonly installed, if you want scripting for a dev/build tool,
| you can 99% of the time just use bash for your scripts, on linux
| and windows.
|
| I use this all the time for my build scripts. build/x86_64-linux-
| gnu-gcc.sh, build/x86_64-windows-msvc-cl.sh, etc. (These are
| generally simple single command line unity builds, parameterized
| only by debug, opt, etc.)
|
| Then from pwsh I can run these scripts with `&
| "$env:GIT_INSTALL_ROOT\bin\bash.exe" .\build\x86_64-windows-msvc-
| cl.sh`, similarly from cmd.exe. (Looks like a ton of typing, but
| it's not, I always Ctrl-R search and get a hit by just typing
| "git_").
|
| No need to write a bat script, or even a pwsh one, pretty much
| ever again. Even if all you want is logic to cd to the script
| directory, parse a single script argument, check it's valid,
| provide a default, make some directories if not present, etc.,
| bash beats all the alternatives on many fronts.
| ruthmarx wrote:
| I've been pretty happy with clink [0].
|
| I'm not looking to have the same environment everywhere, I'm fine
| to have windows stuff optimized for windows on windows, and vice
| versa on Linux.
|
| By that reasoning, I think clink is a much better option.
|
| [0] https://github.com/chrisant996/clink
| shortlived wrote:
| Clink + windows terminal + Git tools is the perfect setup IMO.
| aurelien wrote:
| You should try ArchLinux or Gentoo if you really want a shell as
| you desire ;)
| konfekt wrote:
| For those without admin rights preferring ZSH to Bash in the
| Windows Terminal: install MSYS2 with scoop.sh, then the ZSH
| package with `pacman -S zsh` and add a shell with commandline
| `%USERPROFILE%\\\scoop\\\apps\\\msys2\\\current\\\msys2_shell.cmd
| -defterm -here -no-start -ucrt64 -shell zsh` to launch it in
| Windows Terminal.
| Hackbraten wrote:
| For me, the biggest downsides to Git Bash are:
|
| 1. I don't understand how it relates to msys2 and where the
| boundary is, so I'm always reluctant to apply msys2 practices
| (documentation, advice, blog posts, etc.) to Git Bash.
|
| 2. I've been unable to figure out how to package scripts and
| other software for Git Bash so other users can install them.
| daghamm wrote:
| WSL inside the new Microsoft Terminal is my preferred Windows
| Shell.
| bricss wrote:
| Git Bash + Windows Terminal = one luv
| grepfru_it wrote:
| Git bash breaks password entry on certain tools that hides
| character input.
| kennethrc wrote:
| I'm "All Linux, all the time" at home, develop in it, help out
| with the Kernel a little bit, only use Windows at home in a VM,
| etc.
|
| I'd just started working for a client that is fully entrenched in
| Windows, but we're doing bare-metal and Linux-y work. When I'd
| discovered I couldn't use Linux as my daily driver due to
| security/policy(/tooling) reasons, one of my co-workers told me
| about Git Bash, and it's worked out so well that ... <looks left,
| looks right> ... when we were given the opportunity to use Linux
| but VM Windows, I kept the Windows machine.
|
| GitBash has made Windows painless for my work's use-case. I
| should probably throw a few $$ at them ....
| jmkni wrote:
| Can't you use WSL?
| kennethrc wrote:
| I have it available, but GitBash seems to work better with my
| workflow. BTW, when I checked to see how to donate,
| apparently my client pays for it; I thought it was OOS.
| 4oo4 wrote:
| Git Bash is really nice for when I want a unix utility that will
| do the job simpler and better than Powershell, however it's
| painfully slow for larger I/O operations.
|
| I end up barely using it on my Windows 11 work machine because
| I'm allowed to have Linux VMs. Even with the VM overhead, and
| having fewer CPU cores and less RAM than the host, things still
| end up being way faster there.
|
| I remember one time running a grep command on a large-ish (~ 1
| GB) log file in Git Bash and waiting at least 5 minutes for it to
| complete. After getting impatient I did the same thing in a VM
| and it took about 30-45 seconds, at which point Git Bash still
| had not finished.
| steve1977 wrote:
| Did you use endpoint protection in both systems? In my
| experience, that is often a factor of performance issue on the
| Windows side (and an unfair comparison when it is not used on
| Linux)
___________________________________________________________________
(page generated 2024-09-11 23:02 UTC)