> symbol appearing when interactively defining function in bash

Question

The behaviour of my shell environment changed:

Earlier, when pasting a function definition e.g.

function exampleFunc {
    echo hello
}

to the shell, it would display as formatted and register the new function definition.

Now, for some reason, it displays with > before each line other than the first.

function exampleFunc {
>echo hello
>}

I've found that functions containing for loops now fail to be registered.

What might be an explanation for this? How might I revert back to the previous mode?

---

Ubuntu 20.04

This change occurred after installing nushell, but maybe unrelated.

Answer 1

This has nothing to do with you installing nushell. It also does not stop the shell from functioning correctly.

The > is the default value of the shell's secondary prompt (PS2). The secondary prompt is displayed whenever the shell requires further input after the user has pressed the Enter key without completing the current command. This happens only when the shell is in interactive mode.

The POSIX standard says this about PS2:

Each time the user enters a <newline> prior to completing a command line in an interactive shell, the value of this variable shall be subjected to parameter expansion and written to standard error. The default value is > .

In your specific example, the function definition is the command that still needs to be completed. It's not until the user enters the closing curly brace, }, at the end of the definition that the shell can execute the command.

You will also get the secondary prompt if you are pasting in the commands in the bash shell if "bracketed paste" has been disabled for the Readline library. By default, the bracketed paste mode is enabled, meaning the shell will process a pasted chunk of text in one go rather than as individual lines. This behaviour may be disabled (for future shell sessions) by adding the following line to your ~/.inpturc file:

set enable-bracketed-paste off

Bracketed paste mode is also disabled by default if the terminal is "dumb" or if you are using a release of the bash shell older than 5.0.

Different shells may have a different default value in $PS2. The zsh shell, for example, lets you know what command is currently not complete by dynamically updating the prompt:

$ function foo {
function> for arg do
function for>   print -r $arg
function for> done
function> }
$ foo 1 2 3
1
2
3

... while the bash shell uses a static > string:

$ function foo {
> for arg do
>   printf '%s\n' "$arg"
> done
> }
$ foo a b c
a
b
c

The nushell shell seems to use ::: as its equivalent to the secondary prompt in POSIX-like shells. However, the nushell shell does not even attempt to be a POSIX shell.

Unsetting the PS2 variable in bash would potentially lead to confusion. For example, if you think you have just invoked a long-running command but have in fact forgotten a closing quotation mark, you would not have any indication that the shell was waiting for you to complete the command.

Answer 2

The > is a Bourne Shell Variable known as the secondary prompt string.

From gnu.org:

Bourne Shell Variable

Bash uses certain shell variables in the same way as the Bourne shell. In some cases, Bash assigns a default value to the variable.

secondary prompt string, PS2

The secondary prompt string. The default value is ‘> ’. PS2 is expanded in the same way as PS1 before being displayed.

It can be suppressed using this command:

unset PS2

Inspired by https://superuser.com/a/1499801/217142

---

I did not work out why my shell introduced > as the secondary prompt string. However, as stated by Kusalananda, the problem I had was not to do with that (or installing nushell). Rather, the non-working for loop I mentioned was due to me inadvertently introducing tabs into the editor from which I was copying. This causes bash to interrupt the function definition with a display all X possibilities message.

To recreate the error, I should have posted:

function exampleFunc { 
        echo hello; 
}

Note the \s\t\t (space-tab-tab) before echo. When I was simplifying this for the question I failed to recognise the cause. A painful lesson!