Please how can we clear the screen in Iex on Windows
Documented method in Iex help does not work:
clear/0 — clears the screen
This StackOverflow Answer also does not work in Windows.
I've discovered it's possible, because native terminal in Windows 10 supports ANSI colors and escape sequences. The only thing is to enabled this in iex shell.
According to https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/io/ansi.ex#L41 this option is configurable. As a quick solution just type in your iex session following code:
Application.put_env(:elixir, :ansi_enabled, true)
In order to make it permanent, you can configure iex shell in ~/.iex.exs file (https://hexdocs.pm/iex/IEx.html#module-configuring-the-shell). Just paste following into the file:
IEx.configure [colors: [enabled: true]]
You can use ANSI codes directly in iex on Windows with consoles that support them (like ConEmu or Windows 10 console.)
This will clear the screen in iex:
iex> IO.write "\e[H\e[J"; IEx.dont_display_result
Explanation:
IO.write outputs to the console without a newline
\e[ is the prefix for ANSI CSI codes
H is the CSI CUP – Cursor Position code with no arguments, by default moves cursor to row 1, column 1
J is the CSI ED – Erase Display code with no arguments, by default clears the screen from the current cursor position
IEx.dont_display_result prevents the :ok result of IO.write from displaying after the screen is cleared
You can also clear the screen using IO.ANSI rather than raw escape codes:
iex> IO.write [IO.ANSI.home, IO.ANSI.clear]; IEx.dont_display_result
This is basically how clear/1 is implemented.
Yes, we can't clear it on Windows as far as I know. If there is one escape that we can output to the IO device to clear screens on Windows, I would love to know and add this functionality to Windows too. :)
Your best option (if this is a real problem for you rather than an annoyance) is to use an alternate Windows shell that supports ANSI Escape Sequences. See this S O question for why you can't simply use ANSI Escape sequences in a Windows Cmd Shell. One command shell alternative that does support ANSI is ConEmu. Configuring ConEmu on your machine is left as an exercise for the reader.
Add the following to ~/.iex.exs in your home directory -- If the file doesn't exist, create it and add the following.
Application.put_env(:elixir, :ansi_enabled, true)
Edit: Note that you'll need a term that supports this, ConEmu, Cmder, etc..
Related
I'm trying to send some commands to terminal by putty using sikuliX. The problem is that some commands need to use characters like "#", ">" but when I'm trying to write it via keyboard (For example, alt + 64 for "#"), doesn't work. Any idea? Here is my code example:
openApp("notepad.exe")
sleep(2)
type("64",KeyModifier.ALT)
PS: I can't use paste(), because putty receive content from that command.
As far as I remember, the Java AWT Robot that is used internally by Sikuli's type(), is restricted to the use of Java defined key constants that are mapped to the standard layout of the US-EN qwerty keyboard. Hence the usage of type() is generally restricted to whatever you can produce with your keyboard.
Saying that I would still expect the Alt combination to work.
Try asking this question on Sikuli launchpad and when you get an answer, update it here. It's a good question.
I found a solution that works but I think that should exist more. I used the clipboard to paste the entire command that I want to send. Here is the explanation:
Using the clipboard
App.setClipboard("ssh user#hostname > /path/to/save/file.txt") # Here we save the command into clipboard to paste inside putty
if exists("puttyScreen.txt",10):
rightClick("puttyScreen.txt") # Here we paste the content of the clipboard
I notice that with the TERM environment variable set to either xterm or xterm-256color that Mac OS X’s Terminal.app utility respects most ANSI escape codes, as least when those escape codes pertain to changing text color.
For example:
echo -e "\033[0;31mERROR:\033[0m It worked"
Produces:
However, I’m more interested in the cursor location manipulation functionality afforded by ANSI escape codes. Unfortunately, that type of code doesn’t seem to work too well in Terminal.app, from what I’ve been able to gather. For example, what I want to do is something like this:
echo -e "\033[sHello world\033[uG'day"
ESC[s Saves the current cursor position, whereas ESC[u restores the last saved position. As a result of running the script above, I’d expect the five characters in “G'day” to overwrite the five characters of “Hello” after the cursor has been repositioned, producing the following:
G'day world
Indeed, this is exactly what I get with iTerm2.app, ConEmu for Windows (running either MinGW or MSYS Git’s copy of bash.exe), etc. What I see in Terminal.app, however, is this:
Hello worldG'day
Is there a reason for this, aside form Terminal.app simply lacking support for these codes? Is there a way to enable this functionality? Is there a chance I have something misconfigured? My TERM setting? Something else?
I’ve been searching everywhere, but haven’t found anything relevant to Terminal.app, specifically. I find it odd that it would support colored text via ANSI escape codes, but not cursor repositioning through the exact same technology. That seems like a fairly arbitrary subset of a fairly well-defined standard. That’s what makes me think I’ve got something misconfigured, rather than that Terminal.app is the one to blame… but, I suppose it’s possible that it simply can’t be done. (Probably one of the reasons iTerm2 exists in the first place?)
If anyone could shed some light on this situation, it’d be much appreciated!
UPDATE
So, I've done a bit more reading and experimenting, and discovered the following oddity:
After looking into n.m.'s answer below, I decided to write out the bytes that were being returned by tput to a file to see how they differed from the regular ANSI instruction.
$ echo "$(tput sc)Hello world$(tput rc)G'day" > out.bin
$ cat -e out.bin
^[7Hello world^[8G'day$
It appears that everything works as expected if I send it the sequences ESC 7 and ESC 8, but NOT if I send it ESC [s and ESC [u, which as I understand things is the more typical representation of the ANSI SCP and RCP codes (Save Cursor Position and Restore Cursor Position, respectively). Since putting ASCII decimal characters 7 or 8 next to an escaped octal byte representation is impossible (\0337 != ESC), environment variables can be used instead to avoid relying on tput:
$ esc=$'\033'
$ csi="${esc}["
$ echo "${csi}0;31mERROR:${csi}0m It worked."
ERROR: It worked. # Color works, as before
$ echo "${csi}sHello world${csi}uG'day"
Hello worldG'day # No dice
$ echo "${esc}7Hello world${esc}8G'day"
G'day world # Success
I'm not sure why this is. If ESC 7 and ESC 8 are some kind of proprietary or custom code for ANSI SCP and RCP that has the potential to vary from terminal implementation to terminal implementation, it would explain to me why tput was created in the first place.
Unfortunately, I am unable to use tput for what I am currently working on, as I am not working exclusively in a bash environment. I am more curious as to how the raw bytes are interpreted from terminal to terminal, and more specifically, whether or not there's a way to get Terminal.app to respect the same ANSI escape codes that all of the other terminal emulators I've tried seem to have no problem with. Is that possible? At this point, I'm beginning to think it simply might not be, which is fine, but it would be nice to know for sure, and possibly also to learn the reason why.
Don't use ANSI codes. Use proper terminfo-based techniques. Xterm-based terminals are not specified to support all ANSI codes. Some do for compatibility, some don't.
Save cursor position sequence is given by the tput sc command and the restore cursor position is tput rc.
echo -e "$(tput sc)Hello world$(tput rc)G'day"
should work on any terminal that supports these sequences.
To see a readable representation of the supported sequences, use the infocmp command. The output might be quite long. If you are interested in sc and rc:
infocmp | grep --color ' [sr]c='
Disclaimer: tested on my Linux machine, don't have a Mac nearby.
UPDATE
Terminal.app is modeled after xterm and xterm is modelled after the VT100 terminal. VT100 did not implement CSI u and CSI s sequences, but used DEC private ESC 7 and ESC 8 sequences (source). Later VT models supported both CSI s/u and ESC 7/8, under different name and with slightly different functionality (source).
ECMA 48 doesn't seem to specify any save/restore cursor position sequences (source (PDF)), or I could not find them there. I don't know where CSU s/u come from. Their name in VT510 documentation suggests they are somehow connected with SCO. This source suggests they are in fact private sequences with no standard meaning. SUN terminals use SCI s to do a reset. It is probably an error to brand these two sequences ANSI.
Modern versions of xterm and other X11 terminal programs (konsole, rxvt...) do support both ESC 7/8 and CSI s/u, but the terminfo database only advertises ESC 7/8. Terminal.app apparently only supports ESC 7/8.
Does the Windows console supporsts ANSI control characters?
It doesn't support many ANSI control characters by default (which is also mentioned in the wikipedia article http://en.wikipedia.org/wiki/ANSI_escape_code), but there are ways to make that possible.
Look into the answers to this question: How to load ANSI escape codes or get coloured file listing in WinXP cmd shell?
You might happen upon something useful.
I assume you're referring to ASCII control characters.
The answer is "some". You can read backspace keypresses, for example, and you can pipe-in things like the ASCII "Bell" character.
However if you mean that the Windows console automatically resolves escaped characters, such as converting "\b" into "Bell", then no, you have to do that yourself.
Note that I speak about entering keypresses directly into the console and not batch files, for that see #ProblemFactory's answer.
Lots of times I'll use Ctrl-R for reverse search and mistype some letter. Bash jumps up hundreds of lines and I'm in the middle of commands I was using a week ago.
Is there a shortcut for jumping back down to the lastest commands I had typed?
Edit: after testing it out on a CentOS server and Mac OS X, it looks like this only happening on OS X.
I've struggled with this same issue.
You can solve this by aborting with ctrl-c. Whether you're in the middle of a reverse search or scrolling through history with the arrows, aborting returns you to a prompt with the history scroll just after the last command.
UPDATE
Here's a nice trick I just learned. Bash and many other programs use Readline under the hood for command-line interpretation. Key bindings for Readline can be configured in a .inputrc file or with the bind command. The bindings can make use of a few functions provided by Readline. For example, I use Bash in vi mode but I still like to use Emacs-style ctrl-A so I have this line in my .bashrc file:
bind '\C-a:beginning-of-line'
To list all the available Readline functions:
bind -l
Among the functions is end-of-history. The function does like its name suggests. The difference between this approach and just using the abort command is that this keeps you on the same prompt.
If using libreadline, Alt-> (or Meta->). More info on Readline shortcuts or search for Commands for Manipulating the History in the man page.
On Mac, try command + .
It works for me.
I was trying alt+. and alt+shift+. , neither works for me. And then found command + . actually works
Maybe not exactly what you want, but you can fix your mistyped character(s) by using backspace when you're in the CTRL-r (reverse-i-search) mode.
You may wan to try "suggest box"-like history HSTR. It reads the bash history and allows quick navigation and filtering - you can see the context of similar history entries. Once you select a history entry it can be edited on the command line.
In Zsh with emacs binding set the actual default key sequence is ^[> binded to end-of-buffer-or-history command rather than command-. suggested above (or end-of-history depending on effect you want to achieve)
Cmd-. produces in Apple Terminal the similar or the same key sequence as Ctrl-C, which can be confirmed by running something useless and long, e.g. find . >/dev/null 2>&1 and pressing one and then other keys on keyboard.
Ctrl-C forces input to be ended and reset. and history scroll is just a side effect for it.
I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.