Age | Commit message (Collapse) | Author | Files |
|
After recent changes to terminal.bbclass, variables like PATH were no longer
preserved within the devshell. This change ensures they are inherited into
the environment of devshell and PATH for example has the correct values.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If this isn't done, various terminals fail to launch correctly
with "No such file or directory" errors. This adds back the environment
manipulation removed in the addition of "custom" terminal command
support but shouldn't regress that additional functionality
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Example config:
OE_TERMINAL = "custom"
OE_TERMINAL_CUSTOMCMD = "mysuperterm"
Signed-off-by: Morten Minde Neergaard <mneergaa@cisco.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Passing the data store will be needed for firing a custom event
for the screen class.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some versions of the screen utility provided from the host OS vendor
write the socket directory to $HOME/.screen. When using a shared home
directory across many servers, one sets the SCREENDIR environment
variable to avoid collisions in the shared home directory. This
results in problems launching a devshell where it is not entirely
obvious what happened because the SCREENDIR environment variable
got stripped from the environment prior to setting up the screen
in detached mode.
Example:
% bitbake -c devshell busybox
# ...Please connect in another terminal with "screen -r devshell"
% screen -r devshell
There is no screen to be resumed matching devshell.
The temporary work around was to do something like:
sh -c "unset SCREENDIR; screen -r devshell"
This patch adds SCREENDIR to the white list to ensure screen
works properly on systems where a developer needs to use
the SCREENDIR with shared home directories.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently the environment handling for terminals is inconsistent. There
are two fixes here:
a) Ensure the environment is setup before all oe.terminal call
b) Actually set the environment before the spawn calls since we need
variables like DISPLAY when the commands are being executed, not just
within the terminal environment. If this doesn't happen, DISPLAY can end
up not set with the errors that brings with it when trying to run X
commands.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This should resolve the devshell issue people are seeing.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In the new implementation, each known terminal is defined as a class in
oe.terminal, as a subclass of bb.process.Popen. terminal.bbclass wraps this
functionality, providing the metadata pieces. It obeys the OE_TERMINAL
variable, which is a 'choice' typed variable. This variable may be 'auto',
'none', or any of the names of the defined terminals.
When using 'auto', or requesting an unsupported terminal, we attempt to spawn
them in priority order until we get one that's available on this system (and
in the case of the X terminals, has DISPLAY defined). The 'none' value is
used when we're doing things like automated builds, and want to ensure that no
terminal is *ever* spawned, under any circumstances.
Current available terminals:
gnome
konsole
xterm
rxvt
screen
Signed-off-by: Chris Larson <chris_larson@mentor.com>
|