I am coding with Go 1.2 on Ubuntu 12.04 LTS machine - using LiteIDE (very pleased with it).
I downloaded and installed the go termbox package - built the demo keyboard.go - built fine.
But when I run from LiteIDE, I get this panic - same happens with all the termbox demos:
panic: open /dev/tty: no such device or address
Any clues would be helpful....
OK, that's completely reasonable: interactive terminal applications require, well, terminal to be available. Terminals may be real—hardware—or virtual (like Linux virtual terminals you see on a typical x86 box when you hit Ctrl-Alt-F1) or emulated (like those provided by xterm, rxvt, GNOME Terminal and a ton of others).
Contrary to Windows, in which running a program of type "console" forces a console window to be created and an application attached to it, on POSIX systems there's no "types" of applications, and if an aplication wants a real terminal available for its I/O it performs a special check for this, and if that fails, the application signals an error and quits1. Very few folks have access to real hardware terminals these days so most of the time emulation is used, and then we talk about the so-called pseudo terminals. Linux virtual terminals and GUI terminal emulators and terminal console multiplexors like screen and tmux—all of them allocate pseudo terminals for running programs they control.
So basically you have these options:
Find a setting in your IDE which makes it allocate a pseudo-terminal when running your program. Some programs are able to do that by embedding a terminal emulator into their UI or by running it explicitly.
Teach your IDE to run your program in a terminal emulator. Most of them obey the convention established by the venerable xterm and accept the -e <program> command-line option, so instead of
./myprogram
your IDE should run
xterm -e ./myprogram
If you're on a Debian system or its derivative, you might get away with
x-terminal-emulator -e ./myprogram
which is supposed to spawn your preferred terminal emulator program.
Stop running the code in the IDE and do it in a terminal emulator using the regular
go build
./myprogram
workflow.
I've never used LiteIDE so have no immediate experience with how to do that in it—you'll have to do your own research.
1 Some programs may happily work with or without being attached to a terminal, with shells (like bash or zsh) and interpreters (like Tcl or Python) being good examples: when they detect a terminal device available, they go into interactive mode, enable line editing and so on, otherwise they just read the code from their standard input and execute it. Another good example is Git: its high-level programs detect if they're attached to a terminal and if so they might enable colouring of their output and automatically spawn a pager program if their output if about to overflow the single screenful of lines; otherwise they cut the fuss and just dump their output to their standard output stream.
Related
I would like to know how to use Windows Terminal on PhpStorm?
I went to "Settings> Terminal", and tried to change the terminal path to :
C:\Users\user\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe
But no effects
I don't think it's possible: Windows Terminal is not a shell, it's a terminal emulator that has its own window/UI. It is just another front end to the existing shells that runs a shell (powershell, cmd, wsl) under the hood. PhpStorm provides its own terminal emulator in Terminal tool window. It's impossible to integrate one terminal emulator inside another, because all integration is based on parsing ANSI/VT sequences from underlying shell.
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 use gdb version 7.0 for debugging from emacs. The gdb when launched from emacs behaves slighlty differently compared with one launched from the shell. The points of differences are :-
gdb prompt, when launched from emacs doesn't recogonize the files in the current directory (from which the gdb session is launched.) This very cumbersome as when you run the application through gdb (using run), you have to give the full absolute path of the file. This is not the case when you launch the application through gdb from shell.
The arrow keys (that give the most recent commands typed on the gdb prompt), doesn't work for gdb launched from emacs. Instead, it moves the scroll up and down in the emacs gdb command prompt. Am I doing anything wrong here.. ?
Thanks and regards
since you are in a buffer, up and down move up and down in the buffer. most of the emacs shell-like buffers access the command history using "C-up" and "C-down".
I'm a long time GNU/Linux user. Even though OSX is much like GNU/Linux is many ways, it differs in some. For example, when I install Firefox I expect to be able to run firefox in a shell to start it. But not in OSX.
That gives me some trouble when running Emacs batch scripts. Lets say I have this script:
#!/usr/bin/env emacs --script
(message "Hello world!")
I can run it without any problems. But I'll be using the emacs builtin to OSX. And most of the times that's not possible since the Emacs version is pretty old.
Installing Emacs from scratch made it possible to create a Bash-script, which called some emacs binary file.
But installing Emacs from http://emacsformacosx.com/ I can not make this work. Can anyone think of a solution for this?
(1) Launch Emacs.
(2) Open Activity Monitor. (Applications > Utilities > Activity Monitor)
(3) Find Emacs in the list of running processes, under "Process Name".
(4) Select it.
(5) Choose "Inspect" from the Toolbar.
(6) In the window that opens, choose the "Open Files and Ports" tab.
(7) The name of the Emacs executable currently running should be the second line in the list. (The first line should be /Users/yourusername.) In my case it's /Applications/Emacs.app/Contents/MacOS/Emacs, which is pretty standard.
Yes, you dig out the path to the Emacs app emacs.
I've got X EMACS on my machine (not an emacs app), but the path will be something like
/Applications/Emacs.app/Contents/bin/emacs
You can find the exact path with ls from the command line.