Important: Please read the Qt Code of Conduct -

Unable to use qgetenv to return the $TERM variable in the form of a QString.

  • I'm trying to use qgetenv to return the $TERM variable on arch linux.

    QString MainWindow::test()
       return qgetenv("TERM")
       // This does nothing at all.
    QString MainWindow::test_two()
       return qgetenv("USER")
      // This code correctly outputs my username   

    I have to assume that it's a permission issue, if so is there any other way to get this? If it's not a permission issue, does anyone know how to do this correctly?

  • Lifetime Qt Champion


    Are you sure that this environment variable is set ?

  • Yes, if I have echo $TERM in the terminal it returns xterm-256color.

  • Lifetime Qt Champion

    Are you starting your application from Qt Creator ? If so, did you check the environnement variables in the Run part of the Project panel ?

  • @SGaist I'm not really sure exactly what I should check. I went to tools->options->Environment the Terminal value is set to /usr/bin/xterm -e is there something else that I should be looking at?

  • Lifetime Qt Champion

    You can also check if there is an env variable with the given name with 'qEnvironmentVariableIsSet()'.
    Also maybe there is some other problem with your code - just print the return value of MainWindow::test() with qDebug.

  • Lifetime Qt Champion

    That's not at all where I was pointing you to.

    See here

  • @SGaist I'm currently working on the application so it is being started from Qt Creator. I don't know why I thought you meant that I guess I was just to frustrated lol. The variable TERM and or TERMINAL were not set. I did set them both, one for xterm and one for konsole, thank you guys for the help!

  • @Suroh6 said in Unable to use qgetenv to return the $TERM variable in the form of a QString.:

    I have to assume that it's a permission issue,

    You've already found your issue (trying to read a variable that wasn't set) but just as extra trivia, there's no specific permissions on individual environment variables like that.

    When your process is created, the environment variables are copied into your process's address space. So there's no calling into the kernel/OS through an API that could control access to specific variables based on permissions. The API's in libc for getting access to the environment variables run entirely inside your process, and you could re-implement them yourself if you were terribly bored. Because your process has its own copy of the environment when it starts, it can't see any changes to the parent process's environment that might happen while it is running, and you can freely change your own environment variables without altering the parent's environment.

    Your process was probably spawned with something like execve, and if you look up the docs for that, you can see how the parent process sets the environment inherited by the child process it creates:

    Seeing some of that plumbing may make the whole business a bit less mysterious the next time you are debugging some annoying obscure edge case. :) You always emerge from those kind of debugging sessions battered, bruised, and better educated.

Log in to reply