My X program sometimes must be started from console, but by default on Ubuntu the DISPLAY env var is not set. Is it correct to include DISPLAY=:0.0 startmyapp in the startup script, or how to deal with it otherwise? Who and when and how is responsible for setting this display variable properly? Why the environment is not out of the box ready for this once you install X or the desktop that includes X?
The DISPLAY variable controls the X session that the application communicates with. There can be many (or none) of these available at any given moment. You can't just statically set this value and have it necessarily be correct.
It is set correctly inside an X session (through the environment) and you can set it manually outside of that to use that same session (but you have to know which session you want to use for that).
If you know that will always be your session and you know that will always be the session you want to use then yes, you can just set it in the services startup script. Otherwise you need to come up with some other way to figure out which DISPLAY value you need.
Related
I am connected to our target over ethernet using the Linux TCF agent to debug an application.
I've used a lot of debuggers over my 25 year career, but this is my first time using Eclipse/Linux/Xilinx environment. I can set break points. I can single step through the code. I can view variables. I can view memory. I can type a new value in the memory location, but the variable value doesn't change. I tried to click or double click the value in the Variables pane. I tried right clicking to see if it would give me an option to modify the value.
I'm not sure what good a debugging tool is if I can't change a variable value to alter the execution path of my software...
In addition to the hacky solution we came up in the comments, which is to get the address of a variable and then modify them through the mr command from the xsct console, the same console provide commands to properly get/set a local variable.
The syntax is the following:
locals [options] [variable-name [variable-value]]
And an example:
locals my_int_var 10
locals my_float_var 1.4
I need to use a variable between node modules folder and src folder.Is there a way to use a variable to be used within the whole project?
Thanks.
Typically this is done with process environment variables. Any project can look for a common environment variable and handle that case accordingly, as well as the node modules of said project. As long as they agree on the name, they all share the same environment. Have a good default, don't force people to set this environment variable.
The environment can be set using an environment file (do not check this into source control!), on your container or cloud configuration, or even right on the command line itself.
TLOG=info npm test
That is an example that I use frequently. My project runs logging for the test cases only at alert level - there are a lot of tests so it makes the output less verbose. However, sometimes while developing I want to see all the logs, so my project is looking for an environment variable TLOG (short for "test logging") and I can set it just for that run! Also no code change is needed, which is nicer than JavaScript variables that need to be set back to original values, forget to be turned off, etc.
when configuring https for play framework, I have to use following configuration when running the background task.
play -Dhttps.port=9443 -Dhttps.keyStore=keystore.jks -Dhttps.keyStorePassword=password run
I don't want to display the keystore password on the command line. It shouldn't be visible for all users on that machine.
HTTPS configuration can either be supplied using system properties or in application.conf
I recommend to use a combination of environment variables and the application.conf
Put your sensitive information in environment variables
Reference these environment variables from the application.conf:
Like this:
https.keyStore = defaultvalue
https.keyStore = ${?MY_HTTPS_KEY_STORE_ENV}
The question mark means that if there is no value found for MY_HTTPS_KEY_STORE_ENV then the defaultvalue from above will be used
I'm trying to use the sshrc to execute fish with my own defined functions at the remote server.
I know there is a $fish_function_path variable that I can modify to prepend my custom path with my functions, but this variable seems global and I don't want to affect other fish users.
Is there any way to change this variable only for my single fish session or any other ways to use my fish functions only for a single session?
I have also tried setting and environment variable from the outer shell: fish_functions_path="$MY_FUNCTIONS_PATH" fish but it seems environment variables don't affect those inner variables of fish.
Used this docs.
Thanks!
Global variables, including $fish_function_path, are per-session. You might be thinking of universal variables, which are shared across sessions for a given user.
It should be fine to modify $fish_function_path for a given instance of fish - it won't affect any others.
I've been fighting with crontab recently because in Intrepid the gconftool uses a dbus backend, and that means that when used from crontab it doesn't work.
To make it work I have had to export the relevant environment variables when I log in so that it finds the dbus session address when the cron comes to run.
Out of curiosity I wondered what environment the cron could see and it turns out all I have is HOME, LOGNAME, PATH, SHELL, CWD and this new one on me, XDG_SESSION_COOKIE. This looks curious and several googlings have thrown up a number of bugs or other feature requests involving it but nothing that tells me what it does.
My instinct is that this variable can be used to find all the stuff that I've had to export to the file that I source before the cron job runs.
My questions, therefore, are a) can I? b) if so, how? and c) what (else) does it do?
Thanks all
This is very interesting. I found out it is the display manager setting a cookie. That one can be used to register processes to belong to a "session" which are managed by a daemon called ConsoleKit. That is to support fast user switching. My KDE4.2.1 system apparently supports it too.
Read this fedora wiki entry.
So this environment variable is like DBUS_SESSION_BUS_ADDRESS to give access to some entity (in the case of XDG_SESSION_COOKIE a login-session managed by ConsoleKit). For example having that environment variable in place, you can ask the manager for your current session:
$ dbus-send --print-reply --system --type=method_call \
--dest=org.freedesktop.ConsoleKit \
/org/freedesktop/ConsoleKit/Manager \
org.freedesktop.ConsoleKit.Manager.GetCurrentSession
method return sender=:1.1 -> dest=:1.34 reply_serial=2
object path "/org/freedesktop/ConsoleKit/Session1"
$
The Manager also supports querying for the session some process belongs to
$ [...].Manager.GetSessionForUnixProcess uint32:4494
method return sender=:1.1 -> dest=:1.42 reply_serial=2
object path "/org/freedesktop/ConsoleKit/Session1"
However, it does not list or somehow contain variables that is related to some cron job. However, documentation of dbus-launch says that libdbus will automatically find the right DBUS bus address. For example, files are stored in /home/js/.dbus/session-bus that contain the correct current dbus session addresses.