3

I'm trying to debug a strange issue with my ~/.bash_profile, and I'd like to be able to see if there are any errors / etc printed when it's run. Is there some log or such somewhere that contains the stdout and/or stderr of the login shell process? Thanks!

The error only happens in the very first root login shell, not when re-executed or re-run in other contexts - it has something to do with that particular context / environment. So standard tricks of tee / piping output / etc from an invoking terminal don't work.

  • If there are, usually they'd be printed in the terminal in which you ran that shell. – muru Dec 02 '21 at 02:07
  • @muru I thought the same thing, I created a error in ~/.profile without the existence of ~/.bash_profile , the error message did not pass through. Check out my undeleted answer. – stumblebee Dec 02 '21 at 02:26
  • @stumblebee new terminal tabs won't run login shells unless you configure your terminal emulator that way – muru Dec 02 '21 at 03:23
  • @muru You absolutely correct sir! ~./.bashrc does but ~/.profile does not. I should have run sudo login. Ill reduce to my original answer and suck up the shame. – stumblebee Dec 02 '21 at 06:52
  • You could source the file in your current terminal: source .bash_profile – vanadium Dec 02 '21 at 08:34
  • Hi. Do you have any feedback on what was suggested? That is essential for the community. – sancho.s ReinstateMonicaCellio Dec 07 '21 at 09:38

3 Answers3

0

stdout and stderr will appear in the terminal everytime you do a login. You must log out and back in again for the changes in your profile to take effect. A further explanation of the use of ~/.bash_profile is provided here on Ask Ubuntu with a good answer

stumblebee
  • 3,547
0

Tbh I didn't try myself, but I'm pretty sure standard output and error are the terminal it's running on, as soon as the process starts. You can check by putting a command such as echo "Hello world" in your .bash_profile...

NovHak
  • 669
0

To debug a bash script you have several options, and some of these are even more effective than redirecting stdout/stderr.

Activate trace

You could add to your ~/.bash_profile (creating a trace only for specific parts of your script) with

set -x          # activate debugging from here
<commands>
set +x          # stop debugging from here

Also, set -v prints shell input lines as they are read, and set +v deactivates this. With this alone you will likely catch the problem.

Redirect trace

Use Bash Variable BASH_XTRACEFD

If set to an integer corresponding to a valid file descriptor, Bash will write the trace output generated when ‘set -x’ is enabled to that file descriptor. This allows tracing output to be separated from diagnostic and error messages. The file descriptor is closed when BASH_XTRACEFD is unset or assigned a new value. Unsetting BASH_XTRACEFD or assigning it the empty string causes the trace output to be sent to the standard error. Note that setting BASH_XTRACEFD to 2 (the standard error file descriptor) and then unsetting it will result in the standard error being closed.

So you would use

exec 5> ~/bash_profile_ouput.txt
BASH_XTRACEFD="5"
<commands>
unset BASH_XTRACEFD

Print line numbers

Use Bash Variable LINENO (and BASH_LINENO, BASH_SOURCE and/or FUNCNAME in more elaborate cases)

echo "Executing ${LINENO}"
<commands>

Redirect stdout/stderr

Combine command exec with redirection, and possibly tee. See answers here, which also include other methods/"tricks" than using exec.

Related:

  1. https://stackoverflow.com/questions/44249890/pipe-bash-stdout-only-in-debug-mode
  2. https://unix.stackexchange.com/questions/334382/find-out-what-scripts-are-being-run-by-bash-on-startup
  3. https://unix.stackexchange.com/questions/155551/how-to-debug-a-bash-script