China
Africa
Explore chapters and articles related to this topic
Typical Workstation Environments
Published in Paul W. Ross, The Handbook of Software for Engineers and Scientists, 2018
A shell script is a text file of shell commands. Instead of typing in each command in the file separately, we store them in a file and execute them as a package. As a very simple example, suppose your documentation files are always named with one of the file extensions, “doc,” “bak,” “wp,” or “tex.” Now for any given directory, you could simply type the appropriate ls command to see what files of those type are stored there, or you could create a file that assumes that the current directory of interest has been stored in the variable WK. Thus we may create the file “ls.script” that contains the single line ls -l *.doc *.bak *.wp *. texThen instead of typing a long command line to see the files we want, we may type sh ls.script to accomplish the same thing. The command “sh” initiates a new copy of the Bourne shell (“csh” and “ksh” are the corresponding commands for the C and Korn shells, respectively) and, if a file name is specified, executes the commands in the specified file and exits.
Software development environment for collaborative research workflow in robotic system integration
Published in Advanced Robotics, 2022
Lotfi El Hafi, Gustavo Alfonso Garcia Ricardez, Felix von Drigalski, Yuki Inoue, Masaki Yamamoto, Takashi Yamamoto
Figure 2 gives an overview of the proposed SDE workflow: In a one-time step, the collaborator clones the source code on a new development machine from the remote Git repository hosted on GitLab and executes a Bash shell script to make the minimal required changes to the host system, mainly installing Docker.The collaborator then builds, or pulls from GitLab, the Docker image and runs a local copy of the Docker container that overlays the system environment with all the necessary dependencies and libraries.The collaborator enters the container and, if necessary, triggers the download large binaries required at runtime, such as trained models or input datasets, from OwnCloud.From inside the container, the collaborator can start working in a new Git branch.Next, the collaborator can compile the ROS workspace and operate the robot from inside the container for testing.If no major issue occurs, the collaborator pushes the new code to the remote Git repository on GitLab that automatically initiates a test pipeline on a dedicated GitLab Runner server set up for continuous integration by: Verifying the setup scripts by executing them in a Bash shell on a new virtual machine (VM).Building the Docker image from scratch in a new VM and push it to the container registry on GitLab.Pulling the freshly built Docker image from the container registry in a new VM, running a Docker container from it, and building the ROS workspace inside the container.Performing parallel unit tests and unattended simulations inside multiple container instances of the previously built Docker image.Tagging the Git source code and the Docker image as a release to be shared across all collaborators if the whole automated pipeline successfully exits.