1

I have run across an issue that I just cannot seem to figure out. When I start my terminal in ubuntu (14.04) I get the message

sdfsdfsdi: command not found

As you can see it just looks like someone (maybe myself) was banging the keyboard in frustration and then accidentally wrote to some script that bash reads on initialization. The problem is I cannot for the life of me find what script bash is reading when it encounters this gibberish. I've looked in

~/.profile
~/.bashrc
~/.bash_profile
/etc/profile
/etc/bash.bashrc

and none of them seem to have the gibberish phrase. Are there other locations that bash reads from on startup that I can check?

Thanks!

Andrew

(Note this is not a critical issue, more of just a minor annoyance).

Improve this question
3
  • One way to figure it out would be cd / && sudo grep -r "sdfsdfsdi" though I won't claim it's the best way
    – Mitch
    Oct 16, 2014 at 19:27
  • 1
    The files you list may each source more files. You'll have to expand your search accordingly.
    – glenn jackman
    Oct 16, 2014 at 19:27
  • Also check the command which gnome-terminal executes to start a bash session.
    – s3lph
    Oct 16, 2014 at 19:30

2 Answers 2

Reset to default
1

To find which commands bash runs on start-up and which file those commands came from, run:

PS4='+$BASH_SOURCE> ' BASH_XTRACEFD=7 bash -xl 7>&2

The output is lengthy but the source of the gibberish will hopefully be clear.

Explanation:

  • PS4='+$BASH_SOURCE> '

    When creating an execution trace, bash will prepend every line with an expansion of PS4. Here, we make PS4 display the source file that is being read.

  • BASH_XTRACEFD=7

    This sends the execution trace to 7 which is a file descriptor chosen in hopes that it is one that the bash start-up files will not mess with.

  • bash -xl

    This starts bash with the options -x, which causes all commands to be displayed with the PS4 prompt, and -l which instructs bash to treat this like a login shell. If you don't get gibberish on login shells, then try it without -l.

  • 7>&2

    This redirects the trace output back to stderr for display on the terminal.

Three Refinements

Based on Geirha's comment, this version adds three improvement:

PS4='+ $BASH_SOURCE:$LINENO:' BASH_XTRACEFD=7 bash -xlic ""  7>&2

There are three refinements here: (1) the PS4 prompt now also displays the line number as well as the file name, (2) the -i flag makes the shell interactive, in addition to -l which made it a login shell, and (3) -c "" causes the shell to exit after initialization is complete.

Improve this answer
3
  • I usually recommend PS4='+ $BASH_SOURCE:$LINENO:' bash -xlic "" for debugging the initialization files.
    – geirha
    Oct 17, 2014 at 7:05
  • @geirha I like it! I merged the improvements from your version with trace output redirection and added it to the answer.
    – John1024
    Oct 17, 2014 at 7:26
  • Thanks guys, this worked out. It turns out it was coming from the git completion script in /etc/bash_completion.d/git-completion.bash. Which is odd because I know that I never edited this file so it must have sneaked in there some other way. I also really like how you explained everything John! It was very helpful.
    – Andrew
    Oct 17, 2014 at 13:14
0

It's invasive, but you can use the oldest debugging technique in the book: print stuff to mark where things are going wrong:

sudo tee -a /etc/profile <<<'echo /etc/profile'
sudo tee -a /etc/bash.bashrc <<<'echo /etc/bash.bashrc'
tee -a ~/.profile <<<'echo ~/.profile'
tee -a ~/.bashrc <<<'echo ~/.bashrc'
tee -a ~/.bash_aliases <<<'echo ~/.bash_aliases'
bash -l

That will narrow down the region where the garbage is, and then you can focus your search.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .