Unable to use system envar. Unable to redefine $PATH

[Folco]

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

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

Code

$ 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 ?

[Jenna]

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:

       When 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.

[Folco]

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

[Folco]

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 ?

[oBFusCATed]

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).

[Folco]

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.

[oBFusCATed]

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.

[Folco]

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.

[oBFusCATed]

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

[Folco]

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

       -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...

[oBFusCATed]

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

[Jenna]

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.