I'm writting a Ruby program for windows, and I need to read user input from keyboard (stdin).
However, it's needed that the user key-presses are not automatically displayed in the windows console, and behave like "silent key presses"
This problem in Ruby over linux, can be solved using the "stty" linux command:
%x{stty -icanon -echo}
because it is the linux terminal who automatically outputs the user-keys into the terminal, so running the "stty" command tells the terminal to stop showing the user-key-presses.
But my program must run in windows, so I tried searching for a "stty" equivalent command for windows console, but still found nip...
?any suggestions, pointers ?
Look at Highline gem. To clarify, look at ask method and provide a block to silence it's output. It is well exemplified in their documentation
Related
I need to emulate a terminal in go. I try to do it like this:
lsCmd := exec.Command("bash", "-c", "ls")
lsOut, err := lsCmd.Output()
if err != nil {
panic(err)
}
fmt.Println(string(lsOut))
And it seems to work correctly (the native ubuntu terminal displays a horizontal list, and the result of this function goes vertically).
But if I specifically call the wrong command, for example exec.Command ("bash", "-c", "lss"), I get:
panic: exit status 127
And in the native ubuntu terminal I get the following result:
Command 'lss' not found, did you mean:
and enumeration of commands.
I need to communicate with the native terminal, and get the same thing as the result of the command if I wrote the command in the standard ubuntu terminal.
What is the best way to do this? Maybe the exec library is not suitable for this? All this is necessary for front-end communication with the OS terminal. On a simple html/css/js page, the user enters a command, after go it sends it to the native terminal of the operating system and returns the result to the front-end.
How I can get the same result of executing commands as if I were working in a native terminal?
The problem
But if I specifically call the wrong command, for example exec.Command
("bash", "-c", "lss"), I get:
panic: exit status 127
And in the native ubuntu terminal I get the following result:
Command 'lss' not found, did you mean:
and enumeration of commands.
This has nothing to do with Go, and the problem is actually two-fold:
Ubuntu ships with a special package, command-not-found, which is usually preinstalled, which tries make terminal more friently for mere mortals by employing two techniques:
It tries to suggest corrections for misspellings (your case).
It tries to suggest packages to install when the user tries to execute a program which would have been be available if the user had a specific package installed.
When the command is not found, "plain" (see below) shell fails the attempt by returning a non-zero exit code.
This is absolutely expected and normal.
I mean, panicking on it is absolutely unwise.
There's a historical difference on how a shell is run on a Unix system.
When a user logs into the system (remember that back in the days the concept of the shell was invented you'd be logging in via a hardware computer terminal which was basically what your GNOME Terminal window is but in hardware, and connected over a wire),
the so-called login shell is started.
The primary idea of a logic shell is to provide interactive environment for the user.
But as you surely know, shells are also capable of executing scripts.
When a shell executes a script, it's running in a non-interactive mode.
The modes a Unix shell can work in
Now let's dig deeper into that thing about interactive vs non-interactive shells.
In the interactive mode:
The shell is usually connected to a real terminal (either hadrware or a terminal emulator; your GNOME Terminal window is a terminal emulator).
"Connected" means that the shell's standard I/O streams are connected to the terminal, so that what the shell prints is displayed by the terminal.
It enables certain bells and whistles for the user, usually providind limited means for editing what is being input (bash, for instance, engages GNU readline.
In the non-interactive mode:
The shell's standard I/O streams are connected to some files (or to "nowhere" — like /dev/null).
No bells and whistles are enabled — as there is nobody to make use of them.
GNU bash is able to run in both modes, and which mode it runs in depends
on how it was invoked.
When initializing in different modes, bash reads different initialization scripts, and this explains why the machinery provided by the command-not-found package gets engaged in the interactive mode and does not when bash is run otherwise — like in your invocation from Go.
What do do about the problem
The simplest thing to try is to run bash with the --login command-line option or otherwise make it think it runs as an interactive shell.
This might solve the problem for your case but not necessarily.
The next possible problem is that some programs do really check whether they're running at a terminal — usually these are programs which insist on real interaction with the user, usually for security purposes, and there are programs which simply cannot run when not connected to a real terminal — these are "full-screen" text UI programs such as GNU Midnight Commander, Vim, Emacs, GNU Nano and anything like this.
To solve this problem, the only solution is to run the shell in a pseudo-terminal environment, and that's what #eudore hinted at in their comment.
The github.com/creack/pty might be a package to start looking at; golang.org/x/crypto/ssh also provides some means to wrangle PTYs.
I run calculations on Windows for hours and would like to have the calculation report/log inside the interactive IDLE/shell window be saved to a file at the end by a command.
Would be nice to exit() and close the window too.
As much as I like Linux, this is an Unattended Windows machine, hence, some modules/commands are not available, sadly, and the ability to install other software is limited.
The fact that the developers did not think of a command to save the transactions within the IDLE/shell is surprising.
I know in some environments you can direct the output of a job, like a report to another text file by using the key -o, --o, --output, > to a text file. Surprisingly Python does not support anything like that!
Any help would be appreciated
Thanks
Windows Command Prompt supports stdout redirection and probably stderr redirection. I just tested python -c "print(test)" > F:/dev/tem/out.txt and the print out went to out.txt. Replace -c "print('test') with script.py and the same should happen. Piping stdout of one program to stdin of another might work. You might be able to chain programs with a .bat file. PowerShell likely is more powerful and flexible, but I have never used it.
I am not completely clear on what you are asking, but I hope the following answers your questions.
Python runs in 2 modes: batch and interactive. Interactive mode is intended for ephermeral interaction with a human. Batch mode is for unattended computation, with occasional screen messages, but with most results sent to a file other than the screen. Both modes are combined when you run python -i xyz.py. The file is first run in batch mode, and then Python shifts to interactive mode.
It sounds like you should be using batch mode rather than either Python's or IDLE's interactive mode. If your code runs from IDLE, you should be able to run it directly with the same python.exe that you used to run IDLE. There are exceptions, of course, if one makes one's code dependent on running within IDLE, but this is unlikely to be an accident or to be needed for unattended running.
The IDLE Shell simulates interactive Python. When a file is run from an editor window, IDLE simulates python -i file-being-edited.py, with screen output going to Shell. In either case, an interactive user can save the contents of Shell with the File => Save As menu command. So there is such a command. There are also close window and exit commands and shortcuts.
In IDLE's intended use, as an interactive python learning and program development environment, there is no need from for a program to issue these commands. To save data in a file, a program can open a file and write data directly.
Try to see if you can install Jupyter Notebook (not separate software, but just a python module)
pip install jupyter
Jupyter notebook is highly helpful for saving and sharing your code. It can be used as both a shell and as a script editor.
I have been stuck for two days looking for a solution. Could anybody please tell me how to install shell commands in Atom to enable the atom command at the command line under Windows. I know that it is not installed because when I typed which atom, it returns nothing.
Reading your other thread, I understand that you want to install a package who emulates shell commands within Atom. If so, you just have to follow the installation steps for Windows on Atom's website (I think you got confused with this which command story on the other thread, which explains how to install it on Linux and macOS).
I don't really know how to execute programs with command-line in Windows, if you don't master it either, I'd recommend using the graphics mode, and simply open your README.md file with the FILE button, like in any other software.
When you have Atom properly installed, there'll be some packages created to emule a terminal with shell commands, like this one. But this is independant from executing Atom from your computer. It emulates a terminal within Atom. I hope this is a little bit clearer.
I have been testing with Codeception and PhantomJS for a while, but when ever i have to debug and run
vendor/bin/codecept run --debug
with colors set to true all i get is:
Modules: ←[33mWebDriver, AcceptanceHelper←[39m
and so on... So for some reason the color is just outputed in a raw format and is not working at all. Colors usually work. like when i use "ls --color" it just works.
My System is Windows 7 i'm using the "git bash" and i have also tried the regular "cmd" "powershell" and "cygqwin". Neither one of them seem to work with codeceoptions output.
So what is the problem? I'm clueless :(
in bash, try running
export TERM=ansi
or
export TERM=xterm
before running your program
or, to test color output from the shell itself:
echo -e "\e[41m\e[32mCOLOR\e[0m"
if that does work than it is the program, not the environment
finally, you might just need a better console.
try conemu, it has excellent ansi color support and i use it for cmd powershell bash perl and ssh sessions :)
http://sourceforge.net/projects/conemu/
Your application (Codeception) was not adapted to Windows console, which doesn't support ANSI colorizing. To enable ANSI colors you may choose one of the following options:
ConEmu is the Windows local terminal with ANSI capabilities and many other features like tabs, splits, preconfigured shell tasks, ... Also, it's the only terminal which able to "replace" default Windows console. Yep, I'm the author.
Some applications may work properly in mintty (bundled with cygwin or msys). Many native Windows console tools can't work properly in this terminal, but may be your app will be fine.
There is AnsiCon project. It enables ANSI colorizing in standard Windows console.
BTW, bash's ls (cygwin or msys) was adapted to Windows console API, so it doesn't post ANSI to terminal, unless terminal has done special initialization of POSIX subsystem. ConEmu can do this initialization via cygwin/msys connector.
I've tried using Ruby 2.0 x64 and Ruby 1.9.3 for Windows using RubyInstaller. Entering ruby -v works as expected, and running gem gives me the expected usage docs. Running and using the Interactive Ruby application works as expected. I am running Windows 8.1 Update.
However, for both installations, running ruby from cmd gives me a blank prompt where I can type, but nothing is executed when I press enter. If I attempt to install a gem, there is a similar issue where the program is running, but there is absolutely no output, and nothing happens.
I can't seem to be able to find a similar issue elsewhere. Does anyone know what might be wrong, and how I could fix it?
What did you expect to happen? ruby.exe is the ruby interpreter, meant for running ruby scripts. Normally, to use it you would create a file containing valid ruby commands with your favorite text editor (but not a word processor). If you save the file as foobar.rb, typing ruby foobar.rb (or if you told the installer to associate .rb files with ruby, typing just foobar.rb) will execute the commands in the file as a script/program. If you don't supply a script file name, ruby goes into input mode and expects you to type in a program on the spot. It won't give any feedback until you indicate end-of-file by typing CTRL-z, at which point it will process what you typed and most likely tell you about all the errors you made. If you want line-by-line interactive feedback, use irb.