Hacker News Reader

Comment by tombert | Hacker News Reader

I'm always in favor of things being open-sourced, but I do kind of wonder in what universe I would use PowerShell when Bash is readily available.

View on HN

As a full-time Linux user, I have to say that bash is overrated.

For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

Yes, you can customize it a lot, and you can script it but default bash isn't that special to me.

You can use control-O for that, which does "execute this command as if I pressed enter, then when it's done bring up the following command in command line prompt". So if you have a set of commands to run that are 20 lines up in history, you can first find them (with 20x UP or by reverse-search), then just control-O control-O control-O control-O ... to execute them one after another.

Don't forget control-R. I find that even the GP's example of up arrow 20x to be ridiculous when I can type C-r and a few unique letters that were anywhere in the command to find it instantly.

Which is why any sane powershell user would probably have installed PsReadline to get this and other goodies. Preferably running in ConEmu.

PsReadline is shipped with PowerShell 5: https://technet.microsoft.com/en-us/library/ed48e832-95f9-45...

I wasn't aware of this. Thank you.

Not that I've been using Bash and zsh every day for twelve plus years...

Twelve? Youngster. I'd guess I'm coming up on thirty years. And I did not know this.

Now the trick is to remember it next time the need comes up. :-)

Seems to be an instance of Cunningham's Law:

https://meta.wikimedia.org/wiki/Cunningham%27s_Law

Oh. My. God.

Life changing!

Out of curiosity, how did you discover that you could do this?

I am not the GP but I learned about C-o by reading the man page. If you spend a lot of time in Bash, why not learn to use it properly? There are less than ~100 key bindings, see "Readline Command Names" in http://linux.die.net/man/1/bash You should at the very least skim over them.

  operate-and-get-next (C-o)
  Accept the current line for execution and fetch the next line relative to the current line from the history for editing. Any argument is ignored.

It's been something I've used for many years, so I really don't recall any more just where I found out about it...

Maybe it went something like "god damn it why can't I ctrl+v to copy, what other ctrl keys are there..."? And now I'm looking at http://ss64.com/bash/syntax-keyboard.html and being amazed I didn't know about / forgot a few of these. It'd be nice to put some of the good ones on a coffee mug, I first learned useful vim commands from a coffee mug...

Nope, because I've never used control-keystrokes to do cut-n-paste. I always use (and love) X-style mouse cut-n-paste and hate that there are no good implementations of it on other OSes.

Dating myself, the way I learned copy and paste was CTRL-insert and SHIFT-insert, and those still work fine in konsole, mate-terminal, most any other half-decent terminal program, and straight text mode outside of X.

Not xterm, but I never use that.

are you serious? you guys need to learn more shortcuts. http://teohm.com/blog/shortcuts-to-move-faster-in-bash-comma...

Doesn't work in bash running in my Terminal.app on macOS, although it certainly does when I `ssh` into one of my Ubuntu boxes. Wonderful shortcut.

EDIT: If anyone knows an easy way to get this working on macOS, I'd love to know it.

Stackoverflow to the rescue: http://apple.stackexchange.com/questions/3253/ctrl-o-behavio...

This turns out to be because on OSX the terminal driver defaults to throwing away control-O which is rather unhelpful of it. "stty discard undef" fixes it.

> For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

I think the Bash default is better here. If I wanted to run 20 closely related commands, I would make them a single line; far more commonly I want one command from 20 commands ago and then the last command, which is a pain to do on Windows. Much worse is that Windows seems to lose all history every time I close and reopen a command window.

If you put this in your `~/.inputrc` [1]:

    "\e[A": history-search-backward
    "\e[B": history-search-forward
    "\e[C": forward-char
    "\e[D": backward-char

you can start typing a previous command and go up through your history for all commands starting with whatever you currently have typed into the bash shell. Reset the scrolling through the history with `ctrl+c`.

Personally, I hate that powershell remembers your position in the shell history. I don't want to maintain a mental model of the shell history rollodex and where I am in it. That's one less part of my brain that I can't use for thinking about the code. If I have a set of commands to type over and over:

    history 20 | head -10 | sed -r 's/^ *[0-9]+ *//g;' > new_script.bash

* [1] http://codeinthehole.com/writing/the-most-important-command-...

Exactly, but it makes more sense to bind history-search-backward and history-search-forward to <M-p> and <M-n> in my opinion.

The search by previous characters seems to be the default behaviour of FreeBSD's t/csh. Confused the hell out of me at first because Ctrl+R isn't reverse search.

I think I tried something like this once before, and it broke something else. I can't remember what that was, so I'm totally trying this.

Yeah, this breaks the "move over by word" with Ctrl+Left and Ctrl+Right which I use a lot. Maybe I need to add them explicitly.

Ah. I use the standard emac'esque commands to move over by word. alt+b for back word, alt+f for forward word. Not at all intuitive... windows line movement commands win over emacs bindings form an intuitive perspective.

Also you don't need these to get up/down to work:

    "\e[C": forward-char
    "\e[D": backward-char

Those are for left/right arrows.

For the record - the PowerShell team loves Bash and much of PowerShell is modelled after it. To be fair - we also modelled portions after VMS DCL, Perl, TCL and AS400 CL. There are lots of awesome engineers out there working on different platforms and we learned a lot from of them. Jeffrey Snover [MSFT]

In many bash configurations, ctrl-o is bound to 'operate-and-get-next’. If you hit up 20x, you should then be able to hit ctrl-o to run that command, and your history will automatically go to the next command down. Check it out, it’s great!

EDIT: beaten by pm215!

Bash is 27 years old. It was written to replace the Bourne shell, which is 39.

It is not terribly surprising that a 9 year old tool like Powershell made some improvements over an earlier tool that was already old enough to vote!

I don't see a tremendous amount of accumulated wisdom in Powershell. It may be newer, but I'm not sure they looked at prior art or had design members who were shell gurus in any other shell than `cmd.exe`, which is a horrific shell. Why are commands horrendously long in powershell? If you spend time in the shell, you don't want your fingers falling off due to overuse. Aside... one of the design decisions Microsoft took that absolutely blows my mind is using `\` for file hierarchies instead of `/` when you're writing an operating system in C!

There are lots of aliases for cmdlets for exactly this reason - interactive use. The verbose commands are useful when reading a script that isn't working at 3am in the morning when your boss is breathing down your neck to fix it "stat!".

RE - your aside '\' vs '/' - I think most of us still shake our head at that decision.

Jeffrey Snover [MSFT]

I don't know if that was really a "decision" or an unfortunate compromise. DOS inherited /foo style command line parameters from CP/M, and DOS 1 didn't have a hierarchical file system, so there was no conflict with the path delimiter character UNIX was using. When DOS 2 introduced directories (and brought over the cd, md, rd, etc. commands from UNIX) suddenly we had to choose between massively breaking backwards compatibility or using something else, like \, as a delimiter.

> Aside... one of the design decisions Microsoft took that absolutely blows my mind is using `\` for file hierarchies instead of `/`

That decision goes back to MS-DOS 2.11, circa 1983. (DOS 1.0 didn't have subdirectories.) The model for DOS directories came from UNIX, which at that time was the very aggressively defended intellectual property of AT&T. As Microsoft was an AT&T licensee -- for Xenix, their version of AT&T System 7 UNIX, which was Microsoft's vision of the future of operating systems when PCs became powerful enough: they licensed it in 1978 and resold it via OEMs -- I speculate that they were afraid that AT&T might sue them for patent or copyright violation relating to the filesystem design if they went with a forward slash.

They used \ for directories because most DOS programs used / for switches.

https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...

Interesting hypothesis! I'll ask Bill the next time I see him.

Jeffrey Snover[MSFT]

I'll take his word for it. (If he remembers trivia like that a third of a century later ...)

Well, he made that goddamned donkey game...

> using `\` for file hierarchies instead of `/`

You know you can use both since like XP, right? You can even mix them up in one path which can look quite confusing c:/windows\system32/etc/drivers\

`/` is not a first class citizen. You encounter different oddities throughout the windows environment in the shell and external utilities when you use `/`.

There are many (*nix-inspired) aliases for frequently used commands though. I think PowerShell's preference for verbosity is a strength more than a deficit. Why "grep" when select-string "sls" is so much more intuitive and promotes readability.

The bash I'm running is actually 3 years old. You make it sound like bash was written 27 ago and no one has touched it since then.

Secondly, what constitutes an improvement is a matter of opinion. For example, I don't see this Powersell as an improvement at all.

Autocomplete in Bash was actually a revolutionary improvement

And autocomplete in PowerShell is again.

Cmdlets tell the shell their parameters, and their parameters are long names, so you can just tab through them to find a) the available parameters and b) the ones which might help you.

Well, it's not an improvement, it's just a different design-choice. I for example much prefer Bash's way of doing it.

Also, Bash does have a way of doing it the Powershell-way, if you want that, as others have commented.

Which is also why I disagree with your statement. Bash may be old, but neither the underlying technology nor the use-case changed much in that time. So, there is not a whole lot where you can innovate with a new tool, at least not for such basic tasks, and instead, Bash has matured throughout 27 years to perfectly fit that underlying technology and use-case that millions of people have.

It seems weird that the feature of PS that you're most impressed with is something so... trivial? You have full access to your history in both shells so you could easily emulate that feature in bash/zsh or you could create a special binding to run all commands from a point in your history so you only have to press Enter once.

I actually think the basic windows command line that does it, as I was never in the habit of installing PS while on Windows.

Or just be sane and use ctrl-r and search.

I get the feeling that most users have only accessed 5% of the features available in their unix shell of choice

I would say not just the shell but most software

And almost certainly languages, too. For example C++.

As someone who has created templated subclasses with both private and public virtual inheritance, I don't think that's a bad thing. C++ is wildly powerful, but it's a mess, and most people should stick to easily understood idioms/patterns, for the sake of maintenance if nothing else.

I also highly recommend enabling the pgdn/pgup bindings for history-search-forward/backward. If you are searching for a prefix it's a bit easier than ^R.

I bound these under C-n and C-p. Very convenient indeed!

I do use this too.

>For instance, on Windows I could press the up arrow through my history 20x to find a group of commands I want to run, press Enter, then press DOWN for the following command, then enter, then DOWN until I run them all. In Bash, I need to press UP 20x every single time.

I know other users have addressed this issue in other comments with solutions, but you do know this isn't an issue with Bash so much as it is with readline, right? There are plenty of ways to customize readline/inputrc to make it do what you want. There's even linenoise, if you hate readline for what it is. It wouldn't matter how good Bash got as a shell language, this scenario wouldn't be any easier unless readline also gets a facelift.

I actually did not know that.

Bash is awful. But so are shells in general.

Even Rob Pike says as soon as your shell program gets longer than a few lines, write it in a proper language.

I feel that principle is true from all high-level languages as you move down the chain.

Shell scripts should be 1-20 lines. Python/Ruby/whatever for 20-100 and compiled for anything >100.

I was about to refute you with a recent example of mine that just needed to serially execute a bunch of commands, and it's well over 20 lines. Then I remembered that I needed to introduce some branching logic, said "not in bash, I'm not", and rewrote it in Python.

So for me, it's not a matter of LoC but complexity. Need to copy file from here to there, then commit to git repo, blah, blah, blah, then kick off a build? Whether it's a 1000 lines or 2, I don't have a problem with doing that in bash. But as soon as I need some logic (or on rare occasions, perf), I go to something else.

Given that, why do you cut shell scripts off at 20 lines? I ask in the spirit of being open to the possibility that maybe I'm doing it wrong. :-)

Well it isn't a hard limit. I am okay with a 25 line script for example ;)

Well really you are more right than me. It is about complexity more than the number of lines. However for the most part the longer something is the more complex it is to work with even if it does something simple. Managing a 1000 line bash script is almost certainly going to be more painful than doing it "properly" in Python or Java or whatever.

It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained and I find that gets easier as I work "down the chain".

It mostly comes to do this for me "is this thing going to be something I need to understand and manage outside of my own little bubble?" if it is then I want it to be better designed/maintained.

Thanks for taking the time to reply. And you're right, even I wouldn't want to maintain 1000 lines of serially-executed commands, meaning I have a line limit somewhere as well. So maybe a mix of complexity, and at some point length even if I don't put a number on it like you did.

Everyone has their own way of working :) I first got into things with batch files on Windows 95 and quickly realised how awful they are when more than 5 lines! I quickly moved on to their Windows Scripting Host stuff which was better but still painful. Then VB6 then C++/MFC.... The usual Windows user story.

Scripting on Unix is a lot better but it is only recently that places seriously use VCS for scripts in my experience so before the days of Git if you wanted to do anything with an iota of manageability it meant you did it in a "real" language hehe.

For me, the marker point is arrays. Arrays in shell are terrible - if I'm going to need an array, drop shell for something else.

Respectfully disagree. I've been writing full-on applications using Python and Qt4 which are well over 100 lines of code.

That's cool, we are just different is all. I use Python for automation tasks that require more than what I can do with Bash/Batch/PowerShell but don't warrant a full write/compile/deploy process. If your job is working in Python then sure you are going to use it way past the limits of what I would use it for.

Things are a lot nicer these days than 10 years ago though with PyCharm, etc. it makes managing a Python project so much easier.

Me too. And personally I'm somewhat conflicted as to whether or not it's a good idea. On the one hand I love python and use it for virtually all code I write (that doesn't have to run in a browser) and I'm quite convinced that for what I'm doing it's the most efficient language for me to use. On the other hand I have found myself on more than one occasion really wishing python wasn't quite so dynamic when working on large python code bases and if I was starting a new large desktop application today I'm not sure python would be my first choice. There really is something to be said for a better/stricter type system.

What if you use Nuitka or PyPy for Python, does that magically allow you across the arbitrary border?

When my shell program gets longer than a few lines, it's time to break it into some makefile targets with intermediate files.

I have in the past written a moderate size program in Powershell (installer for a program which needed a lot of configuration for a lot of components and got installed into a lot of different environments). And while that probably wasn't the best approach in hindsight, it wasn't actually that awful an experience.

It's not a million miles off writing a moderate size JavaScript program, except that it has an actual module system.

I wish they hadn't chosen dynamic scope though, nor the silly array result squashing behaviour.

Also the IIS 7 Powershell Provider - that was bad.

(Or a proper language is good too.)

Citation please? I would love to share this with some of my coworkers.

I can't find it anywhere, I have tried.

I think it is in the plan 9 mailing list - 9fans, as that is where I have interacted with Rob

You can use Ctrl+R for reverse search. However, these are minor things... You can find a plugins and what-not to add these kind of functionalities.

I use oh-my-zsh and I'm more accustomed with searching sub-history of commands, e.g. nmap <up> #=> shows flags...

I do that same on bash and zsh since... ever?

It's just default behavior and its customizable for a reason. Different people have different preferences, powershell's default behavior is in no way 'better' than bash's. You can also use a different shell like zsh.

It is just another tool in the toolchest. As you know, on Linux, there are tons of great interactive shells and it is sortof a lifestyle choice. You might want to kick the tires and see whether it fits your lifestyle or not. If you use Bash as your shell, think of PowerShell as you would python or perl - something you write scripts in and call from Bash.

Jeffrey Snover [MSFT]

Thank you for doing this!

Anyone who's done any kind of if else while for in bash/zsh and powershell knows what a relief PowerShell is. I'd love for PowerShell (PSReadline actually) to support the common options of readline- e.g. HISTIGNORE, HISTCONTROL etc

does powershell compile to IL? is it possible to create stand-alone executables from it that do not depend on the runtime?

PowerShell is interpreted, as far as I know. Class declarations may be compiled on the fly, but I've never used them; I'm basically still at PowerShell v3/v4.

We have a hotspot compiler.

We have talked about having it create a stand-alone executable but it has always fallen below the cut line.

Jeffrey Snover [MSFT]

It is about Microsoft being a neutral player in a multiple platform world. Microsoft want people using their tools as it means they are more likely to use their platforms and services. Be it PowerShell on Linux or Bash on Windows or VSCode on macOS they want to make the best tools in the hope that it will push companies/developers towards Azure/SQL/Cloud as that is where the future for MS is.

Windows is on life support and they know this. The future isn't about companies buying hundreds to thousands of Windows licenses but an instance of an OS which is billed per X/month. They have seen businesses are more than happy to enter into such a model with Office 365 and The Cloud so it makes sense for them to move in that direction.

>Windows is on life support and they know this.

How is Windows "on life support"? Desktop/laptop computers are not going anywhere, at least until they invent some kind of VR (and no, mobile OSes like iOS are not suitable for doing real work and managing data in a networked environment the way desktop OSes are). Windows still has at least 90% of the OS market. People and businesses could change to an alternative, but they just aren't, and they aren't going to unless something really drastic happens to force them to (and this would likely have to include many popular applications also providing support for one or more of the alternatives). In the business/enterprise world at least, there is simply no indication that Windows is in any danger at all of losing marketshare or revenue, in fact it's probably going to increase since businesses seem to love the software-as-a-service model.

MS could probably just make Windows free for home users (and make even money on them with advertising and selling telemetry data and also support calls), maybe small business users too, and then soak the big businesses with high fees for their site licenses and SaaS and other services.

Windows revenue has been shrinking for a few years now. The growth is in Azure and related cloud technologies.

Sure Windows probably won't ever go away (until a massive paradigm shift as you mention) but businesses are not upgrading like they once were. You have a mixture of reasons for this, BYOD has chipped away at some of it and forced companies to allow non-Microsoft (i.e. Apple) systems to connect to the network for remote and onsite.

With more and more work being done in the browser it makes specialised software that forces upgrades to Windows out of the picture.

I have worked for a number of large companies and recently the reduction of annual spend on Windows clients is pretty staggering. With almost all "managers" going BYOD with their (mostly) MacBook Pro's and onsite machines lasting a good few years longer than they used to it means we just don't need to buy as much from Microsoft.

You can see Microsoft know whats up as well. Windows Enterprise subscriptions and Azure are the future for Windows in business. For home users Windows is already "dead" from a revenue perspective with the exception of charging via the OEM at first sale. Android, macOS, iOS, tvOS, all the operating systems home users are aware of are free upgrades on supported devices. This is where Microsoft has a problem as obviously they support everything so they can't lock out some users with a "2011 Dell XPS". However going forward I expect we will see them do something along these lines with limitations around what minimum hardware is supported so you will only get upgraded to the latest Windows if you have AVX2 or such based hardware.

I would agree that Windows is nowhere near being on life support but I do think that the size of the desktop OS market is shrinking and that in the future we may see a lot more home computer users move to tablet only or something like a Chromebook.

Enterprise users are much more slow to move but as enterprise SaaS offerings become more robust we may see a lot more businesses move towards a thin-client (a la ChromeOS) and SaaS model to meet their needs. Microsoft is doing the right thing by quickly getting out in front with Office 365. If they hadn't maybe something like Quip or Google Docs could have starting stealing significant market shared but now I don't think many enterprises would bother switching if they can stay with Microsoft.

I wonder the same, but I hope it succeeds.

When PowerShell was written we knew more than when Bash, let alone the original Bourne Shell was designed. Powershell understands that parsing is sometimes hard. Powershell does not invite data-insertion attacks with the the fervour of Bash. In short, it does many things right that would Bash do too if it could be rewritten.

And yet -- I've rarely found it useful in practice. But it's hard to judge that, since I don't do as much in Windows as I do on Unix. So this move will level the playing field a bit, and we shall have a fairer comparison.

Honestly, I prefer the object based approach compared to the text wrangling approach.

I think PowerShell would actually be way ahead of Bash. But we have things so much better than Bash. Python/Ruby let you do a lot of amazing stuff (not shells, I know, but still immensely more useful scripting languages than what you can do in Bash).

Also, if you're still using Bash, I'd highly recommend looking at newer shells. Fish is pretty amazing. I've been using it over over a year. There are others too like Zsh.

I actually use Zsh most of the time, but my point is that pretty much every Linux box has Bash at this point, so I'm a bit curious what Powershell has to offer.

Powershell is really more about the scripting language and the command processing. The "shell" part is modular. On Windows you can still use most cmd tools inside powershell and with its commands.

So you shouldn't give up bash, you should use both and take advantage of the tools that help you get the most done.

What do you know about Powershell? (The answer will depend on that)

Reply on news.ycombinator.com