0

I've got an electron/node application (editor) that uses a bunch of system commands to interact with a bunch of projects on my computer. So in short, when my application needs some information about those projects (for those interesed, rospack and rosrun), it performs a system command (with node's child_process and exec/execSync). The return code and stdout are then formatted an displayed in the editor. So far so good.

For these commands to be used a certain bash file needs to be sourced. I don't understand why completely but I think mostly because it adds some stuff to the path and it sets two other environment variables that the commands use. I am not entirely sure though; there might be some bash/terminal specific black magic in there (when I don't source the bash and execute the command with an absolute path, it complains about a .so not being present) but it's very hard for me to find out (for those interested, it's the setup.bash script from ROS).

Sourcing the bash file usually is no problem; most of my friends and I have it in our .bashrc so when we launch the editor from the command line it finds the commands and the editor runs smoothly. However, if you launch the application by double-clicking, my .bashrc is not being sourced (as far as I have been able to tell from eyeballing the internet) . Therefore it cannot find the commands when launched by doubleclicking.

Launching the editor from the command line is acceptable, but I'd like it to be as smooth as can be. So my question is: is there a way to source this bash file before my double clicked application is launched? Things I have tried:

  • Ubuntu desktop file in various forms:
    • Exec="bash -c 'source the_bash.sh; ./editor'"
    • Exec=source_bash_and_start_editor.sh
    • Obviously also Exec=./editor, but that certainly didn't work
    • I've also been having problems with relative paths in the desktop file. With absolute paths it seemed to work (with the second and third approach above), but that's not an acceptable solution since I cannot hardcode the paths.
  • Making bash script that sources my .bashrc and then executes the editor double-clickable.
    • This would probably work (not entirely sure though), but then I would have to change some system settings to make the bash script double-clickable. By default double clicking opens the script in a text editor, and I would like to avoid that since everyone is used to that.
  • A bash script that sources my .bashrc and then executes the editor. This script is executed by the system() C command in a small executable that I could ship with the editor.
    • I think in this case it can actually execute the command, but then the command can't find the .so file. So it seems that the sourcing happened incorrectly/incompletely.
  • Sourcing the bash file in my node exec/execSync calls (i.e. source ~/.bashrc; rospack ... or . ~/.bashrc; rospack ...)
    • node simply said "command not found" or something along those lines

For context, I'm using Ubuntu 16.04, and the Electron version I'm using is v1.4.13.

bobismijnnaam
  • 1,361
  • 2
  • 10
  • 20
  • I think you are confused. `bash -c source the_bash.sh` and `source_bash_and_start_editor.sh` are themselves just shell scripts. You could run each independently after you start a terminal. If both are required, you could simply create a script containing those two command (and include the `$!/bin/bash` first line). Then just run that script (or you could launch it at the end of your `.bashrc`. However, if it actually sources your `.bashrc`, don't call it from your `.bashrc` or you will create an endless recursive loop with your script sourcing `.bashrc` over and over again.. – David C. Rankin Apr 29 '17 at 09:06
  • I understand. The point is that neither make sure that the important bash file is sourced properly; i.e. in both cases the `rospack` command doesn't function properly. The editor can neither find the binary, nor can it find the `.so`. – bobismijnnaam Apr 29 '17 at 09:38
  • That is a problem with your `PATH` variable and likely your `LD_LIBRARY_PATH` environment variable. You can either add the *absolute path* to the location of your editor, or within your script `cd /path/to/your/editor/dir` and then run the scripts from there, which if the editor executable and the shared object file both exist in that directory, or if the *relative search path* for the shared object library is in the proper place below that directory, your editor should launch fine. You need to step though each command in your script to find where the error is (or `set -x` and run them) – David C. Rankin Apr 30 '17 at 03:55

1 Answers1

0

So by pure luck the answer I was looking for appeared in the stack overflow sidebar. The problem is explained here: source .bashrc in a script not working, and I'll explain how I solved it in my case.

So the problem was that every time I called source either in Node or in a C program, the source was always executed in the context of a non-interactive shell. To make it work you need to make sure that when the source command happens the context is an interactive shell, or at least it looks like one.

What I did was compile the following application:

#include <stdlib.h>

int main() {
    putenv("PS1=BobeTerm");
    system("bash -i -c \"source ~/.bashrc && ./editor\"");

    return 0;
}

The magic here is the bash -i -c "command" call, see the stack overflow question mentioned above for an explanation.

I place this executable in the same folder as the editor, and when I want to launch the editor I can just doubleclick this executable, which in turn launches my editor in the context of the source'd .bashrc. Problem solved! I get my environment variables in a machine independent way, and the user can now just double-click an executable to launch the editor!

Community
  • 1
  • 1
bobismijnnaam
  • 1,361
  • 2
  • 10
  • 20