Ssh – Why don’t Page U/Down, Home/End work in less on Solaris over ssh from Ubuntu

I would disconnect the command from its standard input/output and error flows:

nohup python3 -u <script> </dev/null >/dev/null 2>&1 &  

ssh needs an indicator that doesn't have any more output and that it does not require any more input. Having something else be the input and redirecting the output means ssh can safely exit, as input/output is not coming from or going to the terminal. This means the input has to come from somewhere else, and the output (both STDOUT and STDERR) should go somewhere else.

The </dev/null part specifies /dev/null as the input for <script>. Why that is useful here:

Redirecting /dev/null to stdin will give an immediate EOF to any read call from that process. This is typically useful to detach a process from a tty (such a process is called a daemon). For example, when starting a background process remotely over ssh, you must redirect stdin to prevent the process waiting for local input. https://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash/19955475#19955475

Alternatively, redirecting from another input source should be relatively safe as long as the current ssh session doesn't need to be kept open.

With the >/dev/null part the shell redirects the standard output into /dev/null essentially discarding it. >/path/to/file will also work.

The last part 2>&1 is redirecting STDERR to STDOUT.

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!
What does > /dev/null 2>&1 mean? | Xaprb

PuTTY doesn't do that. It's a feature of xterm, and is one of many features of xterm not provided by PuTTY: sending different escape sequences depending on whether the Control and/or Shift key is pressed at the same time.

xterm-style modifiers for cursor keys are supported in ncurses by a extended terminal description (not part of conventional X/Open or SVr4 terminfo). However, PuTTY does not implement xterm-style modifiers in this case. For a long time, it used the Shift key to switch between normal and application modes for the cursor keys, and recently changed the modifier to the Control key:

commit 41e1a586fb956539a74bc446984a100e0138cd77                                 
Author: Simon Tatham                                          
Date:   Sat Dec 8 08:25:32 2018 +0000 

     - swapping the arrow keys between normal (ESC [ A) and application         
       (ESC O A) is now done by pressing Ctrl with them, and _not_ by           
       pressing Shift. That was how it was always supposed to work, and         
       how it's worked on GTK all along, but on Windows it's been done by       
       Shift as well since 2010, due to a bug at the call site of               
       format_arrow_key() introduced when I originally wrote that function.

but that did not change the escape sequence used. In the change comment, ESC [ A refers to the normal-mode up-arrow, and ESC O A to the application-mode up-arrow.

ncurses provides an accurate terminal description for PuTTY, but in this case the terminal description is irrelevant because bash uses hard-coded escapes in .inputrc (zsh does a little better, but also is lacking in this area--see the xterm manual). Even supposing that bash used the terminal description, the information is not available to bash because the terminal description's names cannot be read using a termcap application (such as bash). As mentioned, zsh is a little better, but it does not read extensions.

Using

infocmp -x xterm

you might notice kLFT5, kRIT5, kUP5, kDN5 (which are the names given to the control-modified cursor keys--all extensions), but you will not find those in the putty terminal description because PuTTY doesn't do that.