In the vxWorks RTOS, there is a shell that allows you to issue command to your embedded system.
The documentation refers to kernel shell, host shell and target shell. What is the difference between the three?
The target shell and kernel shell are the same. They refer to a shell that runs on the target. You can connect to the shell using either a serial port, or a telnet session.
A task runs on the target and parses all the commands received and acts on them, outputting data back to the port.
The host shell is a process that runs on the development station. It communicates with the debug agent on the target. All the commands are actually parsed on the host and only simplified requests are sent to the target agent:
Read/Write Memory
Set/Remove Breakpoints
Create/Delete/Suspend/Resume Tasks
Invoke a function
This results in less real-time impact to the target.
Both shells allow the user to perform low level debugging (dissassembly, breakpoints, etc..) and invoke functions on the target.
There are some differences between host shell and target shell, you can use h command to get the actual commands the two shell support.
The host shell support more command line edit functions like auto complement and symbol lookup etc.
Related
I am trying to run sesu command in Unix server from Python with the help of Paramiko exec_command. However when I am running this command exec_command('sesu test'), I am getting
sh: sesu: not found
When I am running simple ls command it giving me desired output. Only with sesu command it is not working fine.
This is how my code looks like:
import paramiko
host = host
username = username
password = password
port = port
ssh=paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(ip,port,username,password)
stdin,stdout,stderr=ssh.exec_command('sesu test')
stdin.write('Password')
stdin.flush()
outlines=stdout.readlines()
resp=''.join(outlines)
print(resp)
The SSHClient.exec_command by default does not run shell in "login" mode and does not allocate a pseudo terminal for the session. As a consequence a different set of startup scripts is (might be) sourced, than in your regular interactive SSH session (particularly for non-interactive sessions, .bash_profile is not sourced). And/or different branches in the scripts are taken, based on an absence/presence of TERM environment variable.
Possible solutions (in preference order):
Fix the command not to rely on a specific environment. Use a full path to sesu in the command. E.g.:
/bin/sesu test
If you do not know the full path, on common *nix systems, you can use which sesu command in your interactive SSH session.
Fix your startup scripts to set the PATH the same for both interactive and non-interactive sessions.
Try running the script explicitly via login shell (use --login switch with common *nix shells):
bash --login -c "sesu test"
If the command itself relies on a specific environment setup and you cannot fix the startup scripts, you can change the environment in the command itself. Syntax for that depends on the remote system and/or the shell. In common *nix systems, this works:
PATH="$PATH;/path/to/sesu" && sesu test
Another (not recommended) approach is to force the pseudo terminal allocation for the "exec" channel using the get_pty parameter:
stdin,stdout,stderr = ssh.exec_command('sesu test', get_pty=True)
Using the pseudo terminal to automate a command execution can bring you nasty side effects. See for example Is there a simple way to get rid of junk values that come when you SSH using Python's Paramiko library and fetch output from CLI of a remote machine?
You may have a similar problem with LD_LIBRARY_PATH and locating shared objects.
See also:
Environment variable differences when using Paramiko
Certain Unix commands fail with "... not found", when executed through Java using JSch
I am a newbie to vxworks, and I have a target with Vxworks5.5, one application is running on it. I want to ping other host with local keyboard and monitor or telnet. After the ctrl+c is pressed, the task is going on after being interrupted for several seconds, and I can see >-,which means that it's now in C-interpreter mode. After PING command was entered, I was told that there's no such command.
I read the manual, and know that there is also a command mode. How can I switch to command mode and use the PING command?
VxWorks 5.5 has only C interpreter shell and does not support command shell.
Define INCLUDE_PING in configAll.h or in your Tornado project. Try -> ping "8.8.8.8"
VxWorks 6.x has C interpreter shell and command shell. Use cmd to switch to the command shell and C to switch to the C interpreter shell.
-> ping "8.8.8.8"
-> cmd
[vxWorks]# ping 8.8.8.8
[vxWorks]# C
->
If using VxWorks 6.x, switch to the command shell by entering cmd in the C shell. There, you can issue command help to list available commands. If ping is not present, you can add it via the workbench.
From the workbench, add component INCLUDE_IPPING_CMD and rebuild VxWorks on the target. Then you should be able to issue ping commands in the form ping 1.2.3.4 from the command shell. Typically, to use commands that are not included by default in the command shell, you'll need to add components to your VxWorks project in the form INCLUDE_CommandName_CMD.
Please note that this is an AIX related question.
I have a jenkins server running on Redhat which is running a node via SSH on an AIX server.
The commands are run non-interactively using SSH to a user on the AIX machine who has ksh as its standard shell.
The problem is that this build needs a number of environment variables, and i can't seem to get it to work.
I have tried:
Jenkins allows me to set some environment variables for the session. So i tried:
ENV="$HOME/.profile"
I tried creating a .kshrc file containing
. .profile
But none of these approaches seems to make KSH run the .profile script.
The .profile script contains the environment setup for the user i need.
How do i get an AIX implementation of KSH to run my .profile script before executing commands?
You need to specifically tell Jenkins that you want to execute them in ksh shell.
By default, Jenkins runs as sh <commands>.
Add a shebang in your shell command as first line,
#!/bin/ksh
Most shells don't source their .profile files on non-interactive sessions. A simple solution is to source the .profile yourself as part of the command you are sending.
So instead of
yourcommand1; yourcommand2
you should send
. ~/.profile; yourcommand1; yourcommand2
over ssh
UPDATE after reading the comment about Jenkins controlling the ssh command
In the case your ssh command is performed by Jenkins you should have a look at https://wiki.jenkins-ci.org/display/JENKINS/SSH+Slaves+plugin, especially the 'Login profile files' paragraph.
I'd say one of these solutions is best
Set all environment variables from Jenkins using the node's configure page. Install the EnvInject plugin to do this.
Write a wrapper around the java command on the slave that sources your profile script and adjust the JavaPath (also on the node's configure page) to point to that wrapper.
The only way I know of for setting environment variables that will apply for non-interactive shells on AIX is via /etc/environment. I believe this is the correct place, but it will of course then apply to all users and all shells.
I have condition that i have to flash multiple output files one by one to the mpc controller. We use GUI for lauterbach to do the flashing and running software. Now i want to do the same via >command line argument. Some one please explain me what all things are needed for controlling the lauterbach through command prompt.
I want to use Lauterbach Powerdebug interface/ usb2 for the debugging purpose.
You can remote-control trace32 via a UDP port using the t32rem command.
t32rem is typically installed in C:\T32\bin\windows64\
Your t32 configuration file (config.t32) must have "RCL=NETASSIST" in it.
And you need to enable the API port, either via the t32start options or in your custom xxx.ts2 (configuration file).
Out of the box you should then be able to run any t32 command. E.g.:
C:\T32\bin\windows64\t32rem.exe localhost port=20000 data.dump 100000
Replace "data.dump 100000" with anything T32 understands, e.g. "do pgm_my_flash.cmm"
You can also use telnet to remote control the debugger. NETASSIST must be set.
The vxWorks documentation states:
The WDB agent itself is independent of the target operating system: it
attaches to run-time OS services through a virtual-function run-time
interface. The WDB agent can execute before VxWorks is running (as in
the early stages of porting a BSP to a new board)."
How can I use the debug agent before the vxWorks kernel is running?
First, in order to be able to use the agent to perform pre-kernel debugging, you must have a serial port available for debugging. This serial port has to be initialized and functional as it will be the debug channel.
There is a limitation on how early you can start debugging. WDB based debugging will start after the first hardware initialization function runs (sysHwInit) and before the kernel initialization proper (kernelInit).
Depending on the version of vxWorks being used, there are different ways to achieve this result.
Workbench-based vxWorks builds
In the kernel configuration tool, you must select the following components:
WDB serial connection
WDB system debugging
WDB pre kernel system initialization
Depending on the order you select components, you might get complaints from workbench because some components are mutually exclusive (you can't have WDB END driver with pre-kernel debugging). The order above should be ok.
Command-line builds
Edit the config.h file, and select the following options:
#define WDB_INIT WDB_PRE_KERNEL_INIT
#define WDB_COMM_TYPE WDB_COMM_SERIAL
#define WDB_MODE WDB_MODE_SYSTEM
When vxWorks is compiled with those options, it will perform perform the first phase of hardware initialization and then suspend, waiting for the debug agent running on the host to connect to the target.
At that point, you can perform debugging, single step, etc...