Bug 1377494

Summary: script: closing stdin causes immediate exit of 'script' (but the child process runs in background)
Product: Red Hat Enterprise Linux 7 Reporter: Pavel Raiskup <praiskup>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.2CC: fweimer, jpazdziora, kdudka, praiskup
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:46:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1465901    

Description Pavel Raiskup 2016-09-19 21:38:25 UTC
For example:

    $ time script -q -e -c 'time sleep 1' 0>&-
    real    0m0.004s
    user    0m0.000s
    sys     0m0.003s
    $ 
    real    0m1.001s
    user    0m0.000s
    sys     0m0.001s

Doesn't happen on Fedora 24.  At least because there is '-e' used, this looks
like a bug rather than undefined behavior.

Comment 4 Karel Zak 2016-12-01 10:37:27 UTC
I have doubts that 0>&- is the right syntax to closes stdout.

See http://www.tldp.org/LDP/abs/html/io-redirection.html

0<&-, <&-
    Close stdin.

1>&-, >&-
    Close stdout.


RHEL-7:
  $ script -e -c 'time sleep 1' 1>&-
  script: write error: Bad file descriptor

the option -q hides the error message:

  $ time script -q -e -c 'time sleep 1' 1>&-

  real	0m1.011s
  user	0m0.003s
  sys	0m0.009s

So it works for me.

Comment 5 Pavel Raiskup 2016-12-01 10:48:59 UTC
You are right, sorry, there's typo in $Summary.

Comment 6 Pavel Raiskup 2016-12-01 10:53:30 UTC
Also this (from original report):
script -q -e -c 'sleep 3 ; echo why' /dev/null < /dev/null

Script for some reason loses control over it's child processes when one plays
a bit with stdin.  Seems to be fixed upstream.

Comment 8 Pavel Raiskup 2017-01-06 12:48:07 UTC
If there's no way to avoid closing stdin due to environment constraints,
can we mention here in bugzilla proper work-around?

Or do we have other command as an alternative to this feature ("simulate"
fully _working_ terminal with fd <= 2 opened)?

Comment 9 Pavel Raiskup 2017-01-06 13:04:23 UTC
(In reply to Pavel Raiskup from comment #8)
> If there's no way to avoid closing stdin due to environment constraints,
> can we mention here in bugzilla proper work-around?

Sorry, trying to better describe the motivation:  It is possible that
user's script is run in environment (shell) where stdin is closed (by shell);
for such situations it would be nice to have at least work-around.  Is this
the right way?

    #! /bin/sh
    command_with_closed_stdin ()
    {
      script -q -e -c 'sleep 1 ; test -t 2 && echo why' /dev/null </dev/ptmx
    }
    command_with_closed_stdin 0>&-

Comment 10 Jan Pazdziora 2017-01-06 15:29:40 UTC
Being the person who initially inquired about this topic, merely running the program I care about with

   < /dev/ptmx

without script did the trick for me.

Comment 11 Pavel Raiskup 2017-01-06 17:32:09 UTC
Yes, 'COMMAND 0>/dev/ptmx 1>/dev/ptmx 2>/dev/ptmx' makes the 'COMMAND' work,
but I'm not sure it is trivial record what's written to output.  Is it
possible without script?

This is often used for testing purposes, if 'TEST' tries to check that
'COMMAND' behaves differently with terminal attached and without attached
(e.g.  tar's testsuite used to have such test, dropped by 30fe67226a7cfc52
because of limited portability).

'TESTSUITE' running 'TEST' might be run with and without terminal, but results
for 'TEST' should be the same.

Comment 13 Karel Zak 2017-07-12 08:10:53 UTC
Maybe we can rebase script command for RHEL7.5 if the issue is really critical (important use-case).

Comment 16 RHEL Program Management 2020-12-15 07:46:01 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.