Is there a way to enable syntax highlighting in Cygwin such as blue for directories, green for files, etc?
I would ideally use puttycyg, but I am getting a cygwin1.dll not found error, then receiving an x0000007b error when the cygwin1.dll is copied into the puttycyg folder.
Thanks
Font colors and directory colors can be set making changes in user shell profile. So if you are using bash shell then you can make changes in .bashrc.
Check this sample here http://tldp.org/LDP/abs/html/sample-bashrc.html
Put this in your .bashrc:
alias ls='ls --color=auto'
Then you can either check/set colors in the /etc/DIR_COLORS file, or if you want to override those colors in .bash_profile, add these lines:
LS_COLORS="di=31;1:ln=36;1:ex=31;1:*~=31;1:*.html=31;1:*.shtml=37;1"
export LS_COLORS
Related
I use the python formatter Black, but when I switched to zsh it stop working. Every time I try to use it manually through the terminal I get zsh: command not found: black
I have it installed here /Users/HBrovell/Library/Python/3.7/bin/black and added to my .zshrc with export PATH="/Users/HBrovell/Library/Python/3.7/bin/black:$PATH"
What I'm missing here to get it to work?
You don't add black itself to the PATH; you add the directory containing black:
export PATH="/Users/HBrovell/Library/Python/3.7/bin/:$PATH"
I have a PS1 varible in bash_profile file as
orange=$(tput setaf 166);
yellow=$(tput setaf 228);
green=$(tput setaf 71);
white=$(tput setaf 15);
bold=$(tput bold);
reset=$(tput sgr0);
PS1="\[${bold}\]";
PS1+="\[${orange}\]\u"; # username
PS1+="\[${white}\]#";
PS1+="\[${yellow}\]\h "; # host
PS1+="\[${green}\]\w"; # working directory
PS1+="\[${white}\]\$ \[${reset}\]"; # '$' (and reset color)
export PS1;
When I open the new terminal instance it's showing everything properly except color.
But, when I execute the command
source .bash_profile
the color is working. It disappears if I open a new tab.
But, In a new terminal instance, without executing the source command,
the color works for
export PS1="\[\033[35m\]\t\[\033[m\]-\[\033[36m\]\u\[\033[m\]#\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$ "
[
What's the reason for this weird behavior?
In breif, in a new terminal session,
first PS1 is not displaying colors but the second ps1 put in the same bash_profile file is displying it.
But the first one is displaying colors when it is sourced.
Note: I am using mac.
I m also sure that the variable is getting set in bash_profile
but the color is not being set.
You should investigate a little more (yes even more).
In each case you should use printf "%q\n" "$PS1" to see the exact value of the variable PS1 (with escaped unprintable characters). Are you just trying to add the colors to an already set PS1 variable? So, if you get the uncolored output, could that be because your code just wasn't executed so the original value is still set? Then just the PROFILE script isn't executed.
.bash_profile typically only is executed when a login-shell is started. Nowadays many distributions don't get it right and are full of workarounds in this matter, so they often contain .bashrc files which source .bash_profile in their beginning. .bashrc is sourced for each new shell, so effectively, your .bash_profile might well be sourced for each shell as well.
I could guess that your .bashrc first sources .bash_profile and then sets the PS1 to a value like yours, just without the colors. But of course, that's guesswork.
I suspect in the OP's case that using ~/.bashrc rather than ~/.bash_profile to set the colours, is all that is required.
Here is how things work:
There are a number of files involved in setting up your bash environment.
/etc/profile sets the system-wide profile
~/.bash_profile, ~/.bash_login, ~/.profile - These are read by default when bash is invoked as a login shell
~/.bashrc - This is always read unless bash is invoked as sh or bash is invoked as bash --norc
~/.bash_logout - login shell cleanup
~/.inputrc - readline initialisation file.
Which files, and order that these files are read depends on exactly how bash is invoked.
There are a number of cases not all of which are mutually exclusive:
login shell
interactive shell
non-interactive shell
posix mode
bash invoked with stdin connected to network connection (yes
it will know)
bash invoked as sh
bash is invoked with the effective uid/gid not equal to the real uid/gid
You need to be aware of which cases apply to your invocation in order to determine which files will be read.
man bash and search for invocation, for the exact details.
I had installed solarized color scheme/theme for my xterm-256 terminal. It was the one causing the issue. When I change the color scheme, the PS1 is working perfectly.
I'm using Win10 with Ubuntu Linux installed with Bash.
I'm having trouble reading BASH multiple colors and want to switch it to monochrome color (2 colors) for easier reading.
I tried Google search and can't find the Ubuntu Bash command line for that.
If you only want to use two colors, we can add three lines to ~/.bashrc to achieve that.
We add three lines at the end of ~/.bashrc, like this:
$vi ~/.bashrc
rt LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ls='ls $LS_OPTIONS'
After add it completed, we exit this bash to flush it, then login this bash, here is my result:
Also, if you want to set other colors, we can follow this link to do it.
Here a similar case about you, please refer to it.
Update:
We can use CMD to open ubuntu bash, like this:
I am trying to define some aliases in cygwin, but with no success. I am doing so like this at the end of the .bashrc file.
alias foo='pwd'
I have tried to add this line in a .bashrc file in both inside the home folder of cygwin and in the home folder for the Windows user I am on C:\Users\Nuno\. In both cases I have just appended this line to a copy of the /etc/skel/.bashrc file. In either cases, it didn't work.
I had this working before. I had to reinstall Cygwin and ever since it never worked properly again. I have removed all files (or at least think so, when doing the reinstallation). I have also noticed that in the first install (when it was working) cygwin already was creating .bash files in the home folder. Now, it doesn't.
I am on a machine running Windows 7.
EDIT: My cygwin home folder is set to the Windows home folder C:\Users\Nuno\. I have placed what I think is a valid .bashrc file there, but it still doesn't work.
Thanks in advance.
As me_and already explained what's going on I just want to add a workaround should you for whatever reason not be able or willing to remove Windows' HOME environment variable.
Normally the shortcut for Cygwin executes
C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico -
Instead you can create a batchfile with the following content and start that:
#echo off
set HOME=
start C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico -
That will start a a Cygwin windows whose home directory settings are not overridden by a Windows environment variable.
Your .bashrc file will be loaded from wherever Cygwin Bash thinks your home directory is when it starts. You've mentioned in your edit that you've changed your home directory, but not how, so it's possible you've made a mistake there.
Cygwin will load your home directory from one of two places, and if they differ it can cause problems:
The HOME environment variable. This will be picked up from however you launch Cygwin, so normally from Windows itself. You can see what environment variables you have defined by pressing Win+Pause, going to "Advanced system settings", "Environment Variables…". If "HOME" is in either "User variables" or "System variables", delete it – it's unnecessary and only causes problems.
Cygwin's /etc/passwd file (normally C:\Cygwin\etc\passwd from Windows). This will have a number of lines containing details of each user on the system; the seventh : separated field is the home directory. You can tell which user it's looking at by running whoami from a Cygwin bash shell.
If whoami reports nunos, you should have a line in Cygwin's /etc/passwd that looks something like the following:
nunos:unused:1001:513:U-System\nunos:S-1-2-34-567890-123456-7890123-1001:/home/nunos:/bin/bash
It's that /home/nunos that's important; if it's something different you should probably reset it to that, at which point you want to use the .bashrc in Cygwin's /home/nunos/.
You should also be very wary of directories that contain spaces for this. C:\Users\nunos should be fine, but beware in particular C:\Documents and Settings\nunos, which just won't work with Cygwin.
I had the same issue, where the aliases added to ~/.bashrc didn't work.
It seems that, for some reason, the ~/.bashrc was not executed when launching the console.
I stumbled upon a response that fixes the issues
So, you need to create a .bash_profile file. This one seems to be the default script, and put this code in it, to ensure that the .bashrc is executed.
# ~/.bash_profile: executed by bash for login shells.
if [ -e /etc/bash.bashrc ] ; then
source /etc/bash.bashrc
fi
if [ -e ~/.bashrc ] ; then
source ~/.bashrc
fi
That works for me, just make sure that .bash_profile is executable. (chmod +x ~/.bash_profile)
Here's a really quick and dirty way to do it, but it works fine for most things!
Let's say you want to always run 'ls --color' instead of just 'ls'. Instead of messing around with .bashrc stuff, you can create a simple .bat file that essentially bootlegs the original ls command.
Here's what I did:
cd /bin
echo ls2.exe %* --color > lsNew.bat
mv ls.exe ls2.exe
mv lsNew.bat ls.bat
So now, whenever you type in ls from CMD, you actually are calling ls.bat, which in turn calls ls2.exe --color, the original ls command with the --color flag, along with the rest of the arguments, which are nicely passed through %*.
I had the same problem, but I was using ConEmu to run my console. I had to go into settings and change the settings from this :
set CHERE_INVOKING=1 & %ConEmuDrive%\Programs\Cygwin\bin\sh.exe --login -i -new_console:C:"%ConEmuDrive%\Programs\Cygwin\Cygwin.ico"
to this:
set HOME= & set CHERE_INVOKING=1 &
%ConEmuDrive%\Programs\Cygwin\bin\bash.exe --login -i
-new_console:C:"%ConEmuDrive%\Programs\Cygwin\Cygwin.ico"
Then it would work correctly.
It works as explained from cygwin:
Create a file ".profile" in your windows home dir. This will load every time when you start cygwin.
You can edit the file with your alias or you can source the .bashrc.
If you'll source, insert "source .bashrc" and save .bashrc also in your windows home dir.
Now you can start editing the .bashrc.
This is working for me On windows 10 with Cygwin64. Don't worry "kubectl" is just the program that I want to run when I type "k". restart Cygwin terminal after the change.
Smith#NB-Smith-3 ~ echo "alias k=C:/Users/Smith/kube/kubectl" >> $HOME/.bash_profile
changes this file
C:\cygwin64\home\Smith.bash_profile
I had same problem is why the path not is correct, the path correct is: D:\C++\cygwin\home\USER_WINDOWS.bash_profile
I cannot see any syntax highlighting in any language (e.g. python, c++ and sh) when I use vim within a screen session. The line numbers are in color though.
I precise that my terminal (in screen too) is able to show 256 colors schemes (I tested with the 256colors perl script found here: http://frexx.de/xterm-256-notes/ ).
How can I fix that?
OK, here is the issue/solution:
I used to call vim by using $vi, indeed:
$ which vi
alias vi='vim'
/usr/bin/vim
But:
$ screen
$ which vi
/bin/vi
I just learnt that screen doesn't load this system level alias which is tricky.
I had this problem. In my case, I was running a version of screen from brew. brew doesn't use ~/.screenrc as its startup file. So there's two solutions to this.
1) Set your term in the screenrc that brew_screen is expecting. This might be /opt/etc/screenrc. I didn't try this method, so I'm not sure.
2) Make an alias for screen that sets the term to what you want it to be. In this case, screen-256color is sufficient. I added the following line to my bash_profile, which is symlinked to my bashrc (mac problems):
alias screen='screen -T screen-256color'