How can you change permanently the default colors of gradle output?
With my background color, gradle output is difficult to read.
So I want to change the output color.
One blog claims it can be done:
http://gradle.1045684.n5.nabble.com/Colourizing-console-output-td3073839.html
So I tried to put this in my (home)\.gradle\gradle.properties:
org.gradle.color.normal=YELLOW
org.gradle.color.info=YELLOW
org.gradle.color.identifier=YELLOW
and
systemProp.org.gradle.color.normal=YELLOW
systemProp.org.gradle.color.info=YELLOW
systemProp.org.gradle.color.identifier=YELLOW
It didn't help. So I tried this in my (home)\.gradle\init.gradle:
initscript {
System.setProperty('org.gradle.color.normal', 'WHITE')
System.setProperty('org.gradle.color.identifier', 'WHITE')
System.setProperty('org.gradle.color.info', 'WHITE')
}
It also didn't help.
So far, the only way I can remove the colors is to run gradle with
gradle -v --console plain
But I don't want to type that every time I run a command. So I tried to make it permanent with:
set GRADLE_OPTS=--console plain
But when I do that gradle complains : Unrecognized option: --console.
So is there any way to make a permanent change in the output colors?
Two solutions so far: 1. doskey gradle=gradle --console plain $* and 2. set TERM=dumb. I would like errors to remain red though.
Adding org.gradle.console=plain to gradle.properties removed the colors for me.
Related
I have graphviz installed on a linux VM. I am automatically converting .apt into .dot files using APT. I draw these with graphviz and the dot command. But it keeps showing the xlabels, which are set automatically by APT. Is there a way to surpress these xlabels, so they dont show ?
-Gforcelabels=false didn't work and i could not change the labels with -Exlabel
dot -Nxlabel="" -Exlabel="" -T... should(?) work, but it does not! I consider this a bug, not a feature.
This does work:
gvpr -c 'E{$.xlabel=""}N{$.xlabel=""}' file.dot |dot -Tsvg >file.svg
I installed fish shell, installed few themes. Applied the theme "agnoster", all good is pretty but I want fish_prompt to override the original one and keep the styles in order to show me full path properly. Currently the full path is a shortcut such as Desktop/Abba turns to ~D/Abba and I want to remove the D and will it be ~Desktop/Abba. How can I override function fish_prompt properly so that I am able to call the original previous function from the theme to keep up the styles?
The agnoster theme uses fish's prompt_pwd function to display the pwd.
That shortens each path component to $fish_prompt_pwd_dir_length characters. Set that variable to 0 to inhibit shortening entirely.
Alternatively, you can change the prompt_pwd function however you want it, e.g. via funced prompt_pwd (and funcsave prompt_pwd once you're happy with the result).
I've had a similar issue, but the chosen answer didn't work for me.
In my case, I've had to source all theme files manually before overriding the fish_prompt function.
For example
source $OMF_PATH/init.fish # assure omf is loaded before run the following code
# Read current theme
test -f $OMF_CONFIG/theme
and read -l theme < $OMF_CONFIG/theme
or set -l theme default
set -l theme_functions_path {$OMF_CONFIG,$OMF_PATH}/themes*/$theme/functions/
for conf in $theme_functions_path/*.fish
source $conf
end
function fish_prompt
# prompt_theme_foo
# prompt_theme_bar
end
More details on: https://stackoverflow.com/a/72098697/2180456
Just started using conemu on windows again (after quite some time using other rubbish). Its great, but there is one element that really bugs me, that is the command prompt is always spread over two lines:
user.name#DESDAH181093 D:\user\workspace\
>
user.name#DESDAH181093 D:\user\workspace\
>
user.name#DESDAH181093 D:\user\workspace\
>
Can I get it so that this is compressed onto the same line, like this?
user.name#DESDAH181093 D:\user\workspace\>
user.name#DESDAH181093 D:\user\workspace\>
user.name#DESDAH181093 D:\user\workspace\>
I looked through the settings and did not spot anything obvious.
I saw this question: link, but I think I want to do the opposite and I can't find where anything like ${cwdfull}\n> is defined in the settings...
UPDATE
In addition to the answer of Max, here is what I really needed to change in the CmdInit.cmd file:
rem Carriage return and `$` or `>`
rem Spare `$E[90m` was specially added because of GitShowBranch.cmd
if "%ConEmuIsAdmin%" == "ADMIN" (
set ConEmuPrompt2=$S$E[90m$$
) else (
set ConEmuPrompt2=$S$E[90m$G
)
Where both ConEmuPrompt2 where:
ConEmuPrompt2=$_$E[90m$$
changed here ^
Make a copy of ConEmu\CmdInit.cmd file.
Replace I the copied file $_ with $S, save changes )
Utilize your modified file in the task {Shells::cmd}.
Save ConEmu settings.
I'm using Sphinx on Windows.
Most of my documentation is for regular users, but there are some sub-pages with content for administrators only.
So I want to build two versions of my documentation: a complete version, and a second version with the "admin" pages excluded.
I used the exclude_patterns in the build configuration for that.
So far, it works. Every file in every subfolder whose name contains "admin" is ignored when I put this into the conf.py file:
exclude_patterns = ['**/*admin*']
The problem is that I'd like to run the build once to get both versions.
What I'm trying to do right now is running make.bat twice and supply different parameters on each run.
According to the documentation, I can achieve this by setting the BUILDDIR and SPHINXOPTS variables.
So now I have a build.bat that looks like this:
path=%path%;c:\python27\scripts
rem BUILD ADMIN DOCS
set SPHINXOPTS=
set BUILDDIR=c:\build\admin
call make clean
call make html
rem BUILD USER DOCS
set SPHINXOPTS=-D exclude_patterns=['**/*admin*']
set BUILDDIR=c:\build\user
call make clean
call make html
pause
The build in the two different directories works when I delete the line set BUILDDIR=build from the sphinx-generated make.bat file.
However, the exclude pattern does not work.
The batch file listed above outputs this for the second build (the one with the exclude pattern):
Making output directory...
Running Sphinx v1.1.3
loading translations [de]... done
loading pickled environment... not yet created
Exception occurred:
File "C:\Python27\lib\site-packages\sphinx-1.1.3-py2.7.egg\sphinx\environment.
py", line 495, in find_files
['**/' + d for d in config.exclude_dirnames] +
TypeError: coercing to Unicode: need string or buffer, list found
The full traceback has been saved in c:\users\myusername\appdata\local\temp\sphinx-err-kmihxk.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>.
What am I doing wrong?
Is the syntax for exclude_patterns in the sphinx-build command line different than in the conf.py file?
Or is there a better way to build two different versions in one step?
My first thought was that this was a quoting issue, quoting being notoriously difficult to get right on the Windows command line. However, I wasn't able to come up with any combination of quoting that changed the behavior at all. (The problem is easy to replicate)
Of course it could still just be some quoting issue I'm not smart enough to figure out, but I suspect this is a Sphinx bug of some kind, and hope you will report it to the Sphinx developers.
In the meantime, here's an alternate solution:
quoting from here:
There is a special object named tags available in the config file. It can be used to query and change the tags (see Including content based on tags). Use tags.has('tag') to query, tags.add('tag') and tags.remove('tag') to change
This allows you to essentially pass flags into the conf.py file from the command line, and since the conf.py file is just Python, you can use if statements to set the value of exclude_patterns conditionally based on the tags you pass in.
For example, you could pass Sphinx options like:
set SPHINXOPTS=-t foradmins
to pass the "foradmins" tag, and then check for it in your conf.py like so:
exclude_patterns = blah
if tags.has('foradmins'):
exclude_patterns = []
That should allow you to do what you want. Good Luck!
I'm using nano on a server via ssh; on that system, nano doesn't have syntax color enabled by default. So I copied these nanosyntax files (for alternative, see also #CraigBarnes' answer) on the server, and had set up ~/.nanorc as:
include "~/nanosyntax/syntax-nanorc/php.nanorc"
include "~/nanosyntax/syntax-nanorc/php2.nanorc"
include "~/nanosyntax/syntax-nanorc/sh.nanorc"
include "~/nanosyntax/syntax-nanorc/python.nanorc"
include "~/nanosyntax/syntax-nanorc/html.nanorc"
include "~/nanosyntax/syntax-nanorc/perl.nanorc"
include "~/nanosyntax/syntax-nanorc/ruby.nanorc"
include "~/nanosyntax/syntax-nanorc/js.nanorc"
Now, this is the thing; if I just call:
nano somefile.php
... no php syntax coloring is done. If I try to force:
nano --syntax=php somefile.php
... still no syntax coloring (shown as plain text). However, if I do:
nano ~/.nanorc
... then I do get syntax coloring (that corresponds to .nanorc type file) ?!
So obviously, syntax coloring as such works (i.e. shell and nano are capable of it) - except, it seems to be ignored for some languages, like in this case php ?!
So, does anyone know what is going on - and how could I get syntax coloring also for php files?
Thanks,
Cheers!
I just ran into the same problem, and I fiddled around a bit with the includes to find the error. Surprisingly, turns out that changing the inclusion order fixed the issue:
This works:
include "~/.nano/nanorc.nanorc"
include "~/.nano/sh.nanorc"
# more includes...
This fails to highlight sh files:
include "~/.nano/sh.nanorc"
include "~/.nano/nanorc.nanorc"
# more includes...
So I guess it's probably a bug (in nano 2.2.2; worked fine in nano 2.1.7)
Hm... well, it seems there has been an upgrade on that server I was using; originally, nano didn't have syntax coloring by default, which is why I used my own separate ~/.nanorc.
Now, however, on the upgraded server, nano seems to work with php syntax coloring by default - and me having my own separate ~/.nanorc seems to have conflicted; because, once I commented all the entries in the private ~/.nanorc (with an #), php syntax coloring was back!!
Whowouldathunkit ?! :)
Cheers!
EDIT: Just to add a couple of notes about nano:
As noted above, syntax coloring is forced with --syntax switch; to see which syntaxes are available:
grep 'include' /etc/nanorc | # find lines containing 'include' in nanorc
grep -v '^#' | # don't process lines that start with '#'
sed 's_.*/\(.*\)\.nanorc"_\1_' # extract plain filenames
Result of this command is something like:
nanorc
c
css
debian
gentoo
html
...
So to force "nanorc" syntax coloring, you use:
nano --syntax=nanorc /usr/share/nano/nanorc.nanorc
.. or forcing "bash" shell script syntax coloring (especially useful with bashrc) would be:
nano --syntax=sh ~/.bashrc
Those "nanosyntax" files on Google Code are nearly as bad as ones that come with nano by default.
nano's highlighting engine is more basic than something with nested contexts (e.g. GtkSourceView) but you don't have to settle for crappy highlighting:
https://github.com/craigbarnes/nanorc