Upon opening a new terminal I will get
-bash: ‘export: command not found
This line will only appear once then my base cmd line reappears.
I have read the other stackoverflow answers that seem similar but for some reason they get the error
-bash: ‘export: command not found
multiple times consecutively rather than just once.
I want to understand why this is appearing and if so what are likely causes. I am currently working on creating a website and had installed some of the requisite things like ruby but I do not know what specifically would have caused this.
The error message shows a U+2018 character ("LEFT SINGLE QUOTATION MARK"), i.e. a "smart quote".
This is likely coming from a .bashrc or .profile that's executed on Bash startup. Look for it next to an utterance of export.
Since it's not a script character (like a normal quote ') Bash is considering it to be part of the command name, and there is indeed no such command as ‘export.
I (believe) I am having an issue with the following PS1 not properly having an escape sequence:
\x1b[35mabc\x1b[0m \x1b[33mxyz\x1b[0m \x1b[34m\w\x1b[0m\$
The prompt looks okay until I begin to use historical command-lines and then bash seems to lose where the start of the line is. I thought that this stack overflow question would help, but I really don't know where my escape sequence is missing. Is it that I'm missing closing brackets? Also, I'm a little confused why I have \x1b instead of \.
Please help!
You're missing the brackets comletely (both opening and closing). Try using
\\[\x1b[35m\\]abc\\[\x1b[0m\\] \\[\x1b[33m\\]xyz\\[\x1b[0m\\] \\[\x1b[34m\\]\w\\[\x1b[0m\\]\$
That is, put \\[ and \\] around every escape sequence in the prompt.
My personal solution is to use a two-line prompt (so there's a \n in PS1) where the second line is short and has no escapes. So bash has no trouble figuring out how wide it is:
PS1='\033[0;31m[\h${debian_chroot:+($debian_chroot)}] \033[0;32m[\u] \033[0;33m[\w$(__git_ps1 " (%s)")]\033[0;39m\n --> '
In vi, the % key can be used to jump to a matching opening or closing parenthesis, square bracket or a curly brace.
Could it also be used to jump between matching "do" and "done" in a bash loop?
Not "vi" as such. vim does that.
There is a script matchit.vim which can do this:
The script is documented in the vim wiki page Moving to matching braces.
It part of the vim distribution, but is not installed (in your ~/.vim/plugin directory) by default. See the vim help for matchit-install for details.
Once installed, it has to be enabled, e.g., (see matchit.zip : extended % matching for HTML, LaTeX, and many other languages):
filetype plugin on
in your vimrc file.
For further reading:
Vim: Jumping to if endif in fortran uses simply runtime macros/matchit.vim rather than the two-part install from the vim wiki.
Matchit not working has several answers, some disagreeing.
The runtime macros/matchit.vim line in ~/.vimrc did not make matchit.vim work in my quick test; the procedure in matchit-install, plus the filetype line did work. As usual, your configuration may differ.
I maintain (and of course use) vi-like-emacs, and wrote comparable functionality for that editor using a different approach (see discussion of "fences" in documentation). In a quick test, I see that matchit.vim does not know about the syntax for case-values in a shell case statement. So there is some room for improvement.
I am trying to perform a simple for loop, but it keeps telling me there is a syntax error near do. I have tried to find some answers online, but nothing seems to be quite answering my question.
The for loop is as so. All it wants to do is find the differences between two folders:
#!/bin/bash
for word in $LIST; do
diff DIR1/config $word/config
done
exit
The syntax error is near do. It says "Syntax error near unexpected token 'do '". $LIST is set outside of this script by the program that calls it.
Does anyone know what might be happening here?
That's certainly valid syntax for bash so I'd be checking whether you may have special characters somewhere in the file, such as CR/LF at the ends of your lines.
Assuming you're on a UNIXy system, od -xcb scriptname.sh should show you this.
In addition, you probably also want to use $word rather than just word since you'll want to evaluate the variable.
Another thing to check is that you are actually running this under bash rather than some "lesser" shell. And it's often handy to place a set -x within your script for debugging purposes as this outputs lines before executing them (use set +x to turn this feature off).
One last thing to check is that LIST is actually set to something, by doing echo "[$LIST]" before the for loop.
I've done something to break my Bash Shell Prompt in OS X (10.5.7) Terminal.
This is the PS1 that I had configured:
PS1='\[\e[1;32m\]\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '
As far as I can tell I have the color commands escaping correctly. However when I scroll up and down in my command history I often get line wrapping issues if the historic commands wrap onto multiple lines.
I simplified my prompts to the following:
PS1='\[\e[1m\]\h:\w\$ \[\e[0m\]'
PS2='> '
And I still see something like:
localhost:~/Library/Application Support/Firefox/Profiles/knpmxpup.Defau
lt/extensions/{1A2D0EC4-75F5-4c91-89C4-3656F6E44B68}$ expocd \{1A2D0EC4-7
5F5-4c91-89C4-3656F6E export PS1="\[
\e[1;32m\]\h\[\e[0m\]: cd Library/Appl
ication\ Support/
I've also tried \033 instead of \e. I just included PS2 up there for information, I haven't changed that from the install default. If I completely remove the color codes then everything works fine, any ideas?
I am now using this PS1 with good effect:
green=$(tput setaf 2)
blue=$(tput setaf 4)
bold=$(tput bold)
reset=$(tput sgr0)
PS1="\[$green$bold\]\h\[$reset\]:\[$blue$bold\]\w\[$reset\]\$ "
Scrolling through my command history appears to handle line wraps now. However in the meantime since this question was asked I have also updated my OS X to 10.6.3
This stackoverflow thread seems relevant. As someone noted in that thread, the Bash FAQ at mywiki.wooledge.org discusses how to properly quote color codes in Bash prompts (FAQ 53), and the proper invocation of terminal colors (FAQ 37).
Line wrapping issues in Bash are nothing new. Your PS1 should work as is but there is a bug in Bash 3.2.49. Consult the mailing list, there's yet another bug regarding this which was confirmed to be fixed in 4.0.
You can't do much more than tagging unprintable characters with \[ and \], the rest must be done by the prompting code.
It seems that you have correctly escaped and enclosed sequences.
A workaround I use anyway it it to add a '\n' at the end. I find it clearer and lessen any problem with wrapping issues. The exact end of my PS1 is :
'\n\[\033[0;30m\]$\[\033[0m\]
An excellent howto you probably know :
Bash prompt howto
I noticed that there are some issues with the prompt cursor positioning even if there are no special character in the PS1 or PROMPT environment variable.
If we output a file that does not have a end-of-line char at the end. It will confuse the prompt.
You can reproduce this by doing:
curl https://gist.githubusercontent.com/martinos/d4aa0a7d4d752b0d0d9f/raw/3198c39f84a080c44227a084a19fb3a0bb661ee5/wrapping_issue.txt
and pressing the up key multiple times and you will see that the prompt get confused.
You can see an example of this in action:
https://asciinema.org/a/9mtjhi9dib6md4ocsbw210cca
When this occurs, just press <CTRL-C> and the prompt will come back to normal.
Note that ZShell does not have this issue.
For future reference, this is what I use:
export PS1="\[\033[0;31m\][\u#Project:\w]$\[\033[0m\] "
This would display my shell prompt as:
[ec2-user#Project:~]$
Helps me distinguish between live and dev sites.
Here's mine: it's the best one I've found, but the site where I originally found it was missing an escape character, leading to the line wrapping issue. I tinkered with it and finally got it working. It shows your user, path, and branch info with good contrast, color-wise.
export PS1='\[\e[1;37m\]\[\e[1;32m\]\u\[\e[0;39m\]:\[\e[1;33m\]\w\[\e[0;39m\]\[\e[1;35m\]$(__git_ps1 " (%s)")\[\e[0;39m\] \[\e[1;37m\]|\[\e[0;39m\]\$'
Also, add
GIT_PS1_SHOWDIRTYSTATE=true
To show a marker when a branch is "dirty" (changes to be committed exist)
export HISTCONTROL=ignoredups
Is also useful to ignore duplicates when scrolling up through bash history.
bind "set completion-ignore-case on"
Helps too.
Lastly,
shopt -s checkwinsize
May be helpful on OSX if issues persist.
'shopt -s checkwinsize' also works for Cygwin wrap problems also
If you're using the title bar trick "\e]2;titlebar\a", make sure to escape that too: "\[\e]2;titlebar\a\]"