Bug 591384

Summary: getenv("TERM") returns NULL
Product: [Retired] Beaker Reporter: Caspar Zhang <czhang>
Component: beahAssignee: Bill Peck <bpeck>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 0.5CC: bpeck, dkovalsk, kbaker, mcsontos, mrodrigu, qcai, rmancy
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-09 21:06:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 593663, 593365    

Description Caspar Zhang 2010-05-12 05:16:30 UTC
Description of problem:

I have a test which requires to get TERM env in c program, it should return a "xterm", "linux" or other valid values, but in beaker, I only got a NULL. (In old RHTS, it returns "linux")

The simple test program is:

#include <stdio.h>
#include <stdlib.h>

int main()
{
        char *strenv;
        strenv = getenv("TERM");
        if (NULL == strenv)
                printf("can't get env of \"TERM\"\n");
        else
                printf("TERM=%s\n", strenv);
        return 0;

}

In RHTS, it returns "linux": http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=156618&type=Single

In Beaker, it returns NULL: https://beaker.engineering.redhat.com/jobs/307

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. use a simple test in cvs: /kernel/distribution/ltp/debug
2.
3.
  
Actual results:
getenv("TERM") returns NULL

Expected results:
getenv("TERM") returns a valid value.

Additional info:

Comment 1 Marian Csontos 2010-05-25 13:16:48 UTC
This is caused by diffences between legacy RHTS and new harness.

The old tests were nothing more but a script, which was executed at boot time according to it's init.d "record".

However, the new harness runs as a daemon and the process does not have a PTY attached and in most cases such PTY would be useless.

The daemonized version has e.g the advantage of being able to connect to console and login, while the test is running to see what's going on, even when the network is down.

Should I create a PTY by default anyway just to keep it backwards compatible?
Should I simply set the TERM variable without creating a PTY?
Any better option?

/me is going to ask at tech-list.

Comment 2 Marian Csontos 2010-06-07 08:17:51 UTC
Fixed in git: http://git.fedorahosted.org/git/?p=beah.git;a=commit;h=8af808c13c6ff8222cbbb7d409c4f0e22e567f4b
Version: beah-0.6.3-1 in brew/koji.
Verified: J:2226

Comment 3 Kevin Baker 2010-06-10 00:41:14 UTC
(In reply to comment #2)
> Fixed in git:
> http://git.fedorahosted.org/git/?p=beah.git;a=commit;h=8af808c13c6ff8222cbbb7d409c4f0e22e567f4b
> Version: beah-0.6.3-1 in brew/koji.
> Verified: J:2226    

Marian,

can you talk to Auto-Test maintainer lmr (<mrodrigu>) Lucas Rodrigues. Jeff Burke thought that he has addressed this situation and you could benefit from his experience.