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.
Related
I know from experience that if I try to open the same file in Vim in multiple terminals at the same time, I get an error. (Maybe because of temporary files?)
And I know from experience that if I open a text file in Python and read through it, I have to reset the pointer when I'm done.
But I've found that if I run the same Python script in multiple terminals at the same time, I don't get any error; it just successfully runs the script in both. How does this work? Doesn't Python need to read my script from the beginning in order to run it? Is the script copied to a temporary file, or something?
I know from experience that if I try to open the same file in Vim in multiple terminals at the same time, I get an error.
That's not actually true. Vim actually will let you open the same file in multiple terminals at the same time; it's just that it gives you a warning first to let you know that this is happening, so you can abort before you make changes. (It's not safe to modify the file concurrently in two different instances of Vim, because the two instances won't coordinate at all.)
Furthermore, Vim will only give you this warning if you try to open the same file for editing in multiple terminals at the same time. It won't complain if you're just opening the file for reading (using the -R flag).
And I know from experience that if I open a text file in Python and read through it, I have to reset the pointer when I'm done.
That's not exactly true, either. If you make multiple separate calls to open, you'll have multiple separate file objects, and each separately maintains its position in the file. So something like
with open('filename.txt', 'r') as first:
with open('filename.txt', 'r') as second:
print(first.read())
print(second.read())
will print the complete contents of filename.txt twice.
The only reason you'd need to reset the position when you're done reading a file is if you want to use the same file object to read the file again, or if you've opened the file in read/write mode (r+ rather than r) and you now want to switch from reading to writing.
But I've found that if I run the same Python script in multiple terminals at the same time, I don't get any error; it just successfully runs the script in both. How does this work? Doesn't Python need to read my script from the beginning in order to run it? Is the script copied to a temporary file, or something?
As I think should now be clear — there's no problem here. There's no reason that two instances of Python can't both read the same script file at the same time. Linux allows that. (And in fact, if you delete the file, Linux will keep the file on disk until all programs that had it open have either closed it or exited.)
In fact, there's also no reason that two processes can't write to the same file at the same time, though here you have to be very careful to avoid the processes causing problems for each other or corrupting the file.
terminal is just running the command you said it to execute, there is no pointer or anything
you jus
I am trying to write my first vim script, so I apologize if this question boils down to not understanding the basics.
The main goal is that I want to call out to an external command from inside vim and read the results back into the file.
I know how to do this with simple shell commands, e.g. r !ls. However the command I want to interact with is "interactive".
I don't know if this is a meaningful description. But calling this command in the shell opens a TUI, then after interacting with the TUI the command will exit and put things into standard output. I want to read that standard output back into vim.
Possibly it will help to discuss the specific command, which is papis a cli citation manager. If you call, e.g. papis list --format '{doc[title]} {doc[author]}' in the shell it will open up a TUI that allows me to filter down and select a document. After selecting the document it will put the title and author into the standard output. This is what I want to read into vim.
However, my first few attempts have not been successful. Trying the naive :r !papis list results in an error, even though that command is valid in the shell and would result in the TUI being opened. So I'm obviously missing something.
Can anyone recommend a guide or suggest a possible solution for correctly calling out to TUI-based external commands and reading back their standard output?
as far as I know the only way to register aqlfunctions is via arangosh. JS functions very fastly get a few more lines of code which normally also have line breaks for better understanding. Whenever I paste them into the arangosh it gets corrupt as it excepts to get a "proper" end signal/sign. If I don't know it , the only way to reset it is a shotdown. My questions are:
Is there any shortcut like which resets the line input in such a case?
How can I write JS code into several lines and paste them into the arangosh directly?
Is there another way to register (more complex) JS functions I don't know?
Thanks for your help in advance.
<STRG> + D also works in windows.
Multiline doesn't work well with the CMD, it works partly with the cygwin shell window.
However, if the context shows that a function will start (using a brace) it will offer to add another line until the brace closes.
Probably the easiest way to get in more complex code is:
require("internal").load("c:\\tmp\\test.js")
which will be executed right away, so if you define functions in that, they will be usable in the shell context from then on.
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).
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/