In zsh, test command is showing in green
This only happens when there is a valid binary exists for the command.
I am just curious why it is showing green for test command furthermore it is not giving any error on hitting the test command
echo $ZSH_THEME
powerlevel10k/powerlevel10k
zsh --version
zsh 5.8 (x86_64-ubuntu-linux-gnu)
You have a small extension (possibly part of the powerlevel10k theme) that colorizes the text on the command line. One thing it does is do progressive path lookup on the name of the command you are typing. If no command is found, the text is red. Once a valid command is found, the color becomes green.
This is independent of whether the command, when executed, succeeds or fails. test with no arguments fails, as noted by the 1x in the following prompt.
Related
In macOS Catalina (10.15.6), I want to use zsh for Terminal sessions. Formerly I had been using the default bash. For bash, I had a .profile containing the line
export PS1="[\u#\h:\w]$ "
which gave a prompt of the form:
[me#myhost:current-dir]$
I want something similar for zsh, but without the user-name#host-name prefix and with # instead of $ for the actual prompt.
In a zsh Terminal session, the command
PROMPT='[%/]%% '
gives the expected prompt, with the current directory enclosed in square brackets.
Of course I don't want to enter that manually each time. Instead, I want to set this in .zprofile. So in .zprofile I included the line
export PROMPT='[%/]%% '
However, that does not work as expected -- the prompt now has the form:
me#myhost current-dir %
Question: How can I get the zsh prompt to have the desired form as follows?
[current-dir] %
Just add the following export to ~/.zshrc, otherwise it won't work.
export PROMPT='[%1~] %%'
That will give you the following, my directory name is test-workflow-branch-only
[test-workflow-branch-only] %
NOTE: This will give you [~] % when in ~/ directory so don't be alarmed when you see that
UPDATE - per comment questions
We add it to ~/.zshrc as this file gets sourced in all interactive shell configurations. The file ~/.zprofile are for commands that we want to execute when we log in, therefore a non-login shell won't source this file.
Thanks for info from Edward Romero. My critique of answer is that it contains four wasted characters, '[',']',' ','%'. Using instead PROMPT='%d>' yields the nice clear absolute path, something like this:
/Users/myuser/test-workflow-branch-only>
In any case, nice to get this headache behind me, and begin reaping the wonderful benefits of using zsh, whatever they may be.
I have a multi-line prompt in zsh. I've found that sometimes when I CTRL-C out of an autocompletion the previous line of the prompt gets erased unexpectedly. Here's a gif showing this happening with ls, vim and fzf: http://imgur.com/1jTrrzA
Here's an outline of events that happen:
ls all the files
ls then tab complete and CTRL-C out of the first completion (previous line of prompt gets erased)
ls then tab complete and CTRL-C out of the second completion. The previous line of the prompt doesn't get erased
same as step 2 but with vim instead
same as step 3 but I hit Enter instead of CTRL-C, this is my mistake. However, if I CTRL-C out of this example (the not-first completion) the previous line isn't erased
Show how fzf suffers from the same problem several times
I've found that the issue as shown during step 2 and step 4 still exists with a single line prompt. However fzf isn't broken with a single line prompt.
My entire prompt can be found at http://pastebin.com/JwufRy6m which is a modified version of https://github.com/sorin-ionescu/prezto/blob/master/modules/prompt/functions/prompt_sorin_setup to work with mercurial repositories at my company. The lines of interest (I think) in my prompt file are 166 and 167 (line 167 == line 166 minus $prompt_newline).
I've tried creating a multiline prompt without using $prompt_newline by doing:
NEWLINE=$'\n'
PROMPT=.....${NEWLINE}....
But that didn't help either which kinda makes sense to me because part of the problem still exists with single-line prompts.
Step 9 of the GPS tutorial states
It is now time to run the application: select the menu Build->Run->sdc, which
will open a dialog window. In the text input field (selected by default),
press the right arrow key and then insert input.txt: this is the name of a
text file that will be passed as argument to the sdc program.
The text input should now read: %E input.txt and the full command that will
be executed is displayed underneath: .../gps/tutorial/obj/sdc input.txt
In actuality, doing this produces an error:
gprbuild: "c:\gnat\2015\share\examples\gps\tutorial\obj\sdc" is not a source of any project.
What is the syntax for passing command-line arguments for the built executable?
I tried various combinations of macros and parameters to gprbuild. The default by following the instructions is %builder -d %eL -P%PP %X %T %E input.txt. I made sure "input.txt" existed in the directory %E refers to. I can run sdc input.txt on the command line and that works fine.
You are apparently running a "build" command (via gprbuild), and not running the "sdc" executable itself. I guess you selected the wrong menu.
This question is about configuring the R console to behave like a bash shell when it comes to navigating the command history. It is somewhat related to the ?history. For brace-enclosed multi-lines, I'd like to configure the command history navigation of R to be similar to bash.
Presently when running R in an xterm under Linux, using the up-arrow to navigate the command history causes each previous line to be recalled one by one, even if a set of lines had been enclosed in braces. This occurs, for example, when copy/pasting a multi-line function from a text editor into the R console. Not so with bash.
Here is an example of how bash functions in this regard:
In a bash shell within an xterm under Linux, after typing the following five lines...
a=1
{
x=1
y=1
}
... the first press of the up-arrow will recall a single line reformulation of the brace-enclosed commands, like this ...
{ x=1; y=1; }
... and the second press will recall this ...
a=1
It seems that in R, the up-arrow navigates backwards one line at a time, regardless of encapsulation. Is there a way to configure R so that it's command history navigation functions like bash's?
You could use rlwrap. I use it for other console programs and it works very well. You will need to prepend the R command with the rlwrap binary and then your history lines can be restored in a number of ways, including multi-line matching.
Workaround for Linux/Unix
Similarly as in Rstudio (thanks to Ari B. Friedman comment), where user in R console is using ShiftEnter to bypass RETURN, you can start newline (in R terminal) without accepting newline command using Ctrl-VCtrl-J. This way the multi-line command will be accepted into history as one-liner with line-feeds instead of enters and you will even have the chance to edit it. You can even manage in your .inputrc file to have custom combination for this action.
I do not think direct reconfiguration of R is possible.
Readline man page may help more.
I'm starting to think I have broken GNU make. Its behavior seems to have become unpredictable. Do I get a prize for that?
In my commands section, I have been using the '#' character to suppress unwanted output. In one makefile, I removed the '#'s for one run, to verify it was doing what I wanted. Since I put the '#'s back in, I'm getting shell errors:
#mkdir: not found
What in the world is that about? What could make the '#' stop being recognized as a standard command modifier?
Grrrr! I hates that potto! (from the cover of Managing projects with GNU make)
The # character is only valid at the beginning of a line executed by make. If you have continuation characters such as \ ending the previous line, this won't be executed by make, it will be executed by the shell. The shell won't know what to do with the # sign, hence your error.
Additionally if you use .ONESHELL you should note that command prefix will only be valid on the very first line of the recipe, after that it will throw an error since all the lines are passed to one shell for execution.
The same rules apply to the other prefix operator (-) as well.