It has something to do with having promptsubst set to on. See below:
[/Users/darren]# var="Testing...
dquote>1,
dquote>2,
dquote>3,
dquote>Testing..."
[/Users/darren]# setopt promptsubst
[/Users/darren]# echo $var
Testing...
1,
2,
3,
Testing...
[/Users/darren]# echo "$var"
Testing...
1,
2,
3,
Testing...
[/Users/darren]# unsetopt promptsubst
[/Users/darren]# echo "$var"
Testing...
1,
2,
3,
Testing...
[/Users/darren]# echo $var
Testing...
1,
2,
3,
Testing...
[/Users/darren]#
In this case, I set my prompt to something very simple, so that I was sure it wasn't a goofed up prompt, but my real prompt requires promptsubst be on for showing Git status. I've also noticed that it happens with something like echo $var | grep Test. Any ideas how I can fix this while still keeping promptsubst on?
I'm running zsh 4.3.11 and using Oh-My-Zsh if that helps?
Thanks!
I've figured it out. After testing it by disabling OMZ, I found out something in OMZ was the cause. I managed to narrow the issue down to the file libs/termsupport.zsh. It seems that there are issues with Terminal.app on Mac OS X and updating the tab titles. I've posted a fix to Github: https://github.com/darrenclark/oh-my-zsh/commit/8f89d4d5a5d584bae288d8111d83a6489a1369dc
Related
Some time ago I installed and used pyenv for a purpose I don't need anymore. Then, I uninstalled it. However, whenever I open up my terminal the first thing it prints is:
/Users/jcortizrh/.zshrc:1: command not found: pyenv
So it looks like my terminal is still trying to use pyenv. How can I fix this? I tried editing the .zshrc file but it looks complicated and I'm afraid of modifying it and ruining my terminal somehow.
EDIT: my .zshrc looks like this:
PATH=$(pyenv root)/shims:$PATH
# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/jcortizrh/opt/anaconda3/bin/conda' 'shell.zsh' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
eval "$__conda_setup"
else
if [ -f "/Users/jcortizrh/opt/anaconda3/etc/profile.d/conda.sh" ]; then
. "/Users/jcortizrh/opt/anaconda3/etc/profile.d/conda.sh"
else
export PATH="/Users/jcortizrh/opt/anaconda3/bin:$PATH"
fi
fi
unset __conda_setup
# <<< conda initialize <<<
Turns out that removing the first line from my .zshrc solves the issue. Thanks for the suggestions!
I'm not sure how that happened. I tried to create script, to work with some legacy solutions:
#!/bin/bash
echo "Enter pass"
stty -echo
trap 'stty echo' EXIT
read pass
stty echo
trap - EXIT
echo "Nice!"
command="
cd /home/user/work_dir &&
export GIT_PASSWORD=${pass} &&
do_some_stuff
"
ssh root#some_host ${command}
Unfortunately, I had to pass password through environment variable. I only hoped that shell with that variable will not live long. Also I wanted to execute this script like VS Code Task like this:
"tasks": [
{
"label": "Do_stuff",
"type": "shell",
"command": "${workspaceFolder}\\.vscode\\do_stuff.sh"
}
]
And I've achieved some success. BUT, now every time I hit 'w' key in VSCode powershell, instead of printing 'w', it pastes the content of clipboard. I tried to restart shell, restart VSCode and restart whole computer. Also, Windows powershell outside of VSCode works just fine.
Now when I need to work there, I copy 'w' symbol into clipboard, but it would be nice to have more permanent solution.
As Theo pointed out, my key mapping was messed up. I deleted that particular mapping and now everything works just fine, though how that happened is still a mystery. My best guess is that new mapping was added to VSCode (inseders) in the last update. But I failed to find any evidence in release notes.
I'm running a script in solaris 11 with different results depending of the shell used.
The script has an echo redirecting to a file given by an environment value:
echo "STARTING EXEC" >> $FILE
ps. EXEC is just the message the script show, it's not using exec command.
If I execute the script without the variable FILE defined (using /usr/bin/ksh):
./start.sh[10]: : cannot open
and the script continue the execution.
The flags for ksh are:
echo $-
imsuBGEl
But if I change to /usr/xpg4/bin/sh, the script show me the echo in stdout and there is no error shown.
The flags for xpg4 sh are:
echo $-
imsu
I tried to change the flags with set +- (I can't remove El flags, but BG are removed ok), but can't get the same behavior.
Is there anything I can do to get the same result using ksh without cannot open error?
/usr/bin/ksh --version
version sh (AT&T Research) 93u 2011-02-08
I'll want the script keep going, showing the message in stdout, instead of showing the error just like it does now.
Like shellter said in the comments, the good thing to do is to check if the FILE variable is defined before doing anything. This is a script migration from an HPUX to a SOLARIS environment, and client think they must have the same result as before (we unset FILE variable before execution to test it).
You are likely running Solaris 11, not Solaris 64.
Should you want to have your scripts to work under Solaris 11 without having to search everywhere the bogus redirections, you can simply replace all shebangs (first line) by #!/usr/xpg4/bin/sh.
The final solution we are going to take is to install the ksh88 package and use it like default shell (/usr/sunos/bin/ksh). This shell have the same behavior the client had before, and we can let the scripts with no modifications.
The ksh used in solaris 11 is the 93 (http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html#shell-1)
Thanks #jlliagre and #shellter for your help.
I have installed the ANSI-color plugin for Jenkins.
In the Jobs I have activated that plugin with the default profile 'xterm'.
I cannot figure out how to colorize the output of the Console Log when printing to the
log from the batch files (Windows-platform).
The documentation on
https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin
is not helpful. There are no examples how to actually print in color.
I tried several different echo/print commands, but I cannot get colors to work.
Any hint appreciated.
The ANSI-color plug in transforms your console output to HTML. If your output contains ansi escape sequences, then it converts these special char sequences into (colored) HTML. You can only configure the mapping via 'ANSI color map'.
Example:
\x1b[31m is transformes html color red
It looks that your program does't use Escape sequences. But if you wrote your own software or script, you can use these Escape sequences.
1st Example BASH:
echo -e "\033[31mRed\033[0m"
2nd Example BASH:
printf "\033[31mRed\033[0m"
If you need it, you have to add a newline sequence to printf:
printf "\033[31mRed\033[0m\n"
More to Escape sequences:
English: http://en.wikipedia.org/wiki/ANSI_escape_code
Deutsch: http://de.wikipedia.org/wiki/Escape-Sequenz
There's a lot more documentation available on the Jenkins-ANSIcolor plugin here:
https://github.com/dblock/jenkins-ansicolor-plugin
I wasn't seeing colors because I was using "high intensity" colors (in the 90's range) and these aren't supported. Gotta stick to colors in the 30's
Double check that the software really is outputting ANSI colours. For example, a bash script running this echo will produce colour with the AnsiColor plugin installed, but it'll produce messed-up escape sequences in the console output with no plugin.
In BASH:
echo -e '\033[35mPurple!\033[0m'
Check your project configuration, check the "Build Environment" and make sure "Color ANSI Console Output" is checked.
If you can't find the "Build Environment" section, go to Manage Plugins to double-check that the right plugin is really installed.(I recently installed the "Ansible" plugin instead of "AnsiColor"....)
Jenkins console output is place where you can spend decent amount of time trying to figure out what went wrong (or perhaps right?).
AnsiColor plugins gives you opportunity to color monochromatic Jenkins console output.
Set-by-step guide
Install AnsiColor plugin Under Build Environment section check Color
ANSI Console OutputJenkins -
Color ANSI Console Output -should look like
TesterFenster Inside Execute shell step add something like:
set +x
info() {
echo "\033[1;33m[Info] \033[0m $1"
}
error() {
echo "\033[1;31m[Error] \033[0m $1"
}
success() {
echo "\033[1;32m[Success] \033[0m $1"
}
info "This is information message"
error "Houston we have a problem"
success "Great!!!"
echo "Foreground colors"
echo "\033[31m Red \033[0m"
echo "\033[32m Green \033[0m"
echo "\033[33m Yellow \033[0m"
echo "\033[34m Blue \033[0m"
siz
echo "\033[35m Magneta \033[0m"
echo "\033[36m Cyan \033[0m"
echo "Background colors"
echo "\033[41m Red \033[0m"
echo "\033[42m Green \033[0m"
echo "\033[43m Yellow \033[0m"
echo "\033[44m Blue \033[0m"
echo "\033[45m Magneta \033[0m"
echo "\033[46m Cyan \033[0m"
echo "Different combinations"
echo "\033[1;31m Red \033[0m"
echo "\033[1;4;37;42m Green \033[0m"
echo "\033[1;43m Yellow \033[0m"
set -x
you should see like your output
This only works from the Jenkins console, and not from the actual scripts that out put to your console Output
The OP asked explicitly about using AnsiColor Jenkins Plugin on Windows, so here is my answer:
cmd.exe is not a terminal emulator
As #ocodo wrote, cmd.exe (which is triggered by Jenkins) is not a terminal emulator, so it won't support ANSI output from batch commands by default.
So this is just unsupported on Windows.
These tests were unsuccessful in Jenkins using Windows Batch build step:
echo \e[33m hello \e[0m
echo \033[33m hello \033[0m
echo \x1b[33m hello \x1b[0m
echo \27[33m hello \27[0m
echo \[33m hello \[0m
echo ←[33m hello ←[0m
Last line: To inject an ESC character in a Firefox testbox form, press alt+27, which is also the escape sequence in most editors. more info here: http://www.robvanderwoude.com/ansi.php#AnsiColor and https://groups.google.com/forum/#!topic/jenkinsci-users/0OcjlZQfqrk
A solution: Use Python print for text coloring
The build jobs which use Python for console output had no problem with AnsiColor, so if Python is available in your environment where the console output is generated by a script, you can inject ANSI codes from there. Here's how I worked around it to make it colorful.
Create a helper script in util/ansiGreen.py like so:
#!/usr/bin/env python
print("\033[32m");
Register as env var at the level of your global build configuration:
set ansiGreen=python %cdRootPath%util\ansiGreen.py
Add it to your scripts:
call make-some-tests.bat
if %errorlevel% gtr 0 (
%ansiRed%
echo [ERROR] You screwed up trunk!
%ansiOff%
)
As you can see, %ansiOff% is also required, to end with coloring (Its simply "\033[0m" printed through python). Else everything after %ansiRed% will be in red.
This script is run on a Jenkins slave. To set and get an environment directly within Jenkins batch build step is another challenge.
It's a bit ugly but after a lot of research it seems to be the best workaround to enable AnsiColor to be returned to a Windows Jenkins master from a Windows Jenkins slave.
I found an odd problem when I run a simple csh script on Solaris.
#!/bin/csh
echo $LD_LIBRARY_PATH
Let's call this script test. When I run this:
shell> echo $LD_LIBRARY_PATH
shell> /usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/lib:/my_app/lib
shell> ./test
shell> /usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/lib
They print out totally different values for $LD_LIBRARY_PATH. I can't figure out why. (It's OK on my linux machine)
Thanks!
Do you set $LD_LIBRARY_PATH in your $HOME/.cshrc?
You really shouldn't if you do, since it often just breaks software, but changing the first line of the script to #!/bin/csh -f will cause your script to not read .cshrc files at the start, protecting you from other users who made that mistake.
If your interactive shell is in the sh/ksh family you might have set LD_LIBRARY_PATH using "set" but not exported it. In that case it's new value will be set like a normal variable, but not exported into the environment. But it's more likely that your script is reinitializing the variable.
You can use the "env" command to dump out the exported environment from the interactive shell to check this.