Bash 4.4 released | Hacker News Reader

Bash 4.4 released

lists.gnu.org

240 pointsokket79 comments

A little anecdote: there was a case of O(N^2) in readline with long lines. Essentially a bug in the redisplay logic. It affected Bash, mysql/psql, Python, etc.

After having suffered from this for some years, last year that annoyed me enough to start digging into readline to figure out what was causing it. In the end, that prompted Chet Ramey to come up with a fix which looks like it is now being released!

I promised myself that when this one was fixed, I'd look into why most readline shells can go nuts when you resize them - somehow they don't always discover that the line width has changed.

Thank you, thank you. You are my hero, for serious.

> I promised myself that when this one was fixed, I'd look into why most readline shells can go nuts when you resize them - somehow they don't always discover that the line width has changed.

Possibly related?

> Use pselect(2), if available, to wait for input before calling read(2), so a SIGWINCH can interrupt it, since it doesn't interrupt read(2).

(from the Readline-7.0 release notes)

I really like this one:

    jj. New prompt string: PS0.  Expanded and displayed by interactive
        shells after reading a complete command but before executing it.

I currently use my PS1 for a lot of dirty things that would have their place in such a PS0 :).

Now, I just have to wait until Bash 4.4 lands in Debian…

Wait, how does this work again?

See you in Debian stable 10.

4.4rc2 is in experimental and 4.4 is likely to end up in -backports, so it's not all bad.

Like what? Out of curiosity.

I detailed some of these dirty things in an old (2011) blog post: https://shebang.ws/fast-window-switch-2-bash-tricks.html

You could use PS0 to make your terminal title be "running <name of program>" when a program is running, then "directory <dir name>" when just on a prompt (that might be too busy for some people, but I'd like to know if a program is actively running in the terminal title).

See my other comment with a link to a blogpost that explains how to do just this before having PS0 :).

Ah, cool. Didn't realise there was a hack around it (that might still be useful on non-4.4 systems).

This is really nice if you keep your own history because then the directory stored for commands like cd will be the one it was called from rather than the one it moved you into.

Presumably I can use this to display when the command started (PS0='\t'). I've wanted that forever.

Yes! This is huge for visually knowing when something happened.

To find the time taken by jobs, it's simplest to just display current time in the prompt. You can quickly look at the time when the job start and the time after job ended.

PS1="\@ \h \w> "

This displays current time, host and working dir.

Except you have to not forget the to refresh the prompt before typing the command after a coffee break or switching terminal tabs, etc. The PS0 solution is much, much better for this use case.

You could implement PS0 in an older Bash which doesn't have it.

See here:

http://superuser.com/questions/175799/does-bash-have-a-hook-...

There is way to hook into command execution. And that piece of code you hook in could look at a variable called PS0 and process it the way Bash 4.4 does it now.

This new PS0 might provide a pre-execution hook of its own. If it performs $(....) command substitution (like PS1 does!), it provides a way of executing arbitrary code. If the entire prompt is "$(some-command ...)" and that command produces no output, then you have a de facto pure hook.

Yes that's what I did, see my other comment where I link to one of my old blogpost detailing it. My point is that PS0 will make that cleaner :).

Here is the announcement on mailing list:

http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00018....

http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00019....

One Readline feature I have been looking forward to:

> c. The editing mode indicators can now be strings and are user-settable (new `emacs-mode-string', `vi-cmd-mode-string' and `vi-ins-mode-string' variables). Mode strings can contain invisible character sequences. Setting mode strings to null strings restores the defaults.

So now I can get the prompt to change color depending on the mode!

Do you know if you can change it when in insert mode vs normal mode? That's one of the things that stops me from working in vi mode in bash.

EDIT I seem to have misread that description. So it is possible, that's brilliant news!

Excellent news. This is the one thing that zsh had and bash didn't. Well, among the things that I use...

Does that mean doing `Ctrl + R` can be colorized now just like how zsh does it ?

It seems that this has not been fixed (or maybe I'm just doing something wrong?):

https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00031...

Edit: it looks like you must use \1 and \2 instead of \[ and \].

Archive link: https://archive.is/n9Qb7

> ll. Posix-mode shells now allow double quotes to quote the history expansion character.

Yikes, finally you can use `echo "Hello World!"`

I never understood that feature. I have been putting `set +H` for decades on every profile of every system I touch.

OS X has been stuck in 3.2.57 for years due to licensing.

I like being able to SSH into a fresh Linux box and feel at home, but at some point, they'll be so different that I might as well permanently switch to Zsh.

I keep hoping for Apple to adopt Fish, last I heard the guy works there, and it's totally Apple's thing to have its own shell. It would be fun at least.

I gave in and installed bash from Homebrew.

Same here. Wish I had done it sooner.

Having a, "Holy shit, why didn't I think of that?" moment over here. Thanks for the tip!

So weird, I literally updated bash minutes before seeing this post about bash. I followed these instructions to enable it as default https://johndjameson.com/blog/updating-your-shell-with-homeb...

This is what I do, and just so others know:

Realize that if your personal account's shell is pointed into the homebrew installation in /usr/local, and you implode homebrew or wipe /usr/local, you won't be able to start a terminal until your shell is changed or the binary exists. Solving this without Terminal.app being able to launch is a minor annoyance.

That is a very good point, thank you

The proof of this is trivial, and left to the reader.

Right, so have Terminal run this instead:

  #!/bin/sh
  
  for shell in \
    /opt/local/bin/bash \
    /bin/bash \
    /bin/sh
  do
    [ -x "$shell" ] && exec "$shell" -l
  done
  
  echo >&2 "ERROR: No valid shell found!"
  read -r -s -n 1 -t 10 dummy
  exit 1

If you are able to run a script with #!/bin/sh, and /bin/sh becomes un-executable during the execution of your script, you're definitely having a bad time. :D

I found an "article" that explains this a bit [0], the gist is that the App Store is the sticking point. But why would this be the case? What does bash have to do with the App Store app? And why are they still allowed to distribute 3.2?

[0] https://www.quora.com/What-is-the-reason-for-some-of-the-Lin...

Bash 3.2 is distributed under GPL Version 2. Bash 4 is under GPL version 3. (I'll let others discuss the differences and how they might interact with the App Store.)

That doesn't make any sense, App Store has no relation to what Apple distributes as part of macOS.

Apple takes issue with patents-related wording in GPL3 and doesn't want to be subject to GPL3 (while they're OK with GPL2). Hence not distributing GPL3-licensed software.

FWIW fish is great. My only complaint is that you can't use the `ENV_VAR=value` syntax available in bash, but you really just need to prefix with `env`.

> The shell now allows `time ; othercommand' to time null commands.

Uh, what? Could someone explain this one, please?

Pre 4.4 - ';' (command separator) was ignored by time

  # time; echo hola
  -bash: syntax error near unexpected token `echo'

Why would you want to time nothing? What does it output, real 0s user 0s system 0s?

Why would you want to multiply by 1 or sum zero? You probably wouldn't need to do it, but computers and scripts aren't so smart as people and always follow code literally. For them is important a language having less irregularities and exceptional rules. If "" is a valid command and you have the syntax "time [COMMAND];", why not allow "time;"?

It might be to avoid errors for scripts like:

  time ${cmd}; foo

where cmd happens to be unset. Conceptually, that's a valid script, because `time` standalone is a valid script. No reason it should generate an error.

Not always the case, I just tried and:

$ time

real 0m0.002s user 0m0.000s sys 0m0.000s

Holyshit!

After four releases versions bash starts to get regular syntax?

    o.  There is a new address@hidden family of operators to transform the
    value of `parameter'.

Can anyone show an example of that? I'm not sure I understand that feature.

Interesting addition ${PARAMETER@OPERATOR} parameter expansion. Taken from the new docs, see:

https://www.reddit.com/r/linux/comments/52z087/bash_44_relea...

I'm not sure how wise that is. It doesn't exactly lead to readable scripts. Zsh has had the equivalent feature with the syntax ${(operator)parameter) for over two decades so plenty of time for more operators to be added. It is very powerful but worse than perl for code that looks like line noise.

It was mangled by the anti-spam system, which does make it confusing to read.

Cool stuff. Weird numbering though.

I was led to think that Chet's bash page [0] might contain details about the 4.4 release. Unfortunately, not.

(Chet Ramey [1] is the primary maintainer of GNU bash.)

[0] https://tiswww.case.edu/php/chet/bash/bashtop.html

[1] https://tiswww.case.edu/php/chet/

It does now: https://tiswww.case.edu/php/chet/bash/NEWS

This is a terse description of the new features added to bash-4.4 since the release of bash-4.3...

One of the most important open-source projects in my view. Great work!

Still waiting on a formal way to denote namespaces in bash

Really, posting a link to `git.savannah.gnu.org/cgit/` was probably not a nice thing.

Why? There is no official release posting I could find, not on the website, not on the mailing lists. ~~Also, cgit seems to cope with the traffic.~~

Edit: I see. Sorry. My browser was caching all requests to cgit. Please have the mods replace the link with something better.

Meanwhile, please visit the link from _jomo: https://archive.is/n9Qb7

It's down right now.

Not anymore, at least for me.

Thanks, we've updated the link from http://git.savannah.gnu.org/cgit/bash.git/plain/NEWS?id=a0c0... to the release announcement.

This may be a better link: http://lists.gnu.org/archive/html/bug-bash/2016-09/msg00018....

> Bash now checks $INSIDE_EMACS as well as $EMACS > when deciding whether or > not bash is being run in a GNU Emacs shell window.

hahaha

Next release it will check the variables $INSIDE_ACME, $INSIDE_SUBLIME and $INSIDE_NOTEPADPLUSPLUS

I don't think this is a good design decision either.

Next release would probably check $INSIDE_SCREEN, $INSIDE_BROWSER, $INSIDE_PHONE, $INSIDE_VR, $INSIDE_PAPER, $INSIDE_HUMAN

Bash and Emacs are under the same umbrella. This software is part of GNU system and systems tend to incorporate its part to make it more maintainable.

However, more generic solution shall be used, like checking out parent process of current session to determine environment in which bash is running.

The problem is not only with bash, but with entire gnu ecosystem. Bash disable something ONLY when the parent process is EMACS is totally nonsense. Bash should check for some behavior, instead of some technology... because I'm sure other editors can behave similarly when executing bash inside some buffer.

Doing software this way makes bash and emacs working well, but hard to make other softwares interact with both of them... Sublime, acme, micro, and so on can benefit of a better solution. In the same way, other shell should work fine inside emacs (M-x ansi-term).

But software design is not expected here (see downvotes)

Reply on news.ycombinator.com