I have a daily use case where I need to work with projects on different version of Java (8, 11, ...).
I would like to have it displayed in the right side prompt in my shell (ZSH with Oh-My-Zsh). I know of a dummy way (computationally expensive) to do it (just java --version to var and display it). I would like it to have it cached until I don't source a file (which is a specific project file that sets the new env vars for different java versions).
Do you have any ideas how to do this efficiently?
Br,
Stjepan
The PROMPT and RPROMPT variables can have both static and dynamic parts, so you can set the version there when you source the project file, and it will only be calculated one time. The trick is to get the quoting right.
This line goes in the project file that sets the env variables, somewhere after setting PATH to include the preferred java executable:
RPROMPT="${${=$(java --version)}[1,3]}"
The pieces:
RPROMPT= - variable for the right-side prompt.
"..." - the critical part. Variables in double quotes will be expanded then and there, so the commands within this will only be executed when the project file is sourced.
${...[1,3]} - selects the first three words of the enclosed expression. On my system, java --version returns three lines of data, which is way too big for a prompt; this reduces it to something manageable.
${=...} - splits the enclosed value into words.
$(java --version) - jre version info.
Related
I am trying to set the dictionary option (to allow autocompletion of certain words of my choosing) using wildcards in a filename glob, as follows:
:set dict+=$VIM/dict/dict*.lst
The hope is that, with this line in the initially sourced .vimrc (or, in my case of Windows 10, _vimrc), I can add different dictionary files to my $VIM/dict directory later, and each new invocation of Vim will use those dictionary files, without me needing to modify my .vimrc settings.
However, an error message says that there is no such file. When I give a specific filename (as in :set dict+=$VIM/dict/dict01.lst ), then it works.
The thing is, I could swear that this used to work. I had this setting in my .vimrc files since I started using Vim 7.1, and I don't recall any such error message until recently. Now it shows up on my Linux laptop as well as my Windows 7 and Windows 10 laptops. I can't remember exactly when this started happening.
Yes, I tried using backslashes (as in :set dict+=$VIM\dict\dict*.lst ) in case it was a Windows compatibility issue, but that still doesn't work. (Also this is happening on my Linux laptop, too, and that doesn't use backslashes for filepaths.)
Am I going senile? Or is there some other mysterious force going on?
Assuming for now that it is a change in the latest version of Vim, is there some way to specify "use all the dictionary files that fit this glob"?
-- Edited 2021-02-14 06:17:07
I also checked to see if it was due to having more than one file that fits the wildcard glob. (I thought that if I had more than one file that fit the wildcard, the glob would turn into two filenames, equivalent to saying dict+=$VIM/dict/dict01.lst dict02.lst which would not be syntactically valid.) But it still did not working after removing extra files so that only one file fit my pathname of $VIM/dict/dict*.lst . (I had previously put another Addendum here happily explaining that this was how I solved my problem, but it turned out to be premature.)
You must expand wildcards before setting an option. Multiple file names must be separated by commas. For example,
let &dictionary = tr(expand("$VIM/dict/dict*.lst"), "\n", ",")
If adding a value to a non-empty option, don't forget to add comma too (let is more universal than set, so it's less forgiving):
let &dictionary .= "," . tr(expand(...)...)
I just added the Powerlevel10k theme to my zsh and i'm trying to configure certain parts.
It currently looks like this:
The ~/.p10k.zsh has a lot of configurations done and I've been trying to change certain things but i'm not there yet.
I don't want to print the whole path on the left prompt, just the directory. Also, not sure what those numbers indicate in the git section. And the right prompt is displaying my ruby version, although I haven't used Ruby in ages and want to change it to a different setting.
I've tried adding a PS1=... to .zshrc but it seems to be overriden by the P10K config file.
Any suggestions?
Display only the last directory segment
Open ~/.p10k.zsh.
Search for POWERLEVEL9K_SHORTEN_STRATEGY.
Change the value of this parameter to truncate_to_last.
Alternatively, change the value of POWERLEVEL9K_DIR_MAX_LENGTH to 1. This will maximally shorten current directory while keeping the transformation reversible. You can restore the original directory by copy-pasting the shortened directory to the command line and pressing TAB.
Ruby version
Powerlevel10k has several prompt segments that can display Ruby version. By default only those are enabled that display Ruby version when it has been manually overridden by some tool (e.g., rbenv or asdf).
To remove Ruby version from prompt:
Open ~/.p10k.zsh.
Search for POWERLEVEL9K_RIGHT_PROMPT_SEGMENTS.
Remove or comment out the following elements: rbenv, rvm and asdf.
Alternatively (and perhaps preferably), find out which tool is overriding Ruby version for you and remove the override if you no longer need it.
shorten dir segment to show only deepest directory
To show only last n significant path segments, you can set following in your config .zshrc, e.g n=1 means show only last folder in present working directory:
POWERLEVEL9K_SHORTEN_DIR_LENGTH=1
See https://stackoverflow.com/a/49027654
explain Git symbols
The question/exclamation mark in Git segment (vcs segment, next to path) means the number of files untracked (?) and unstaged (!). For detailed description see What do different symbols in Git status mean?
change version segment
You can change the version segment (on the right of prompt) to reflect another tool. For example to replace shown ruby version by python version replace the element within right promt elements in your config .zshrc:
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(rbenv)
by
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(pyenv)
I need to achieve the below using Robotframework script:
c:\>runbatch "C:\Program Files (x86)\tool\bin\test.exe" C:\tool\get.ini
where runbatch is a MS DOS Batch and "C:\Program Files (x86)\tool\bin\test.exe" and C:\tool\get.ini are parameters to the batch file. The first argument contains path of a tool that has "(" and ")" in its path.
So in my Robot script I have a variable like below:
${tool_path} "C:\\Program Files (x86)\\tool\\bin\\test.exe"
${tool_ini} "C:\tool"
And invoke like below:
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} ${tool_ini}\\get.ini
The execution fails but note when I run it via the same param thru the command line as standalone batch it works fine.
In the batch I added comments to just log the arguments and I found that they are completely distorted, the tool_path value is completely distorted ("\"C:\Program) and second argument becomes (Files ) - how can I fix the issue in robot script such that when a path is passed having braces are not modified?
You need to also escape the backslashes in ${tool_ini} - make its value c:\\tool; that's not the culprit thought, just something else to change.
Remove the double quotes in the arguments' values - Run Process does not need them in the way you are calling it, with a keyword argument per script argument. E.g.:
${tool_path} C:\\Program Files (x86)\\tool\\bin\\test.exe
${tool_ini} C:\\tool
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} ${tool_ini}\\get.ini
The way you've put them, they have become a part of the value itself.
Alternatively, keeping the double quotes there, you can call the script with all arguments in the call line:
${tool_path} "C:\\Program Files (x86)\\tool\\bin\\test.exe"
${tool_ini} C:\\tool
${RC}= Run Process ${CURDIR}/../scripts/runbatch.bat ${tool_path} "${tool_ini}\\get.ini"
(the second one doesn't really need quotes, but I've added them for consistency)
By the way, not really an issue, yet - the script path uses slashes (/), which is a bit unorthodox for Windows. Contrary to the popular believe, the OS does support this path delimiter pretty much the same way as it supports backslashes (\), it's just not widely used and looks a bit out of place.
I have added
export HISTIGNORE="ls:cd:pwd:exit:cd .."
to my .zshrc file.
Deleted .zsh_history and restarted terminal but it still wont ignore those commands.
The zsh shell doesn't use the HISTIGNORE environment variable. Instead, it has a HISTORY_IGNORE environment variable.
From the zshparam manual:
HISTORY_IGNORE
If set, is treated as a pattern at the time history files are
written. Any potential history entry that matches the pattern is skipped. For example, if the value is fc * then
commands that invoke the interactive history editor are never
written to the history file.
Note that HISTORY_IGNORE defines a single pattern: to specify
alternatives use the (first|second|...) syntax.
So in your case, you would want to do
HISTORY_IGNORE="(ls|cd|pwd|exit|cd ..)"
or something similar.
Notice that this affects only history written to the history file, not the history in the currently active shell session, as far as I can see.
I'm busy porting my build process from msbuild to cmake, to better be able to deal with the gcc toolchain (which generates much faster code for some of the numeric stuff I'm doing).
Now, I'd like cmake to generate several versions of the output, stuff like one version with sse2, another with x64, and so on. However, cmake seems to work most naturally if you simply have a bunch of flags (say, "sse2_enable", and "platform") and then generate one output based on those platforms.
What's the best way to work with multiple output configurations like this? Intuitively, I'd like to iterate over a large number of flag combinations and rerun the same CMakeLists.txt files for each combination - but of course, you can't express that within the CMakeLists.txt files (AFAIK).
The recommended way to do this is to simply have multiple build directories. From each one you simply call cmake with the required settings.
For example you could do, starting in the base source directory (using Linux shell syntax but the idea is the same):
mkdir build-sse2 && cd build-sse2
cmake .. -DENABLE_SSE2 # or whatever to enable it in your CMakeLists.txt
make
cd ..
mkdir build-x64 && cd build-x64
cmake .. -DENABLE_X64 # or whatever again...
make
This way, each build directory is completely separated from each other.
This allows you to have one directory for Debug, another for Release and another for cross-compiling.
There hasn't been much activity here, so I've come up with a workable solution myself. It's probably not ideal, so if you have a better idea, please do add it!
Now, it's hard to iterate over build configs in cmake because cmake's crucial variables don't live in function scope - so, for instance, that means if you do include_directories(X) the X directory will remain in the include list even after the function exits.
Directories do have scope - and while normally each input directory corresponds to one output directory, you can have multiple output directories.
So, my solution looks like this:
project(FooAllConfigs)
set(FooVar 2)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-2b")
set(FooVar 5)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-5c")
set(FooVar 3)
set(FooAnotherVar b)
add_subdirectory("project_dir" "out-3b")
set(FooVar 3)
set(FooAnotherVar c)
add_subdirectory("project_dir" "out-3c")
The normal project dir then contains a CMakeLists.txt file with code to set up the appropriate includes and compiler options given the global variables set in the FooAllConfigs project, and it also determines a build suffix that's appended to all build outputs - any even indirectly included output (e.g. as generated by add_executable) must have a unique name.
This works fine for me.