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?
Related
I want to run following Linux command which opens the document with application registered with the system:
xdg-open mydocument.pdf
I see that many commands for this are available: run, run*, capture, shell, execute, system* etc.
from: http://wiki.call-cc.org/eggref/4/shell and https://wiki.call-cc.org/man/4/Unit%20utils
I also need the result of the command (ran successfully or not) from this.
Following (system without *), although not listed, also seem to work well:
(define result (system "xdg-open mydocument.pdf"))
Which of these will be the safest way to run system commands as above?
If the name of the document is hardcoded, it doesn't matter much what you use. If the file name is user-supplied, you must use qs to quote the arguments if you're relying on a string-based API like system's. It might be easier to pass arguments separately using process.
I don't know the shell egg very well, but if you want to get really fancy with shell calls, the scsh-process egg is a very nice alternative (full disclosure: I'm its author).
I am writing a program that handles some data on a server. Throughout the program, many files are made and sent as input into other programs. To do this, I usually make the command string, then run it like so:
cmd = "prog input_file1 input_file2 > outputfile"
os.system(cmd)
When I run the command, however, the programs being called report that they cannot open the files. If I run the python code on my local computer, it is fine. When I loaded it onto the server, it started to fail. I think this is related to issues with permissions, but am not sure how I can fix this. Many of the files, particularly the output files, are being created at run time. The input files have full permissions for all users. Any help or advice would be appreciated!
Cheers!
The python code you list is simple and correct, so the problem is likely not in the two lines of your example. Here are some related areas for you to check out.
Permissions
The user running the python script must have the appropriate permission (read, write, execute). I see from comments that you've already checked this.
What command are you running
If the command is literally typed into your source code like in the example, then you know what command is being run, but if you are generating any part of it (eg. the list of operands, the name of the output file, other parameters, etc), make sure there are no bugs in the portions of your code that generate the command. For example before the call to os.system(cmd) consider including a line like print("About to execute: " + cmd) so you can see exactly what will be run.
Directly invoke the command
If all the above looks good, try to execute the command directly at a terminal on your server. What output do you get then. It's possible that the problem is with the underlying command itself rather than your python code.
I want to save all the commands that are fired in the terminal. Using history and appending it to a file using cron job method is not suitable for my case.
If anyone types a ls -lrt in the terminal and as soon as he presses the Enter, I want to store it in a file. Any logical explanation would do, I would write the code myself.
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/
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.