I'm trying to use the Scala interactive shell, but the backspace key's behavior is strange. I'm finding that backspace does seem to delete the previous character, but it doesn't display that way on the line I'm typing... the cursor moves forward instead of backward. This makes it impossible to see what the current input line looks like.
I'm using Scala 2.11.12. I'm working in a terminal window on a Linux system, but xrdp'ing into the Linux host from a Windows 10 laptop. The backspace key works fine outside Scala (in zsh).
As a workaround, is there any control character that tells Scala to redisplay the current line? (Old OS's used to support characters that perform that function, if memory serves, but they haven't been necessary for a couple decades or so.)
I also encountered the same problem and improved by changing the setting of pyenv.
If the global setting of pyenv is not system, try changing to system.
Example:
$ pyenv versions
* system (set by /Users/*****/.pyenv/version)
2.7.10
3.5.0
anaconda3-5.2.0
Perhaps it's a bug of JLine, which scala use as a replacement of readline. But, if I empty the folder ~/.pyenv/shims, scala works fine. Then I execute pyenv rehash (which will bring back the files under shims), scala failed!
Then I remove the files in ~/.pyenv/shims half by half and it's a file named infocmp makes the difference. And it's not the content in it, but the exec permission that matters, i.e. chmod a-x ~/.pyenv/shims/infocmp will make scala work fine, but chmod a+x ~/.pyenv/shims/infocmp, even if infocmp is empty, the problem will occur!
May be I am close to the truth, but for now we can use chmod a-x ~/.pyenv/shims/infocmp to work around. And it needs only to be run once, because pyenv rehash will not overwrite a file if it already exists.
Related
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I am using fish terminal inside of Emacs term
My normal prompt on load looks like the following
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
$>
Ok, when I load fish term inside of term.el it looks like this
Welcome to fish, the friendly interactive shell
Type helpB for instructions on how to use fish
7;file://Collins-MacBook-Air.local/Users/collinbell/Programs/riddley⏎
$>
A cd command in my normal terminal looks like this
$> cd ~/
$>
However in the emacs term.el it looks like this
$> cd ~/
7;file://Collins-MacBook-Air.local/Users/collinbell⏎
$>
I have no idea why it is pasting the cwd into the buffer, but it does it every time a directory changes. Emacs also makes the system sound after this, while other commands like ls do not make the system sound.
This is obviously not the biggest issue in the world, but I do run clear as a pre-command to keep my terminal looking clean (although I turned it off for this example) and Emacs pasting this line into the buffer really messes with sublime usage.
You seem to be experiencing a known issue.
Try this fix:
In your fish config file ~/.config/fish/config.fish add the following:
function fish_title
true
end
Also, see this from the fish documentation, though according to the github issue, the fix suggested in the docs might not work, while the above function does.
According to the fish documentation, this is what's going on:
Fish is trying to set the titlebar message of your terminal. While
screen itself supports this feature, your terminal does not.
Unfortunately, when the underlying terminal doesn't support setting
the titlebar, screen simply passes through the escape codes and text
to the underlying terminal instead of ignoring them. It is impossible
detect and resolve this problem from inside fish since fish has no way
of knowing what the underlying terminal type is. For now, the only way
to fix this is to unset the titlebar message, as suggested above.
I'm using the projectile library. When I invoke projectile-find-file I get the following error:
[svn: E155021: This client is too old to work with the working copy at foo/bar` (format 31). You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change
From the command line, everything is fine (I'm using version 1.8.13).
Is there anyway that emacs can be using an out of date version? Or even how do I find out what version it is using/how it is invoking svn?
Projectile uses whatever svn binary it finds in your path. Try running which svn from Emacs (e.g. via shell-command / M-!) and from your terminal and comparing the paths you get. A difference will indicate that Emacs and your terminal are using different path variables.
Since you are on OSX, and since your terminal uses the expected svn, something like exec-path-from-shell might be helpful:
Ever find that a command works in your shell, but not in Emacs?
This happens a lot on OS X, where an Emacs instance started from the GUI inherits a default set of environment variables.
This library works solves this problem by copying important environment variables from the user's shell: it works by asking your shell to print out the variables of interest, then copying them into the Emacs environment.
exec-path-from-shell is available on MELPA.
i have this issue (https://github.com/sbt/sbt/issues/562)
basically when I try to get a console it says:
[ERROR] Failed to construct terminal; falling back to unsupportedjava.lang.IllegalArgumentException: Invalid terminal type: jline.UnixTerminal
also you cant use backspace
you basically cannot use sbt in cygwin (in dos is fine but cygwin is a much nicer environment)
and have voiced my concern there
i have tried several workaround i found on the net but they are all for old releases and no use now
was just wondering if you know of any workaround?
thanks
The following works for me (mostly, see note at bottom):
Use the mintty shell. I believe this is the default shell for new cygwin installs but has been included as an alternative for a while. If mintty.exe exists in your <cygwin home>\bin folder then it's ready to use, else it can be installed through the typical cygwin package selection from the setup.exe.
Open a mintty window, right click anywhere, go to Options... -> Keys, and make sure Send Backspace as ^H is checked. This will allow the REPL to correctly interpret backspaces.
For just running the Scala REPL that should be all you need, but attempting to run sbt console can still produce that exception. To get past that, run sbt without any arguments to get to the sbt prompt. From there execute:
eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal")
then
console
or, as a single command (with both semi-colons being important):
; eval System.setProperty("jline.terminal", "scala.tools.jline.UnixTerminal") ; console
From what I can tell, this is caused at least in part by the Scala REPL and the sbt prompt using incompatible versions of JLine. In particular, it looks like the Scala REPL created their own wrappers around the library and are using that while sbt is using the JLine library directly.
Note
One limitation that I continue to run into is that the REPL wraps at column 80 even if the shell window has more horizontal space. Not only that, but when the REPL wraps like this it overwrites the same line rather than advancing to the next, and pulling long lines from history ends up pushing the cursor above the line you're actually editing.
For some reason, when I type in commands I'm used to on linux, it works perfectly, as it does in bash... But in eshell, it doesn't work.
I've narrowed the problem to a trivial and small sample, as follows:
$ du
c:/Program: command not found
$ which bash
c:/Program Files (x86)/Git/bin/bash.exe
How do I get this working? (du is whatever it is by default... It's implemented in elisp, I haven't made any unusual changes there, that is, it's a compiled lisp function in `em-unix.el')
I would've expected something along the lines of "You have used 1.3 GiB of disk space", rather than that command not found error.
It doesn't use bash.exe, but it can use du.exe, when present.
On my system:
c: gutov $ which bash.exe
which: no bash.exe in ...
c: gutov $ which du.exe
h:/Apps/System/gnuwin32/bin/du.exe
From your error message I can tell that it calls some command and fails because it doesn't properly quote the path to executable (which contains spaces). Maybe you should do M-x report-emacs-bug.
Overall, I recommend:
1) Uninstall Git and reinstall it selecting the second option when asked about your PATH environment ("Run Git from the Windows Command Prompt"). This will remove the unix tools packaged with it from PATH.
2) Install in some directory without spaces and add to PATH unix tools from GnuWin32 project, or from Eli Zaretski's ports. The latter contains fewer packages overall, but it has a much faster find, for example. You can mix them.
Alternatively, maybe you can get away with just reinstalling Git into directory without spaces.