I have a Tcl/Tk expect script, and log information is logged to external log file.
I can execute it on Linux server successfully without any wrong, and the log file do not have any weird ^H. But when the script is called by Jenkins job, run on the same Linux server. the log file will have a lot of ^H, And the expect will timeout.
What the possible reason could be?
The ^H is actually the backspace character, U+000008, and it is used in terminals (and terminal emulators) to move the current character insertion position one place to the left. This is used in turn to simulate various kinds of effects, such as making a character bold (by double-striking) or giving it an underline (by putting a _ on the same cell). Think like it's going to a traditional teletype, which prints things into the same position twice. It's definitely a hang-over from
the old days.
It seems that Jenkins (or maybe whatever it is calling, quite possibly maven though definitely not necessarily!) is using that device to back up over what it has written so it can write a new value there instead, probably for something like a simple download progress meter. Things that are writing to what they think is a terminal sometimes do this. You'll just have to cope. A \b in your Expect regular expressions will match it, though it is possibly unwise to do so, as whatever is being overwritten is transient info. If the characters are being written to a file, the col program (part of the nroff/groff suite) can be used to strip them; that might be easier.
Be aware that there are other ways that software can achieve the same effect, such as writing just a carriage return (which puts the cursor back at the start of the current line).
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 am using node.js to write a command line interface that generates unit test files. I have been using inquirer to get user input, however there is one field in which the user will very likely want to copy-paste and/or edit, large multi-line chunks of JSON data. Therefore, my goal is to:
open vim # certain point in CLI -> allow input-> close vim -> write out to tmp file -> process the result.
The problem is that input to vim is also going to the parent stdin, and when the return key is hit, the program continues on top of vim (mayhem). I'm fairly certain that stdio/in/out/err are not set up properly, but i cant seem to find the exact solution anywhere. Every iteration of my manipulating the streams seems closer, but i know that there is a small missing link.
i have tried a lot of things along the lines of:
var vim = child_process.spawn('vim', [path], {stdin: 'pipe', stdout: 'pipe', stderr: 'pipe'});
var vim = child_process.spawn('vim', [path], {stdio: 'inherit'}); //{stdio: ['pipe','pipe','pipe']}
Finally, i have followed a lot of the stdio manipulation from this example, How do I open a terminal application from node.js?, but there still remains some small missing link that i need help with
Notes:
I am 99% certain that my async promises are in order.
it doesn't necessarily have to be vim, as I am checking the ENV for
an editor first
I liken this to git commit, where an editor pops up and allows input
before closing
in a small test program, i can get perfect functionality, but when
trying to do this over another process, it doesnt go well
tl;dr : i want to ignore the parent process while input goes only to vim (child_process), but i cannot keep them separated, and because of this, the program goes haywire
If there is anything i can clarify, please let me know.
Thanks!
I know this is old, but anyway 6 days ago they released a function with 2015.02.06 Version 0.12.0 (Stable) that makes this very easy.
var spawnSync=require("child_process").spawnSync;
spawnSync("vim",[__filename],{stdio:"inherit"});
It will of course block the event loop, but in such a situation you likely want to wait for the user. Otherwise, you may end up with node writing to stdout and reading stdin while you are editing, which is obviously very confusing, and is the issue you were running into.
If you really still need asynchronous stuff while you are editing, it's probably easier to require("child_process").fork so you don't confuse the stdin/stdout. I imagine you could do some fancy stuff to remove all the listeners and add them back later, but it's probably not worth the effort.
I can scroll trough bash output using shift+pgup/pgdown.
But lets say, some command outputted lot of text, I have to pageup few times to go to beginning of output of this command.
Can I just simply do this by some shortcut? Something that simply allows me to scroll between previous commands (not history!), seeing their output.
You could try piping the output into less:
someCommand | less
less will allow you to search and scroll through the output text pretty easily.
once in less you can just type % to jump back to the top of the page. Essentially that means jump to 0% of the page. There are also a bunch of extra commands on the page I linked to above.
Another option is to use screen and use backward search (beware: read the Overview first, especially the part about the C-a prefix) to e.g. search for some specific characters in your prompt (like your username).
The scroll back history in Unix shells is a shell specific functionality, meaning that it is up to the specific shell (xterm, rxvt, text console, etc) to handle it. The functionality you request would require the shell to identify the individual program runs, to know where to scroll to. Scanning text is not technically hard per se, but as prompts and command display can differ due to user settings it can be hard to make it work generally good. Some communication between the shell and the terminal could make it better.
There sure are some nice fancy terminal programs doing things like this, to for example show syntax help when writing commands, but for your case I agree with previous answer, that piping commands to less is a good way to isolate the output. It might be a bit cumbersome first, as it requires you to think about it first, and not just go back in history, but if you learn the shell better and learn to use the command history it will probably work fine. I recommend you to, if you haven't already. What I mean is ctrl-r etc. More described for example here:
http://www.catonmat.net/blog/the-definitive-guide-to-bash-command-line-history/
Here's my issue. I'm outputting directly to console and also getting user input via the terminal. Sometimes, the user is typing a thing and then the text they were typing gets messed up when the console outputs something. It doesn't break the program, it's just annoying.
I looked at ncurses in the npm catalog, but it seems pretty complicated. All I want is to print stuff to the screen without disrupting user input.
Any help, and I do mean any help, is very much appreciated.
How are you reading from the terminal? If you're doing it in "raw" mode where you get input for each character (or each few characters), then when you get a character, set an "output inhibit" flag and also set a timeout that will clear the flag when the user has stopped typing for a bit. Whatever does your output needs to check the flag and hold off if it's set.
Alternatively, if the user is typing line-by-line, you could set the flag on each character and then clear it (and simply flush your output) when they enter a newline.
If the terminal is in "cooked" mode (your code doesn't see anything until the user types a newline) there's really little you can unless you bite the ncurses bullet.
Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.