I'm currently setting up a node.js server and I'm using the debug module here https://github.com/visionmedia/debug.
I'm trying to enable it so I can get the colored debugging information in my output, however my terminal looks like the last terminal screen at the bottom after it says:
When stdout is not a TTY, Date#toUTCString() is used, making it more useful for logging the debug information as shown below:
Can anyone shed some light on this? Thanks.
tty is one of those funky Unix commands that prints (or, displays) to standard output the name of the terminal connected to standard input.
These are commonly used as a way to get access to the computer to fix things, without actually logging into a possibly b0rked desktop.
Related: What is tty7 in the commandline?
By default Ubuntu has 7 tty's.
1-6 are command line only, 7 runs your X session (your normal desktop).
To access them, use this keyboard shortcut:
Ctrl + Alt + F1
(changing F1 to F1-F6 to access the terminal that you need)
To get back to your X session (the normal desktop),
Ctrl + Alt + F7
The TTY is the terminal or command prompt itself.
The screenshots are demonstrating the different results when stdout is directed to the terminal/TTY (with colors and time diffs) vs. when it's redirected elsewhere, such as to a file (via > out and with timestamps).
It determines which format to use with tty.isatty.
Note that not all terminals support the ANSI escape codes it's using to display colors.
Related
The script should treat 'enter' as sending the users string but instead it just prints '^M' to the terminal.
I'm not sure why this is happening suddenly, it wasn't happening yesterday. Something has changed about this particular terminal session because if I open a new terminal window it works as expected in that.
Any ideas?
I'm using iterm on Mac (xterm?)
TL;DR: just type the reset command on the OS shell whenever the terminal starts acting funny.
Terminal emulator programs (as iterm) feature complicated internal states in order to provide literally decades of features to allow prettier programs on the terminal.
Terminals started as keyboards that would physically print the typed text into paper, back in mainframe era - and "stdin" and "stdout" concepts: a single stream going forward with all data that is typed and another with all data that is printed out, are up to today, more than 50 years later, the default way to interact with the text terminal.
Internal state changes by programs that deal with the terminal in different ways (like being able to read a keypress without waiting for "enter"), should be reverted when the programs terminate. But due to errors and bugs that is not always the case.
I don't know which possible state would change "ˆM" to be displayed instead of a CR code being applied to the terminal. There are tens or hundreds of other possible misbehaviors, including completely messing up all characters. The reset command in modern *nixes (MacOS, Linux, BSDs) will fix everything.
Although, of course, if "enter" is not being applied, it won't be possible to issue the command at all from the os shell. You will have to start a new terminal session then. From within a Python program, if you happen to make a call to some code that will always break the terminal, you might run "reset" as a subprocess by calling os.system('reset').
In particular, "ˆM" represents "ctrl + M", which is a control character with value "13" (0x0d in hex). It is the value for the "Carriage Return" control code (AKA. "return", "enter", "CR"). If you never did this: try pressing "ctrl+M", and see that it behaves the same as "enter". It is being displayed in "human readable form" instead of acting as a control character in your case.
(regarding xterm and iterm: all they have in common is that they are both "terminal emulator" programs, xterm being one of the oldest existing such programs, which probably pioneered a lot of adaptations from text-only video modes to a graphic environment. "iterm" is just a normal modern app which implements terminal functionality)
I work with ZOC terminal installed at windows 7 in order to communicate with device that has Linux operating system zoc picture.
The communication via terminal works great but recently the text has been cut halfway down the page.
attached picture .
The picture shows 24 lines. You can get this behavior if your terminal description sets scrolling margins to 24 lines — as some might do, when initializing the terminal if the application assumes that the screen has 24 lines.
Since ZOC could be connecting via a serial port, that may not allow negotiations about window size (NAWS). You might then see that stty -a shows 24 lines in its output. ZOC is said to emulate a VT100; you can usually adjust its notion of screensize either directory (using stty) or using the resize program (which calls the same system functions as stty as a side-effect).
Alt+y solved the issue I had..
I just ran a script on a server that generates a lot of output on the command window.
However, now, after running it for roughly 4 hours I want to check all the output, but the beginning of the output has already disappeared from the terminal window. When I scroll up, it is not there anymore.
Is there any way to access this? It needs to be via commands in the terminal because I'm running it on a server.
Thanks.
Best way is to redirect the output to a file & open the file to check for all the output.
You can also redirect the script by running it in background & saving the output to a file. Do let me know what type of command you are running for which I can give you the exact command. :)
if it's a real terminal and not a virtual terminal
you need to recompile your kernel and increase the buffer size of your terminal.
in the .config file of your kernel the parameter you need to increase is
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE
Actually, redirecting I/O interferes with many programs (for instance, changing the output from a tty to a plain file). Use the script program to capture all output from programs run in a shell, with minimal interference.
I want to know if anyone does know a way to dump or copy the whole lot of viewable messages in a xterm window on linux. The very important thing is I don't want to know how to send a command out and kapture its output for stream 1 and 2 as well as the input, as this is well known to me.
I may explain for what this is needed. You do something and expect not any complications but than you got pages of msg's als err msg or normal output. To be able to see later after it you should be able to get them in a file and as long as you are able to scroll that all back and forther with your mouse it is sure the data is there some where. But the time may be not to scroll and screenshot and scroll ....
I would be glad to help me out in such cases and it would be fine to have the full view including all your own typing and all the msg's in same order as you watch it when you scroll it back.
I don't really know where this is stored and how you could get that saved. I know that I could dump the whole lot of Memory and search it for a part of the xterm window, but that is a bit over the top I think.
There is a control sequence, which I had forgotten. This question reminded me. In XTerm Control Sequences, it is noted "print all pages":
CSI ? Pm i
Media Copy (MC, DEC-specific).
Ps = 1 -> Print line containing cursor.
Ps = 4 -> Turn off autoprint mode.
Ps = 5 -> Turn on autoprint mode.
Ps = 1 0 -> Print composed display, ignores DECPEX.
Ps = 1 1 -> Print all pages.
That dates from 1999 (patch #119), so you likely have it in your xterm. You could do this in a shell command like this:
printf '\033[?11i'
A comment mentions the page Hidden gems of xterm, which uses the corresponding action print-everything (something that can be executed via the translations resource). It is in the manual page, of course. The same comment points to Extra characters in XTerm printerCommand output, which mentions the resource printAttributes. By default, the control sequences for the printer tell xterm to send extra control characters (to reconstruct video attributes). The resource can be modified (set to 0) to suppress that. That is even older (patch #74).
Without that — Conceivably one could construct an application which used the X SendEvent protocol to construct a series of events which would be interpreted as xterm actions to scroll back, select text and copy it chunk-by-chunk via the clipboard. You could even write it in Perl (there is a module for X protocol). But seriously, no.
If you want to capture text which was written to xterm, you can do this by preparing before the text is needed by different methods (see manual):
turn on the xterm logging feature (not that user-friendly because it generates the filename). This can be enabled using the "Log to File (logging)" menu entry.
use the printer control sequences to write lines as they are written (again, not that friendly, though there is a menu entry to turn it on and off, "Redirect to Printer (print-redir)")
use script to capture all output to the terminal. I use this, because it works with any terminal on any POSIX-like system (even Cygwin).
Each of these methods produces a file containing escape/control sequences, which requires filtering out. The hypothetical program using SendEvent could in principle eliminate that.
There are multiple questions that ask about capturing keystrokes, but the solutions provided have some complications.
ncurses termios structure/stty
-Changes the console settings so that SIGSTOP/SIGTERM would leave the setting in effect for the terminal.
X based solutions
-requires X server to be running(not that is is a huge problem, but it seems unnecessary to bring X server calls into a console application)
/dev/input/event*
-requires root
Vim seems to be able to capture keystrokes without root, an X server, and without changing the console settings. Does anyone know how vim is able to achieve this in linux?
Look at TTY raw mode -- there is a ioctl call which allows you to get individual keystrokes -- i.e. taking the tty out of line mode which is the default.
A quick search on ioctl raw give this link which looks ok.