so-called-hang-on-exit

[Jim Knoble]

Circa 2002-08-07 16:54:49 -0700 dixit Frank Cusack:

: Great, so OpenBSD ** guarantees ** data loss in the pty case.  Ben,
: et al, this should be a no-brainer: put in the patch, making data
: loss *optional* on other OSes.  The patch I posted seems to be the
: simplest complete patch.
: 
: Or it may just be a shell difference.  (bash doesn't send hup, csh
: does) Jim, can you do this with bash on OpenBSD and see if it goes
: "forever"? Oh, I see it *is* a Bourne shell.  Is that some other
: Bourne-like sh or is it actually bash?

Hmm ... good question.  That was my own login, so it was bash-2.05a.
Here's several sets of tests with different shells:

    $ uname -svrm
    OpenBSD 3.1 GENERIC#1 i386
    $ 
    ----------------
    $ ssh binsh at localhost 'echo $SHELL'
    /bin/sh
    $ ssh -t binsh at localhost 'yes & exit'
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    binsh    17842 87.0  0.4    20   272 p7- R     12:43AM    0:10.98 yes 
    $ sudo kill 17842
    $ sudo kill 17842
    kill: 17842: No such process
    $ ssh -t binsh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ls -li /bin/sh /bin/ksh
    5803 -r-xr-xr-x  3 root  bin  307200 Aug  1 00:28 /bin/ksh
    5803 -r-xr-xr-x  3 root  bin  307200 Aug  1 00:28 /bin/sh
    $ 
    ----------------
    $ ssh ksh at localhost 'echo $SHELL'
    /bin/ksh
    [jmknoble at golem:~]
    $ ssh ksh at localhost 'echo $KSH_VERSION'
    @(#)PD KSH v5.2.14 99/07/13.2
    [jmknoble at golem:~]
    $ ssh -t ksh at localhost 'yes & exit'
    [jmknoble at golem:~]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ssh -t ksh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ 
    ----------------
    $ ssh csh at localhost 'echo $SHELL'
    /bin/csh
    $ ssh -t csh at localhost 'yes & exit'
    [1] 10493
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    csh      10493 92.6  0.4    20   272 p7- R     12:45AM    0:08.10 yes 
    $ sudo kill 10493
    $ sudo kill 10493
    kill: 10493: No such process
    $ ssh -t csh at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second, presumably with a job ID that scrolled offterminal]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    csh      13662 89.3  0.4    80   272 p7- R     12:46AM    0:17.41 yes 
    $ sudo kill 13662
    $ sudo kill 13662
    kill: 13662: No such process
    $ 
    ----------------
    $ ssh -t bash at localhost 'echo $SHELL'
    /usr/local/bin/bash
    $ ssh -t bash at localhost 'echo $BASH_VERSION'
    2.05a.0(2)-release
    $ ssh -t bash at localhost 'shopt huponexit'
    huponexit       off
    $ ssh -t bash at localhost 'yes & exit'
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ ssh -t bash at localhost 'yes & sleep 1; exit'
    $ ssh -t bash at localhost 'yes & sleep 1; exit'
    y
    y
    y
    [etc., for 1 second]
    $ sleep 5; ps auxwww |fgrep yes |fgrep -v fgrep
    $ 

So:

    /bin/sh is really pdksh @(#)PD KSH v5.2.14 99/07/13.2.
    /bin/ksh is also pdksh (but behaves slightly differently).
    /bin/csh looks like it's the regular BSD csh.
    /usr/local/bin/bash is bash-2.05a.

Bash is particularly interesting, because it differs from the following
one on my Linux system:

    $ echo $BASH_VERSION
    2.03.8(1)-release

in one significant way.  Both versions of bash agree on what startup
files they read under which circumstances:

  INVOCATION
       [...]
       When bash is invoked as an interactive login shell, or  as
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^
       a  non-interactive shell with the --login option, it first
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       reads and executes commands from the file /etc/profile, if
       that  file  exists.  After reading that file, it looks for
       ~/.bash_profile, ~/.bash_login, and  ~/.profile,  in  that
       ^^^^^^^^^^^^^^^^
       order,  and reads and executes commands from the first one
       that exists and is readable.  The --noprofile  option  may
       be  used  when the shell is started to inhibit this behav­
       ior.

       [...]

       When  an  interactive  shell  that is not a login shell is
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       started, bash reads and executes commands from  ~/.bashrc,
                                                      ^^^^^^^^^^^
       if  that  file exists.  This may be inhibited by using the
       --norc option.  The --rcfile file option will  force  bash
       to   read  and  execute  commands  from  file  instead  of
       ~/.bashrc.

So, since 'ssh -t bash at localhost <command>', doesn't execute a login
shell, i need to use ~/.bashrc to set the 'huponexit' option.

However, the definition of interactive differs between the two
versions.

For bash-2.03 (on Red Hat Linux 6.2):

       An interactive shell is one whose standard input and  out­
       put  are  both  connected  to  terminals (as determined by
       isatty(3)), or one started with the -i option. [...]

For bash-2.05a (on OpenBSD-3.1):

       An  interactive  shell  is  one started without non-option
       arguments and without the -c option whose  standard  input
       and  output are both connected to terminals (as determined
       by isatty(3)), or one started with the -i option. [...]

Since 'ssh -t bash at localhost <command>' uses the '-c' option to run
<command>, i'm unable to set the 'huponexit' option under bash-2.05a,
unless i do so inside <command>.

Nevertheless, bash-2.05a does the "right thing" on my OpenBSD system.

Fun.

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 262 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020808/064b0ee0/attachment.bin