Score:3

How can I view the stdout / stderr from the bash login shell?

cn flag

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!

muru avatar
us flag
If there are, usually they'd be printed in the terminal in which you ran that shell.
stumblebee avatar
mx flag
@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.
muru avatar
us flag
@stumblebee new terminal tabs won't run login shells unless you configure your terminal emulator that way
stumblebee avatar
mx flag
@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.
vanadium avatar
cn flag
You could source the file in your current terminal: `source .bash_profile`
sancho.s ReinstateMonicaCellio avatar
Hi. Do you have any feedback on what was suggested? That is essential for the community.
Score: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
Score:0
mx flag

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

Score:0
cn flag

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

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.