Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to debug what bash does on login initialization for Linux. I've read that "bash -x" will make bash print out what it's doing, but it doesn't print commands in sourced files like "set -x" does. I can't use "set -x" because initialization runs before I can call it. "bash -x" seems to recurse fine on OS X, but that might be because of the bash versions.

Linux: 3.2.25

OS X: 3.2.48

Here's an excerpt of the non-recursing behavior on Linux:

bash -l -x -c 'echo 1'
# ... snip ...
+ for i in '/etc/profile.d/*.sh'
+ '[' -r /etc/profile.d/vim.sh ']'
+ '[' '' ']'
+ . /etc/profile.d/vim.sh
+ for i in '/etc/profile.d/*.sh'
+ '[' -r /etc/profile.d/which-2.sh ']'
+ '[' '' ']'
+ . /etc/profile.d/which-2.sh
# ... snip ...

Notice how /etc/profile.d/vim.sh is sourced, but its commands aren't printed. Is there a workaround without upgrading? Is this caused by the version difference?

share|improve this question

1 Answer 1

set -x somewhere in the root file (the one requiring all other files) should work. Alternatively, introduce something like [[ !-z "$DEBUG" ]] && set -x in each file, and call with DEBUG=1 script.sh.

share|improve this answer
    
Where is the root file? Is it platform independent? –  Kelvin Apr 19 '12 at 19:26
    
With "root file" I simply mean the file you are calling on the shell, and which is importing the other files. In my example, the root file would be script.sh –  mkaito Apr 19 '12 at 19:31
1  
But bash login initialization happens before the script is run. It's too late to run "set -x" in the script. Try it yourself - run "bash -l -x script.sh". You'll see stuff happening before your script's commands are run. –  Kelvin Apr 19 '12 at 21:41
    
Why on Earth would you run a script with bash -l? That's meant for interactive shells. A script is not an interactive shell. –  mkaito Apr 19 '12 at 23:09
1  
Please be a bit more open-minded - obviously the creators of bash thought it would be useful. I see 2 uses (at least): 1) You want to run ssh user@host 'bash -l -c command' so you get the proper env loaded. 2) You're a sysadmin and want to troubleshoot what init scripts are doing before your script runs - bash -l -x will show you. Sometimes you want to know where an env variable is being set. –  Kelvin Apr 23 '12 at 16:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.