Hacker News Reader

Comment by larrik | Hacker News Reader

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.

View on HN

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.

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?

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.

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.

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

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...

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-...

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.

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.

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!

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.

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!

> 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...

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.

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.

> 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 `/`.

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.

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

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.

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

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.

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.)

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.

Reply on news.ycombinator.com