Kinetic setup.sh script can conflict with aliasing . in the .bashrc

[robertcrowe-zz]

While trying to debug an install I discovered a conflict between setup.sh and an alias in my .bashrc that prevented the ROS_ environment variables being set. Moving the line to source setup.bash above the aliases in .bashrc fixed the problem for me, but to prevent conflicts in the future, setup.sh could use the "command" syntax:

% command ls -l

instead of:

% ls -l

See answers.ros.org

[dirk-thomas]

Can you please post the full path as well as the complete content of the file which contains ls -l.

[robertcrowe-zz]

"ls -l" was just an example of a Bash command. The files are any Bash scripts that should be run from .bashrc as part of initializing the environment, but in particular:

/opt/ros/kinetic/setup.sh

[dirk-thomas]

Can you please point to the specific commands being used which are resulting in problems with your local aliases.

[robertcrowe-zz]

In my .bashrc I have this alias (which I love):

alias .='ls -aF'

In setup.bash, it conflicts with this line:

. "$_CATKIN_SETUP_DIR/setup.sh"

which I think can be fixed like this:

command source "$_CATKIN_SETUP_DIR/setup.sh"

I think it's better to insulate scripts from whatever crazy aliases people (like me) may have, although I can see how it might be painful to make that change if the code is spread out.

[dirk-thomas]

Do I understand you correctly that you are aliasing the . command? And you change it to do something completely different? I understand to alias a command to a modified version to e.g. include some arguments but changing the semantic of the command seems "uncommon".

I don't see an obvious workaround which also works in sh (source doesn't work in bash). Since I won't have the time to work on this special case please consider to contribute a PR for this. Any change affecting the setup files will need to be thoroughly tested across platforms though.

[dirk-thomas]

I will close this for now since I don't think this is fixable across all shells. Please feel free to comment and it can be reopened if a clear path forward is known.