My knowledge on terminal emulators is a little sketchy, and in an effort to learn more about them, I thought I could experiment with some of the escape sequences and see what I can do. One of the things I thought of to try was (pseudo-code):
pushTerminalState()
writeSomeDataToTheScreen()
popTerminalStateToRestoreItToTheWayItWasBefore()
In researching how to do this, I came across two control functions
DECTSR - terminal state request
DECRSTS - restore terminal state
However, I am unsure how to use them. For the DECTSR function I am trying process.stdout.write('\x1B1$u'). According to the note on the DECTSR page, this should give a "response", but I am unaware as to where I should "read" the response from? I naively attempted to read from STDIN, but as expected I only received keys from my terminal.
Any tips on what I am doing wrong?
Related
I'm wanting to make an application with node have a cli interface, as it needs to be ran in a terminal. I want to split the terminal into several sections, one with some identification as to who is viewing the application, another with some other random info, a menu on the side that you can use the arrow keys to move up and down the options, a main logs section, and another that you can type, and press enter to send text in. I've drawn up a little diagram of how I want to make it: (I know this looks awful, it was made in mspaint)
I've gotten the console input part working by using the readline module, but I don't even know where to really start with designing the terminal how I want it, setting text in certain sections, etc. I've looked around at things like terminal-kit, and clci, but either they didn't seem like what I wanted, or their docs/examples were a mess.
I would prefer to do this with node only, not using another application in another language, as all of the stuff going to the console sections will be from the same node application.
I found the blessed library at https://github.com/chjj/blessed. It is based on the ncurses library (written in C, https://en.wikipedia.org/wiki/Ncurses) and it allows you to create different sections with specified heights, widths, etc. in different areas of the terminal. Very useful in theory, and you can follow the advice on the github page, clone the repo into your desktop, look into the test folder, and then run the different files ie. node test/widget-form.js to see the different types of interfaces that you can create in your terminal.
It hasn't really worked for me, because it keeps crashing on my end, but I see that there are a lot of open pull requests and that people are still trying, so it might be working for some, although I think that the usage for some "widgets" is limited. The next best thing I can recommend is either blessed-contrib or neo-blessed, the former being developed by some dude from Facebook. Blessed-contrib is newer so you might have more luck with it, but it's essentially made for visual output, so you'd be able to create a section for a log, a selection menu, a paragraph section, etc. but nothing to create an area where you can input text (so 4/5 of what you need), based on my reading of the documentation, which you'll find here https://github.com/yaronn/blessed-contrib.
I personally think it's dope. Good luck with it, I'm going through the motions of understanding the documentation better myself, and I've delved pretty deeply in it, so feel free to reach out if you need any help.
On another note, let me know if you've found anything else other than the resources I mentioned, which would be very helpful for me, as the alternative right now is for me to code the text user interface myself using C and the ncurses library, which I'm trying to avoid if it's unnecessary :)
EDIT:
I found something for you and for me that might send us in the right direction. Good news. This is the gitter-cli. It uses the library I mentioned above blessed. If you clone the gitter-cli's repo, follow the instructions to get a token and create an account, and join one of the rooms (you can find the name of the rooms like 'gitterHQ/javascript' on the gitter.im website), you'll see that the chat works. There might be some optimizations I'm not aware of, but I recommend just delving into their code while also delving into the blessed documentation to understand how it works. It should give you an idea of what to do next.
It took me a lot of hours to find all these different resources and connect the dots so you should definitely check them out.
For Google Chrome Extension, is it possible to record the sequence of line numbers (with file names) (with the existing variables values in case of JavaScript) that are executed during the execution of HTML/CSS/JavaScript?
This is certainly possible but exceedingly difficult.
One can, in principle, implement it using chrome.debugger API, which gives the same access to the page as DevTools.
However, that API basically consists of sending almost-raw Remote Debugging protocol commands, and there aren't many samples to go on with. Debugger domain seems relevant.
So, it's possible but it's a lot of work, and additionally it's going to slow execution to a crawl.
As such, this is not a good problem to solve with extensions. It's better served by modification of Chromium code and maybe existing debugging capabilities of it. Basically, to efficiently output this information you need to get down to browser internals.
I've started working on a little project in Lua that involves making a text-based interface that updates constantly, and allows keyboard input for interaction.
I need a way to get keyboard input, but I also need it to either not block, or have some kind of timeout (which can be set to a fraction of a second, preferably). I've done research myself, but I found nothing that worked for me.
I need something that works with Lua 5.1.5 and Linux. Windows compatibility would be nice, but is not a requirement as I'm also doing things that require an ANSI terminal.
As stated in the comments of my post by hyde, I can use a Lua wrapper for ncurses to get input. In addition to this, I can use its features for some other parts of my code that I was going to program myself anyways.
I'm doing this in Lua 5.1 with Luasocket and opening two separate Lua processes. I have two Lua console windows- "INPUT WINDOW" AND "OUTPUT WINDOW". INPUT WINDOW sends keypresses over localhost. OUTPUT WINDOW reads the localhost socket I'm using for this. It's non-blocking; you can set a very quick timeout on the udp receive. It's ugly, but it's the most vanilla solution I've found. That said, input data from INPUT window doesn't appear on the OUTPUT window (unless I want it to), which can be nice for a console-based UI.
On linux, console applications have the ability to format their output. They can set font color, set background color and can place signs everywehre on the console. Using that it is, for example, possible to implement a tetris game right into the console.
I´m wondering how one can do that. I think they use a output markup language or something else. Can anyone tell me where I can learn more about this?
Thanks very much!
Most console applications involving a lot of motion or color are built using the ncurses library. Some very common examples would be irssi (IRC client), mc (Midnight Commander, the console file browser), mutt (POP3/IMAP mail client)
It seems like you are already aware of the escape codes used to modify console colors. A good list of console color escape sequences (for Bash) can be found here.
You obviously need to get a hold of those every-popular Unix video games, rogue, srogue, larn, hack, and/or nethack. They have a long and venerable history.
Notably, these all use the standard curses — or more recently, ncurses — library. Here’s a screen shot.
Since they have no joystick, motion is with vi commands. They are hands-down the very best way to hone your vi motion skills ever invented: no more two-finger typing for you! You stop thinking about motion; it just becomes a part of your fingers’ muscle memory. You really have to play them to get a feel for the awesome “Zen” state you can get into playing them:
After enough practice, it feels as though your fingers themselves remember how to play the piece. You don’t even watch them. They've a job to do, and once they’ve learned it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world, so that the program becomes the dominant reality, is what a musician would call “finger memory”. (You might have heard athletes or dancers refer to it as muscle memory, but when we’re talking about using the computer, it really is the fingers that count.)
[...] Of course, that's not really what’s going on; it only seems to be. Your fingers don’t really remember. But a part of your brain that controls them does, even though “you” don’t realize it. What’s happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you’ve trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. [...]
[...] There’s no question that, for certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn’t want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse‐and‐menu interface instead of a keyboard one would slow you down by at least two orders of magnitude.
The rogue family of video games are also notable for showing how to write a video game for a regular terminal like a vt100 or an xterm, which I believe is what you are looking for. I’d probably use a more modern language than C these days, but all the same principles still apply. Both Perl and Python have good interfaces to these standard libraries.
It's not so much a markup language as a series of escape sequences that trigger the terminal viewer to format in a certain way.
You can send ANSI escape sequences before your output to indicate that the following output should be a certain color, weight, background. You can also send sequences that jump the cursor to specific locations to continue writing output.
If you are going to do a full blown app you should consider using some library such as ncurses which makes these manageable.
This is one of my assignments and I need some help in getting started. The basic idea behind the assignment is that I have to design a self destructible email program that is capable of destructing the message after (n) time duration.
Speaking about self destructible emails, there are quite a few ones on the internet offering the same service. But what they do is, they just convert the email message into an image and store them on their servers. Now, they send the message attaching the image inline with it. After they receive a hit on that image (which means that the message was being opened), they simply delete the image and the inline image link breaks! BOOM!
IMO, that's not what a self destructing email should be like. Nevertheless, in my case, I have to take care of following points:
I have to do it for TEXT. No image, nothing else.
I have to assume that the systems used throughout the process will be UNIX based (I don't know how that is going to make a difference).
There are also some hints regarding the usage of various network layers in solving the problem.
This isn't supposed to be done "in general". What I mean by that is, I have to do that ONLY for one/two UNIX systems. Let me put it this way, all I have is two UNIX systems and nothing else. Now I want to create a program (in UNIX itself) that would do that self-destructing thing. I have total control of protocols and the network layers and I have to code anything and everything required at any level.
This is more geared towards the StackOverflow side of things but I have no problem getting you started.
The first thing I'd like to point out is that you seem to be heavily over-analyzing this. The services that have self-destructing e-mails which are image based are simply deleting a file after it is viewed. All you need to do differently is put that text in a file and get it's contents before deleting it. This fits well with the UNIX philosophy since so many programs already make use of flat files.
The part you seem to have left out is how you are building this. You describe it as an e-mail program and then talk about web services. Is this a web-based project or a program you are designing for Linux? Do you have to code everything from scratch or can you parse output from Linux utilities to grab the mail? These kinds of things really would simplify the process.