I have this file with lldb commands in it that I want to run.
Is there a way to run pre-written lldb commands?
lldb's help system is a good way to answer this sort of question:
(lldb) help command
Commands for managing custom LLDB commands.
Syntax: command <subcommand> [<subcommand-options>]
The following subcommands are supported:
alias -- Define a custom command in terms of an existing command. Expects 'raw' input (see 'help raw-input'.)
delete -- Delete one or more custom commands defined by 'command regex'.
history -- Dump the history of commands in this session.
Commands in the history list can be run again using "!<INDEX>". "!-<OFFSET>" will re-run the command that is <OFFSET> commands from the end of the list (counting the current command).
regex -- Define a custom command in terms of existing commands by matching regular expressions.
script -- Commands for managing custom commands implemented by interpreter scripts.
source -- Read and execute LLDB commands from the file <filename>.
unalias -- Delete one or more custom commands defined by 'command alias'.
For more help on any particular subcommand, type 'help <command> <subcommand>'.
command source looks promising:
(lldb) help command source
Read and execute LLDB commands from the file <filename>.
Syntax: command source <cmd-options> <filename>
Command Options Usage:
command source [-e <boolean>] [-c <boolean>] [-s <boolean>] <filename>
-c <boolean> ( --stop-on-continue <boolean> )
If true, stop executing commands on continue.
-e <boolean> ( --stop-on-error <boolean> )
If true, stop executing commands on error.
-s <boolean> ( --silent-run <boolean> )
If true don't echo commands while executing.
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the command options and the beginning of the arguments.
There's also an apropos command that will search for keywords in the help. Unfortunately apropos command returns too many hits to be particularly helpful in your case. apropos file is a little less noisy, but just looking at the command subcommands is probably easiest. help with no arguments will list the top level commands which might also help you get started.
Note, you can also tell lldb to source a random file of commands when you launch it from the command line (with the -s option). To find out more about lldb's command line options, run:
> lldb --help
Related
I have a function (written below; source: TeX SX) that uses pipes in the shell which I'd like to use in vim command mode. It works as intended from the shell but returns an E34: No previous command error if entered in vim command mode. Full credit goes to jirislav in this post on TeX SX.
: | pdflatex -halt-on-error src.tex | grep '^!.*' -A200 --color=always
I'd very much like to have this shell functionality from the vim command line if anyone can help with that.
I tried the following from within vim command mode:
:! : | pdflatex -halt-on-error src.tex | grep '^!.*' -A200 --color=always
returns the E34 error. No pipes hides all compilation; however, it also doesn't output errors. Deleting 1 of 2 of the pipes also returns E34 errors for me.
I tried further troubleshooting to no success and here are some results of that. The help for :! says
a pipe '|' in {cmd} is passed to the shell, you cannot use it to append a vim command. See :bar
and :bar says (something that's referred to as escaping it out I think)
'|' can be used to separate commands, so you can give multiple commands in one line. If you want to use '|' in an argument, precede it with '\'.
I tried doing what :bar suggests, i.e.
:! : \| pdflatex -halt-on-error src.tex \| grep '^!.*' -A200 --color=always
The result is it hides everything, including compilation errors that I want to see. So I've come to the conclusion that I have no clue how to properly use shell pipes in vim command mode.
If you aren't a LaTeX user, all that the function is meant to do is the following. pdflatex compiles what's going on in vim into a pdf file. Enacting :! pdflatex % from vim's command mode outputs a whole slew of processing text and interrupts workflow; the grep in the function yanks out compilation errors, if they exist. The function, then, is meant to hide all output from pdflatex unless a compilation error occurs, in which case it outputs only the error and outputs it in red.
If anyone cared to explain the E34 error and why it doesn't work that would be appreciated, also.
Edit 1: This is now solved thanks to filbranden. Below there are a couple pictures attached of a minimal example should anyone come across this later.
vim file before input, output
Edit 2: Should you want to stick this in your .vimrc file, you'll need to escape out the pipe before grep, else the vimrc file defaults to thinking that pipe is a separator.
E34: No previous command
So the answer to your question was hiding in plain sight under :help E34, which redirects to the :! command.
(Vim pro-tip: whenever you get an error from Vim, ask for :help on the error code to get more context about it.)
The section on :! includes this passage:
Any ! in {cmd} is replaced with the previous external command. But not when there is a backslash before the '!', then that backslash is removed.
You did have a ! in your command, as part of the grep regular expression, ^!.*, so that was triggering the "history" behavior, trying to replace with the previously executed command. But since no command had executed at that point, the command failed with an error.
You can solve it by escaping the ! with a backslash, which Vim will remove before passing the command to the shell:
:! pdflatex -halt-on-error src.tex | grep '^\!.*' -A200 --color=always
But note that there are better ways to approach this problem! Let me cover some of them.
Using systemlist()
One great way to run external commands in Vim is to use the systemlist() function, which runs the command on a shell, captures its output, splits it into lines and returns a List with the resulting output lines.
So you could start with:
let latex_output = systemlist('pdflatex -halt-on-error src.tex')
And then use Vimscript commands to check for lines starting with ! to report to the user.
Note that, unlike with :!, the output of systemlist() is never displayed to the user (which means you don't switch back to seeing a terminal, possibly a blank one, and after the execution you don't have a "Hit enter prompt.) Which is great!
But that means you need to present that information to the user, when there are errors. A great way to do that is to use the quickfix window!
You can use the setqflist() function to set the contents of the quickfix window.
(For best results, you should set 'errorformat' appropriately, more on that later.)
Using vim-dispatch
If you don't like the part of running an external command (either through :! or systemlist()) that has it block Vim until the command execution is completed, then consider installing the vim-dispatch plug-in.
It can execute a command for you in background or in a separate terminal, so you're not blocked from editing. It also integrates with the :make command and the quickfix window.
Compiler configuration in vim-latex
Finally, the vim-latex plug-in (also known as latex-suite) has configurations to help you run pdflatex and report errors.
It includes a Vim :compiler configuration that will run pdflatex for you as a :make program. It also will set 'errorformat' to recognize the ! LaTeX Error string and recognize the line number of the errors, so you can jump to them directly from the quickfix list.
Note that vim-latex also has many other features to help you write LaTeX documents in Vim (besides managing the output generation through the compiler support.) You might want to check these other features as well.
(Since the plug-in has quite many features, I recommend reading the whole documentation to get you started on it.)
Also note that this plug-in is compatible with vim-dispatch (since vim-latex provides a compiler interface and vim-dispatch consumes it), so you can use both together if you like them both!
When I type some command, I sometimes want to read the help of the command. For example, when I'm typing
sort --overwrite some_texI # I is a cursor
, I'd like to check if sort command has --overwrite option, reading the output of sort --help or whatever option-summary I've made. I expect bind -x could realize this, but have no idea how to pass (a part of) the current command line information (in this case, the word "sort"). Of course, bind -x 'KEY: "sort --help"' works well, but I want this to work for all commands. So the pseudo command would be bind -x 'KEY: "CURRENT_COMMAND --help"'.
Could anyone please give a solution or a hint?
You can use READLINE_LINE variable of bash. man bash says
bind [-m keymap] keyseq:readline-command
(snip)
-x keyseq:shell-command
(snip) When shell-command is executed, the shell sets the READLINE_LINE variable to the contents of the readline line buffer
So what you want is the first word of READLINE_LINE. Thus, the solution is bind -x 'KEY": "array=($READLINE_LINE); ${array[0]} --help"'.
So say I have an external command, fart, that supports tab completion for its subcommands. When you type fart <\tab><\tab> in the command line, it prints out something like
$ > fart █
do some things here
or other stuff there
however, if you type fart <\enter>, it prints the help text
fart is a tool for doing things and stuff
Usage: fart <command>
Commands:
init Initialize a new something or other
status Report the status of the thing
version Show the fart version information
I want to test that the tab completion works via an integration test suite in Ruby. When I tell exec to execute fart \t\t, I get the help output, not the autocomplete output. How can I get exec to not terminate the shell command with a newline so that I can assert the autocompletion output?
You shouldn't fa^M^M exec the thing. It doesn't work like this. You need to interact with a PTY. Basically spawn a shell in a PTY, then send keys like you would do interactively.
Alternatively you could write expect scripts and use the expect utility found in most linux distros.
Auto-completion is a shell function, not a program function. When you hit tab, bash or some other shell is looking for completion definitions and uses them to show you the available options. It is not executing the program in any way.
I am writing a Bash script that runs a command-line program (Gromacs), saves the results, modifies the input files, and then loops through the process again.
I am trying to use Vim to modify the input text files, but I have not been able to find a way to execute internal Vim commands like :1234, w, x, dd, etc. from the .sh file after opening my input files in Vim ("vim conf.gro").
Is there a practical way to execute Vim commands from the shell script?
I think vim -w/W and vim -s is what you are looking for.
The "Vim operations/key sequence" you could also record with vim -w test.keys input.file. You could write the test.keys too. For example, save this in the file:
ggwxjddZZ
This will do:
Move to the first line,
move to the next word,
delete one character,
move to the next line,
delete the line, and
save and quit.
With this test.keys file, you could do:
vim -s test.keys myInput.file
Your "myInput.file" would be processed by the above operations, and saved. You could have that line in your shell script.
VimGolf is using the same way to save the user's solution.
You can script Vim via the -c flag.
vim -c "set ff=dos" -c wq mine.mak
However that only gets you so far.
From the commands you gave it looks like you are trying to run some normal commands. You will need to use :normal. e.g. :norm dd
Writing all this on the command line is asking for trouble. I suggest you make a Vim file (e.g. commands.vim) and then :source via -S.
You probably want to get good and conformable Vim's ex commands. Take a look at :h ex-cmd-index
So you will end up with something like this. With all your Vim commands inside of commands.vim.
vim -S commands.vim mine.mak
You may also want to look into using sed and/or awk for text processing.
Alternatives
Unless you really need special Vim capabilities, you're probably better off using non-interactive tools like sed, awk, or Perl / Python / Ruby / your favorite scripting language here.
That said, you can use Vim non-interactively:
Silent Batch Mode
For very simple text processing (i.e. using Vim like an enhanced 'sed' or 'awk', maybe just benefitting from the enhanced regular expressions in a :substitute command), use Ex-mode.
REM Windows
call vim -N -u NONE -n -es -S "commands.ex" "filespec"
Note: silent batch mode (:help -s-ex) messes up the Windows console, so you may have to do a cls to clean up after the Vim run.
# Unix
vim -T dumb --noplugin -n -es -S "commands.ex" "filespec"
Attention: Vim will hang waiting for input if the "commands.ex" file doesn't exist; better check beforehand for its existence! Alternatively, Vim can read the commands from stdin. You can also fill a new buffer with text read from stdin, and read commands from stderr if you use the - argument.
Full Automation
For more advanced processing involving multiple windows, and real automation of Vim (where you might interact with the user or leave Vim running to let the user take over), use:
vim -N -u NONE -n -c "set nomore" -S "commands.vim" "filespec"
Here's a summary of the used arguments:
-T dumb Avoids errors in case the terminal detection goes wrong.
-N -u NONE Do not load vimrc and plugins, alternatively:
--noplugin Do not load plugins.
-n No swapfile.
-es Ex mode + silent batch mode -s-ex
Attention: Must be given in that order!
-S ... Source script.
-c 'set nomore' Suppress the more-prompt when the screen is filled
with messages or output to avoid blocking.
I want to type something like 'scheme file.scm' and have it interpret the file, and then take me back to my shell, rather than loading it in the REPL.
edit: I tried scheme < test.scm and it still uses the REPL, the only difference is that scheme exits when the stream ends.
scheme < file.scm should work (as long as you don't specify --interactive and stdin is not a terminal, scheme works non-interactively).
To run a scheme program using MIT Scheme:
scheme --quiet < program.scm
The --quiet option ensures that the output from your program is the only thing that is displayed (i.e. you won't see the REPL, as per your requirements).
Caveat: This will not work if your program prompts the user for input using the input procedures (e.g. read, read-char, read-line, etc.). This is because of the shell input redirection (<) (See: relevant question). Unfortunately, there is currently no proper way of executing an MIT Scheme script from the command line when input procedures are used. The best option is probably mit-scheme --quiet --load 'myscript', but you'd have to manually exit MIT Scheme when the script finishes. Relevant mailing list thread: [MIT-Scheme-devel] How to run a script and exit?
EDIT: Due to the possibility that you may mistype < as >, resulting in the overwrite of your source code, I would suggest encapsulating the above command within a shell script or a shell function. For example:
runscheme () {
scheme --quiet < "$1"
}
Then you can run runscheme program.scm without fear that your source code will be overwritten. (Special thanks to Paul Rooney for bringing this potential mistake to my attention).
References
scheme --help:
--batch-mode, --quiet, --silent
Suppresses the startup report of versions and copyrights, and the
valediction.
This command line option seems to have been mistakenly ommitted from the list of command line options in the documentation, but I think this is a legimate command line option because scheme --help shows it, and because --batch-mode is used in other parts of the reference manual (e.g. here).
I think what you want is SCM. You can execute a .scm script like this:
$ scm -f foo.scm arg1 arg2 arg3
See http://people.csail.mit.edu/jaffer/scm_3.html#SEC28 for more details.
The SCM homepage: http://people.csail.mit.edu/jaffer/SCM
checked chez --help, and then I found this(let's say that I'm using chez scheme):
chez --script ./temp.scm
Also, --verbose is very useful:
chez --verbose --script ./temp.scm