How to fix minor glitch with BaSH prompt?

[Argy-Bargy]

Apologies in advance if this is the wrong forum. This is not a major problem, more an annoyance, but what really annoys me is I can't figure out how to mend it.

I have a pet BaSH prompt that has served me in good stead in a number of other Linux flavours, and in Mint as well, prior to v13. But under Maya, when I open a BaSH terminal window, it has picked up the odd habit of apparently attempting to execute the first file in the top line of the directory listing of my home directory, twice. Here's what it looks like:



I created the two screen shot images shown at the top of the listing with gimp after opening the terminal window but before executing the 'ls' command, which is why 'bootinfoscript' isn't at the top. If I were to close the window and reopen it, next it would show, "BaSH_prompt.jpg: command not found", twice.


To make change the prompt, I create a file named ".bash_ps1" in my home directory containing the following:

***************************************
# Fill with minuses
# (this is recalculated every time the prompt is shown in function prompt_command):
fill="--- "

reset_style='\[\033[00m\]'
status_style=$reset_style'\[\033[0;90m\]' # gray color; use 0;37m for lighter color
prompt_style=$reset_style
command_style=$reset_style'\[\033[1;29m\]' # bold black
# Prompt variable:

PS1="$status_style"'$fill \t\n'"$prompt_style"'${debian_chroot:+($debian_chroot)}\u@\h:\w\$'"$command_style "

# Reset color for command output
# (this one is invoked every time before a command is executed):
trap 'echo -ne "\e[0m"' DEBUG

function prompt_command {

# create a $fill of all screen width minus the time string and a space:
let fillsize=${COLUMNS}-9
fill=""
while [ "$fillsize" -gt "0" ]
do
fill="-${fill}" # fill with underscores to work on
let fillsize=${fillsize}-1
done

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
bname=`basename "${PWD/$HOME/~}"`
echo -ne "\033]0;${bname}: ${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"
;;
*)
;;
esac

}
PROMPT_COMMAND=prompt_command
***************************************


Then I was supposed to add this to my '.bashrc':

***************************************
if [ -f "$HOME/.bash_ps1" ]; then
. "$HOME/.bash_ps1"
fi
***************************************

Except that in Mint 13, there was no '.bashrc' -- anywhere -- not even in /etc/skel (which I don't recall being the case prior to v13) so I created one containing just these three lines. The pet prompt otherwise works as advertised, it just appears to be trying to execute the uppermost file in that directory every time it opens, and it's killing me I can't figure out why.


I didn't create this prompt, I just 'borrowed' it and I don't have a clue what most of these lines are on about. I have tried tweaking the ones whose function I do recognise, but I nothing I have tried has had the desired effect. So if you have bothered to read this far for the sake of my trivial little problem, I thank you, and ask what you think might correct this.

Any ideas?

EDIT:
It just occurs to me that there is a risk to not fixing this. I should through some strange stroke of luck leave a destructive executable in that directory. Not a great danger, granted, but if it should happen to be at the top of the listing, it wouldn't be good GNUs.

[nanowire]

Now that this problem has started occuring, does this still happen if you remove the lines from the ".bashrc" file and not display the prompt?

As a note, I'm on Mint 12 and there was no ".bashrc" file by default either.

[Argy-Bargy]

Using an empty .bashrc has the same effect as no .bashrc, the "error" doesn't appear, but then neither is there a custom prompt.

[Habitual]

Restore from backup.

[Argy-Bargy]

I've updated to Mint 14 (clean install) and, after "personalizing" the install, the quirk carried over:



The prompt still attempts to execute the first item in the directory listing (in this case, the directory 'Desktop') as a command, twice.

I've gone to school on what all the fiddly bits in the file ".bash_ps1" are but as yet haven't solved it.


These might be legacy files but there remain a few bashrc templates in Mint 14, specifically at /usr/share/doc/adduser/examples/adduser.local.conf.examples/skel/dot.bashrc, /usr/share/doc/adduser/examples/adduser.local.conf.examples/bash.bashrc, /usr/share/base-files/dot.bashrc, and /etc/bash.bashrc. I've been through them as well and found nothing relevant.



Any ideas?

[nanowire]

I've gone to school on what all the fiddly bits in the file ".bash_ps1" are but as yet haven't solved it.

This is a really odd problem, as I copied the code for both files in your original post and used it on my system and it works flawlessly. So the code isn't an issue assuming the code you posted above is an exact copy of what you have on your system. Do you have anything else in your .bash_ps1 or .bashrc other than those two code segments?


Also perhaps try running those files via bash debug and verbose, what is the output of those..

Code: Select all

bash -x -v ~/.bashrc

Code: Select all

bash -x -v ~/.bash_ps1

Also you can try running bash in verbose mode... If you are using the default terminal app, edit your current terminal profile preferences and enable 'Run a custom command instead of my shell', and use the command '/bin/bash -v'

Then open up a new terminal and type 'ls'. What comes up? My output looks like this, does yours show anything odd?...

Code: Select all

rob@memory-core:~$ ls
ls
echo -ne "\e[0m"
Desktop Pictures etc...
prompt_command
echo -ne "\e[0m"
basename "${PWD/$HOME/~}"
------------------------------------------------------------------------------------------ 11:55:50
rob@memory-core:~$


[Argy-Bargy]

The problem was the infamous ID-10-T error.

I maintain a text file with all my Mint configuration tweaks in it and I use lines of asterisks to separate the individual tweaks. What I posted above was in fact a cut-n-paste from the actual configuration file, but I excluded the lines of asterisks -- which I had transfered to the ".bash_ps1" file -- because I ASSumed they were inconsequential.

When I read your reply, nanowire, that put me to thinking the there must be some difference in my configuration that's causing the problem, so I finally swallowed my pride and tried it with the row of asterisks removed. That fixed it. I obviously am not so script-savvy as I thought.

Thank you for your help, nanowire.

[nanowire]

Glad you figured it out. I just assumed that the asterisks were there to separate the code for the forum post. For future reference though, as a script separator, ####### works well, as the # is used to comment out code in bash scripts, so having them as a separator would not cause any weird effects like the **** apparently did.