This question is related to R, I have written >help('[[") instead of >help("[[") and the shell prompt changed from > to + and none of my commands work. How do i get back to the default shell prompt
press Escape key to get out of the + sign
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.
Problem steps like this:
copy text 'kill-server' to system clipboard
hit Prefix : to enter the tmux command prompt
hit command+v to paste
The result paste text is 200~kill-server201~ instead of kill-server. This weird bracketed paste mode text do not happen in shell prompt but in tmux command prompt, and I had tried to turn off bracketed paste mode but without luck.
Environment that has this issue:
Mac OS 10.11.1, iTerm, zsh 5.0.7, Tmux 2.1
Mac OS 10.10.1, iTerm, zsh 5.1.1, Tmux 1.9
Environment that without this issue:
Mac OS 10.11.1, iTerm, bash, Tmux 2.1
I'm posting this as an answer because it's a bit too long and I need some formatting... So here it goes.
I can reproduce only with zsh 5.1+. There's no reason to expect the problem on 5.0.x, because bracketed paste mode was introduced in 5.1. You might be doing something wrong in your testing, or there might be something peculiar about your setup, in which case you have to explain better. Also, iTerm2 probably doesn't play any part in this, since I could reproduce in Terminal.app just fine (of course they could both have the same defect...).
Considering bracketed paste mode is a ZLE feature, I think (disclaimer: the rest of this paragraph is purely my speculation) the real problem is that tmux uses the underlying shell's line editing features (ZLE, in zsh's case) in its command prompt to offer better editing experience (for instance, you have access to all the Emacs style shortcuts there), but its command prompt is a dumb term, and doesn't understand the bracketed paste sequences. So we have this weird situation of two modes of terminal emulation within tmux, one is fairly smart which happens within each pane, and the other is dumb which happens in its command prompt.
Solutions and workarounds:
This is probably worth reporting to tmux. https://github.com/tmux/tmux/issues.
Turn off ZLE bracketed paste. It does work, you're probably doing it wrong. If you don't mind losing bracketed paste in tmux, you could put the following somewhere in your shell init sequence:
(( $+TMUX )) && unset zle_bracketed_paste
In iTerm2, you have access to advanced paste (Edit->Paste Special->Advanced Paste..., or ⌥⌘V). Just uncheck "Bracketed paste mode", and you shouldn't see the escape sequences.
I solved this problem finally just deactivated the safe-paste plugin in my oh-my-zsh.
The safe-paste used to fix zsh up arrow completion issue. But now, the arrow completion issue is gone while inducing tmux bracketed paste problem. I haven't dived into the code of safe-paste yet. Hope to help others encountering the same problem.
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.
All,
When JlinkSTR91x.exe is invoked, it opens up a command prompt J-Link. In this prompt, we can type the commands. I need to do the same using AutoIt scripting.
This is what I tried,
;Execution.au3
Local $foo = Run("C:\\Program Files\\SEGGER\\JLinkARM_V426b\\JLinkSTR91x.exe", "", #SW_SHOW, $STDIN_CHILD)
StdinWrite($foo,"setb 0")
ProcessWaitClose($foo)
When I run this script, J-Link prompt opens up but unable to send the command "setb 0" at this prompt. Please help.
Run("cmd")
$prog = WinWaitActive("C:\WINDOWS\system32\cmd.exe")
ControlSend($prog, Default, $prog, "exit")
Sleep(999)
ControlSend($prog, Default, $prog, "{Enter}")
WinWaitClose($prog)
This does theoretically what you want. Just replace the cmd with your command and insert the actual title of the prompt.You can find it out with the Info-Tool included with AutoIt.
It's just a working example.
And it will even send the text when your prompt isn't active any more. You can even hide your prompt with WinSetState($prog, Default, #SW_HIDE) .
I need to run knit2html on the command line using Rscript. I tried the following code and it works
Rscript -e "(knitr::knit2html(text = '## good', fragment.only = TRUE))"
However, when I introduce R code chunks (or anything involving backticks), the process hangs. So the following does NOT work
Rscript -e "(knitr::knit2html(text = '## good\n `r 1 + 1`',fragment.only = T))"
For the purpose of my use, I only have access to the contents and hence can NOT pass a file to knit2html, which I know will work.
My question is how do I make this work. I know the problem is the backticks and I have tried looking at escaping them, but nothing seems to be working.
it is a shell issue.
On windows it works.
On linux You need to escape the backtick like \'
I think the reason , some shell interprets the double-quoted string once.
A related issue has been reported once here. You have to use single quotes to avoid shell expansion. I'm not sure if that applies to Windows as well, though.