Command that launches a graphical text input box that outputs to stdout - shell

Is there such a program that can open a little input box and send the input to stdout? If there isn't, any suggestions for how to do this (maybe python with TkInter)?

If you're looking for something that works in text mode, then dialog or whiptail are two options.

The oldest would probably be dialog. Another example of such a program is Zenity and another would be Xdialog (all pretty much replacements for dialog).
They tend to do more than just accepting user input, and you can create some fairly complex GUI dialogs with them, but are simple enough to do what you want very easily.

Related

How to keep terminal input always at bottom in Golang?

I am trying to create a program which will have live updates from some data source. And I also want to wait for user input just like a normal terminal. Right now, whenever there is update, I will print the content and print the prompt message for input again which create something like this:
Enter command >
This is a live update message
Enter command >
This is a multi-line li......
......ve update message
Enter command > quit
Bye bye!
The problem is that for every live message I received, I will print it and the "Enter command >" will be displayed again again and again, which is not desired. I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
The closest package I can found on Github is https://github.com/gizak/termui but most of the examples inside is trying to display text, gauge and graphs. So I am not quite sure how to get started.
Is there any package or example of the termui package to achieve this? Thank you.
With github.com/gizak/termui you're heading in the correct direction.
To understand why you can't get that
I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
part sorted out, a little excursion to the history of computing is due. ;-)
The thing is, the mode your teminal emulator¹ works by default originated
in how computers would communicate to the operator in the era which predated
alphanumeric displays — they would print their responses using a line printer. Now think of it: a line printer works like this: it prints whatever is sent to it on a roll of paper. What was output, was output.
The new output always appears physically below the older.
When alphanumeric displays (screens) came into existence they
naturally continued to support this mode:
the line text to be output was rendered at the bottom of the screen
with the text above it scrolled upwards.
That's what you see in your typical terminal emulator all the time when you're working in the command line of a shell (such as bash) running by the emulator window.
This, default, work mode of a terminal is called "canonical" or "cooked".
Then came more advanced displays, for which it was possible to change
individual positions on the screen — identified by their column and
row numbers.
This changed the paradigm of how the information was output: the concept
of a so-called "full-screen application" was born.
Typical examples of them are text editors such as Vim and Emacs.
To support full-screen text output, terminals (and terminal emulators)
were adapted by implementing certain extensions to their protocols.
A full-screen application first requests the terminal to switch into another
mode called "raw", in which the terminal sends most of what is input by the
user directly to the program running on the terminal.
The program handles this input and orders the terminal where and what
to draw.
You can read this good summary
of the distinction between the both modes.
As you are supposedly suspecting by now, to be able to keep some block
of information at a certain fixed place of the terminal's text screen,
you want your program to be a full-screen program and use the terminal's
raw mode and its special commands allowing you to directly modify
text at certain character cells.
Now the problem is that different terminals (and terminal emulators)
have different commands to do that, so there exist libraries to isolate
the programs from these gory details. They rely on the special "terminal
information databases" to figure out what capabilities a terminal has
and how to make it do what the program asks.
See man terminfo for more background.
The most widely known such library (written in C) is called ncurses,
and there exist native solutions for Go with supposedly the most visible
one being github.com/nsf/termbox-go.
The github.com/gizak/termui makes use of termbox-go but for you it might
suffice to use the latter directly.
¹ Chances are very high you're not sitting at
a real hardware terminal
connected to a UNIX® machine but are rather working in a GUI application
such as GNOME Terminal or xterm or Termial.app etc.
These are not "terminals" per se but are rather
terminal emulators —
that is, pieces of software emulating a hardware terminal.

Bash script with graphical menus

I have been writing simple bash scripts for a while now, and I was wondering how I could implement simple menus and, if possible, use menus with color.
In the past, I have written simple C applications that use ncurses and would like to (if possible) have menus in my bash script where the user can use the up/down arrows to select items in a list, and go back/forth through a series of yes/no/cancel prompts.
I am familiar with setting up colored text in bash, so there's a start (eg: bash using colors), so the only requirement left at this point is to see if bash has these capabilities. I would prefer to avoid having to code an application in C/C++ for this, as I would like to be able to edit it on the fly.
there is a package called dialog, is this relevant to your requirement?
I haven't used this myself, but have you checked out bashsimplecurses? From the documentation, it looks like a possible solution.

Vim Question Regarding Views

I have been reading a lot of the questions here on vim. I can't locate something that I want to do with vim but I am sure its possible.
I like vim(I am still new at it) using tabs and I have adjusted my vimrc so that H & L keys take me back and forth between tabs.
I was hoping to find a way to be able to use tab commands to open up a tab as output, so that if I am writing something in my case Ruby and I want to test it I could run it and flip to a new tab with the output. Or flip a tab to an interactive console to test code. This is possible?
As an aside is it possible to expand tabs to views so if I had two tabs open say script and output I could :spx or similar and have tabs come to split screen.
You can load the ruby output into a vim window in a couple of ways. One way would be to open a new split window and then load output of command:
" vimscript command to open new split window
wincmd n
" run ruby command and insert output at line 1
1,1!ruby foo.rb
alternatively you could get view the output on a new tab with a single window:
tabnew
1,1!ruby foo.rb
I know it's not the answer you want, but use buffers and ditch the tabs. I have a screencast going over how to use splits to manage your window.
http://lococast.net/archives/111
As for the ruby output, that seems like it might be covered here:
https://superuser.com/questions/133886/vim-displaying-code-output-in-a-new-window-a-la-textmate
In answer to your question about opening up a tab as output, I don't think there's any built in way to do this. There's the RunView plugin (see my answers to this question and this one), but I don't think that it supports using a separate tab (it works with a split window: what I think you refer to when you say 'view').
Regarding an interactive console: no, this is not possible. See :help design-not.
As for general use of Vim, try to get used to the idea of buffers and the fact that each 'view' (my term), whether it be a split window, a tab or whatever is just a means of looking at a particular buffer. You can have multiple views on a single buffer, so you can have a source file vertical split with two headers in one tab and the same source file vertically split with another header and a different bit of the same source file in another tab. This is very powerful once you get used to it. The Ctrl-W keyboard shortcuts are your friend (e.g. Ctrl-W, h to go left one window).
As for changing a tab into a split window, I don't think there's a direct way to do this (how would Vim know which tabs you wanted to join?). You can break a split into a tab with Ctrl-W + T, but to go back you'd have to create a couple of mappings. This is off the top of my head but something like this might work:
command! TakeThis let takebufnr = bufnr("")<CR>
command! SplitTaken exe 'split #' . takebufnr<CR>
nmap ,t :TakeThis<CR>
nmap ,s :SplitTaken<CR>
Then press ,t on the buffer you want to grab and ,s on the one you want to split with the 'taken' buffer.

Mac-Automator, How to pipe the output of a shell script to a GUI text box

The problem I face is this:
I would like to have in a context menu (when i right-click on a folder) an action to be executed and display the output to the user, inside, let's say, a text area window with a vertical scrolling bar. Suppose, that the action is just a shell script that executes a "find" command inside the given directory, searching for a specified pattern.
I have managed to implement it, up to this point, using Automator. What I cannot do is to pipe the output in a synchronous fashion (what is meant by "synchronous" is to have the output print to the user when is produced by the "find" command, and not after the command has finished) in a GUI.
I have spent sometime searching on this and I have come to the conclusion that XCode and Interface Builder have to be put into the play? Am I on the right track? Is there a straightforward and simple way in succeeding in this without having to dig into this framework?
Thank you very much,
Babis
You can have the shell script throw a dialog when it gets the result using http://cocoadialog.sourceforge.net/

Windows text editor that shows/hides lines based on RegEx or Grep syntax?

One of my application components produces some extremely hairy log files. They require a lot of poking and prodding before they produce useful information. I'm on the hunt for a text editor for windows that will let me enter text in either RegEx or Grep-style syntax, and automatically show/hide the relevant lines.
Does anyone know of a text editor that has this feature?
Thanks!
IVR Avenger
I know it's answered already, but http://glogg.bonnefon.org/ is the perfect answer for this. Couldn't live w/o it.
I would recommend Notepad++ as far as a good all-around Windows text editor is concerned - it is very extensible and includes just about every power feature you need to wade through data logs. If your log files are in a well-defined format, you can even use the built-in language editor to define a custom visual scheme for your logs - easier on the eyes.
-matt
GVim with for example, :g command. There are also plugins that allow entering search criteria, and they show relevant lines, and fold everything else.
Emacs, of course (occur), but I think pretty much every editor will do this.
Another option is SlickEdit using it's "Selective Display..." option
Although it wont show/hide based on a regex, Textpad will allow you to search and produce a hyperlinked result file with the lines that will allow you to click into the actual log. Consider the benefit: You can keep the filtered results up on your left monitor, and you can click into the full files and show them on your right monitor to see the context.
SPFLite is free and does just what you want. At least the IBM SPF and ISFP (used on IBM mainframes as part of the MVS operating system) that it emulates is just what you want.
From what I have tried, SPFLite will probably do the job. It can X (exclude) all lines from view, or eXclude lines with a given character or phrase (optionally starting in a certain column) from view. Or after eXcluding all lines, you can display, by Finding, characters or strings (optionally starting in a certain column). I think it also has a macro capability. The original does, and I think this Lite does as well. How robust I do not know. The original could create interactive screens and programs using the MVS TSO Command Language.
I found SPFLite at http://www.spflite.com/
I found that this interface is not so easy to use, but one gets used to about anything if necessary.

Resources