Code::Blocks Forums

Hi again, I still having a path problem...

System: Debian 6.
Some infos grabbed in an Xterm:

$ echo $SHELL
/bin/bash
$ echo $PATH
/home/folco/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/share/gcc4ti/bin
$ echo $TIGCC
/usr/local/share/gcc4ti

$TIGCC and the last path of $PATH are defined by myself in ~/.bashrc.
I have said to C::B that I want it to use /bin/bash as my shell.

I have defined 2 tools.

First one is very simple:
executable: xterm
working directory: ${PROJECT_DIR}
All work fine. When I call this tool, I get an Xterm, with the environment that I have defined in my ~/.bashrc


Second one is like that:
executable: xterm
parameters: -hold -e ./build.sh (header of build.sh: #!/bin/bash)
working directory: ${PROJECT_DIR}

My script contain an invocation to tigcc, which is located in the path defined in my .bashrc. It internally uses the variable $TIGCC defined in the same place.
The problem is that when my script is executed, tigcc is not found, because env vars don't seem to be defined at this moment.

I says that env vars are not defined at this moment because:
- if I execute ./build.sh with my first tool, it works, and I can see the vars if I echo them.
- if I add $TIGCC in Settings -> Environment -> Environment Variables, it works

So it acts like if my system variables were hidden at this moment, and I needed to redefine them internally to be able to use them.
Why are my system settings hidden ? What is wrong ?

If bash is invoked from a shell-script it does not read any bashrc-file (neither the global nor the personal one).
That's not a C::B-issue, it's bash-design.
You can try to create the variable BASH_ENV and let it point to your bashrc script:

Quote from: bash's man-pageWhen bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value
       as the name of a file to read and execute.  Bash behaves as if the following command were executed:
              if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
       but the value of the PATH variable is not used to search for the file name.

Impressive. How can you know all that ? Thanks a lot. I have done a lot of tries, but I didn't imagine that bash could be the cause of this behavior.
Now I have read the bash manpage, I will try two ways:
- use BASH_ENV
- source /etc/bashrc in /etc/profile

Many thanks again jens :)

Ok, problem solved here. Bash is complex, but interesting to learn.

I have a simple question : why does C::B want to use /bin/sh and xterm as defaut tool ? Why doesn't he use my SHELL and TERM configuration ?

Patches welcome, I guess :)

p.s. the TERM variable is hard to use in a generic fashion, be cause we are not starting an empty terminal, but we want to start an executable inside the terminal and all terminals have different options (unfortunately).

On the other hand, xterm is not installed on all systems.
Nevertheless, options -e and -T seems to be common : gnome-terminal, konsole, xterm, aterm, eterm for the terminals I tried. But I agree that it is far from an exhaustive list.

Have you tried them?
All the major terminals (xterm, gnome-term, konsole) require different options in my experience.

And as you know we give you a setting so you can change the terminal to be used, it is not hard coded to xterm.

Yes, I have used all the terms I quoted (and only the ones). I was talking about -e and -T options only.
And I modify C::B settings, I just didn't know why they weren't not set initially at the values of my account configuration.

Does it work with -e and -T for all terminals?
If I remember correctly gnome-terminal required -x instead of -e!

Both exist, but indeed, -x seems to be more like xterm's -e. But I never had to use -x.

Quote-e, --command=STRING
                 Execute the argument to this option inside the terminal.

       -x, --execute
                 Execute the remainder of the command line inside  the  termi‐
                 nal.

A solution would be to map a string to an argument for each supported shell.
Terminal -> Option
xterm -> -e, -T
gnome-terminal -> -x, -T
etc...

Yes, this is the correct solution, but someone should test and implement them:)

Quote from: oBFusCATed on September 11, 2011, 03:59:11 PM
Yes, this is the correct solution, but someone should test and implement them:)

and maintain them.

As long as xterm is available on all platforms the actual solution is good enough in my opinion.
Maybe a warning message, if the terminal execution has a non-zero value, and a hint where to set the correct terminal-emulator, should be shown.