Can I use zsh vi normal mode to move around previous commands output or the printed text in the shell to copy/yank it ?
For example in the screenshot below. I want to move to the output of ls to copy something. When I press j/k zsh cycle my command history but doesn't move up to the printed text. j/k move one line down/up only when I have multiple line command that I'm currently writing but haven't executed yet.
To the best of my knowledge, the ability to access the output of commands interactively is the domain of your terminal (-emulator), not the shell. You would use commands like sed, awk, grep, possibly in a pipe, to access, manipulate and use output you know in advance is the part you are interested in.
To access the output with keyboard shortcuts/command-keys, I suggest using the like of tmux - it allows to copy/yank from the whole terminal display as if it was a text-file in an editor.
Related
I use zsh and I would like backward-kill-word in Emacs mode to behave like Emacs (and bash, fwiw). The behaviour that I have failed to reproduce is that when I press multiple backward-kill-word Emacs adds the killed text to the cut buffer (the first item in the killring) making it possible for me to yank everything with one yank command.
How can I configure zsh to behave like this aspect of Emacs editors?
Actually, by default, Zsh's cut buffer works exactly the same as in Emacs. Just use zsh -f to start Zsh without config files and try it.
However, are you perhaps using zsh-autosuggestions or zsh-syntax-highlighting? There are bugs in these plugins that break this feature:
https://github.com/zsh-users/zsh-autosuggestions/issues/363
https://github.com/zsh-users/zsh-syntax-highlighting/issues/150#issuecomment-658381485
Fixes have been submitted, but for zsh-autosuggestions, none have yet been merged, and for zsh-syntax-highlighting, the fix won't work until Zsh 5.9 has been released.
In the meantime, though, zsh-autocomplete contains a workaround that fixes the problem. If you add that plugin, your cut buffer will start functioning like normal again.
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 custom prompt in Zsh. At the end of it, I colour the last character red or green depending on if the last command succeeded or failed. However, when I do this, I can't go back and edit previous commands.
This is the prompt code:
%{%F%(?.$fg[green].$fg[red])>%f%}
An example workflow:
I enter a command that wraps onto a new line:
> printf "%s\n" "This is a very long printf. How long is it? It's so very very long that it wraps onto the next line."
After this runs, I hit up arrow and modify the command by deleting and retyping "is it". Now, the command line shows:
> printf "%s\n" "This is a very long printf. How long is it It's so very very long that it wraps onto the next line."
This prints out:
This is a very long printf. How long iis it It's so very very long that it wraps onto the next line.
I assume that I'm not terminating the color codes somehow so that the prompt is spilling over into the actual commands I'm trying to enter. It only misbehaves when the prompt wraps around to a new line. Can anyone see what's wrong with my prompt?
I've verified that, without this snippet of code, the rest of the prompt is fine and behaves as you'd expect.
zsh is confused about how long the prompt actually is. The shell already knows that its own %F escape doesn't contribute to the on-screen length of the prompt; you don't need to wrap it in %{...%} like you would similarly do in bash.
PS1="%F%(?.$fg[green].$fg[red])>%f"
If fg contains actual terminal-specific escape sequences, then you would need %{...%}, but you wouldn't use %F at all, as this isn't how you use it. So you might actually need something like
PS1="%(?.%{$fg[green]%}.%{$fg[red]}%})>%f"
But, you don't need a separate array of colors; zsh has them built in as well.
PS1='%(?.%F{green}.%F{red})>%f '
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 writing a program (in python) that calls a separate program (via subprocess). I'm finding that in some cases the sub program is getting stuck running. I can see the sub-program by running top, and if i press "c", I can see the full command line.
What I want, is to be able to stick debugging data (like current thread id, etc) in the command line when i'm calling the sub program, so I can futher debug my problem.
Is there a way to put comments in command line arguments such that they show up in top?
I can't think of a direct way but you could write a little shell script to which you pass the actual command to run plus argument and debugging information. It would show up in the top/ps output.
Instead of making them comments, put them in the environment. For example, if you have a /proc file system, you could do:
FOO=value cmd
When top shows the pid of the command, do:
tr '\000' '\012' < /proc/pid/environ | grep FOO
to see the value of FOO in the environment of the cmd. If the values contain newlines, you will need to be more careful about the display, something like:
perl -n0E 'say if /FOO/' /proc/pid/environ