Bug 591384 - getenv("TERM") returns NULL
Summary: getenv("TERM") returns NULL
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Community
Component: beah   
(Show other bugs)
Version: 0.5
Hardware: All
OS: Linux
low
medium vote
Target Milestone: ---
Assignee: Bill Peck
QA Contact:
URL:
Whiteboard:
Keywords: Regression
Depends On:
Blocks: 593663 593365
TreeView+ depends on / blocked
 
Reported: 2010-05-12 05:16 UTC by Caspar Zhang
Modified: 2013-07-03 07:24 UTC (History)
7 users (show)

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: ---


Attachments (Terms of Use)

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@redhat.com>) Lucas Rodrigues. Jeff Burke thought that he has addressed this situation and you could benefit from his experience.


Note You need to log in before you can comment on or make changes to this bug.