I would like to load my breakpoint commands from a file at startup using the '-s' flag to lldb, but it does not appear to accept the usual multiline input syntax of 'br command add' (a series of commands followed by 'DONE'). Is there a way to set a multiline breakpoint command from a script file?
I have a script file 'lldb.txt' with the following:
br set -n ptrace
br command add 1
register write pc `$pc + 42`
cont
DONE
And I'm running lldb as
lldb -s lldb.txt MyApp
The part from 'register' to 'DONE' does not work as it would from the lldb command prompt.
I'm running lldb on MacOS.
That's a bug in lldb. It will be fixed in the next lldb release.
Related
Is there a way to launch Emacs from terminal and execute some Emacs command automatically soon after Emacs is launched (the command to be executed inside of emacs is provided along with the Emacs-launching command executed from the shell.)
What I want to do exactly is to have a command to launch Emacs and then open a new empty buffer and activate org mode inside of this buffer.
I want something that might look like this
emacs -fs --command="evil-buffer-new && org-mode"
I want the -fs flag because I want Emacs to open in full-screen in this case.
Update
--eval flag didn't work. Forget about evil-buffer-new, I have tried something as simple as:
emacs --eval="(org-mode)" txt.txt
txt.txt is an empty text file created before executing the above command (and please don't ask me why I didn't use .org file extension).
after Emacs opened, org-mode wasn't active. I had to run pp-eval-expression then (org-mode) to activate it, and then it worked.
Am I missing something here? How about rephrasing the question like this:
How to open an empty text file (having .txt file extension) with Emacs from the terminal and have org-mode activated in that buffer automatically?
See C-hig (emacs)Action Arguments or even just run emacs --help -- there are several options for loading and evaluating arbitrary code.
--command="evil-buffer-new && org-mode"
More like:
--eval="(progn (evil-buffer-new) (org-mode))"
But you'll have to figure it out for yourself, because I don't know what evil-buffer-new is specifically.
You told an empty file is created before emacs is started. But instead of an empty file could you create a file with file-local mode variable specifying the org mode ? For example with bash:
#!/bin/bash
cat <<EOF >> "$1"
; -*- mode: Org;-*-
EOF
emacs "$1" &
Now the mode is always resolved correctly with normal major mode selection procedure.
On Windows, if I start c:\msys64\mingw64.exe, it opens a shell, where I can build my project, let's say by calling a release bash script (to simplify). Everything works fine.
Now, I would like to execute my release script on mingw64 directly, without interaction.
I tried:
c:\msys64\mingw64.exe /c/the/full/path/release
A window opens and closes, it does not work.
I attempted to use bash directly, but it seems the environment is not correctly set:
> c:\msys64\usr\bin\bash -c ls
/usr/bin/bash: ls: command not found
> c:\msys64\usr\bin\bash -c /bin/ls
... it works ...
So it is obvious that the environment is not the same as when execute c:\msys64\mingw64.exe then call ls.
How to execute my release script as if I were in the shell started by mingw64.exe?
To run a Bash shell script in MSYS2 without showing a window, you should right-click on your Desktop or somewhere else in Windows Explorer, select "New", select "Shortcut", and then enter something like this for the shortcut target:
C:\msys64\usr\bin\mintty.exe -w hide /bin/env MSYSTEM=MINGW64 /bin/bash -l /c/Users/rom1v/project/release.sh
Note that there are 4 paths in here. The path to mintty and release.sh are absolute paths that you will need to adjust. The paths to env and bash are relative to your MSYS2 installation directory. Note also that the first path must be a standard Windows path, since Windows expects that when it is running a shortcut.
Explanation
It might seem odd to use MinTTY for a non-interactive script, but we need to use some program that was compiled for the Windows subsystem (-mwindows option to GCC), or else Windows will automatically start a new console when we run the program. We pass the -w hide option to MinTTY to tell it not to actually show a window. Everything after that option is interpreted by MinTTY as a command to run.
So MinTTY will run /bin/env from the MSYS2 distribution and pass the remainder of the arguments on to it. This is a handy utility that is actually a standard part of Linux as well as MSYS2. It sets the MSYSTEM environment variable to MINGW64 (which is important later) and then it runs /bin/bash with the remainder of the command-line arguments.
We pass -l to Bash so that it acts as a login script, and runs certain startup scripts. In particular, the /etc/profile script from MSYS2 is essential because it looks at the MSYSTEM environment variable, sees that it is MINGW64, and then sets a bunch of other environment variables (e.g. PATH) to give you the MinGW 64-bit shell environment.
Finally, we pass the name of your script as the main argument to bash, so it will run that script after running the initialization scripts.
Error handling
Note that if your Bash script has an error, you won't get any notification, because the shortcut above doesn't open any console windows. I personally would find that pretty annoying. I'd probably remove the -w hide option, then make a wrapper bash script that just does something like:
run_my_main_script || sleep 10000
So if the main script is successful, exit right away, otherwise keep the window open for 10000 seconds. You don't have to even put that wrapper script in its own file, you can just put it in the shortcut as the argument to Bash's -c option (don't forget to wrap it in double quotes).
Thanks to the answers from #David Grayson, I managed to call my release script with msys2/mingw from a Windows console (cmd), with additional directories (for Java and Meson) in $PATH:
c:\msys64\usr\bin\env MSYSTEM=MINGW64 c:\msys64\usr\bin\bash -l -c "PATH=\"/c/Program Files/Java/jdk1.8.X_XXX/bin:/c/Program Files/Meson:$PATH\" /c/Users/rom1v/project/release"
add an supplement to the above: if u want to the output of shell script
reference：https://mintty.github.io/mintty.1.html
-l, --log FILE|-
Copy all output into the specified log file, or standard output if a dash is given instead of a file name. (Implies -o Logging=yes.)
If FILE contains %d it will be substituted with the process ID. See description of equivalent option "Log file" (Log=) below for further formatting options and hints.
Note that logging can be toggled from the extended context menu.
Add A complete example:
C:\msys64\usr\bin\mintty.exe -w hide -l - c:\msys64\usr\bin\env MSYSTEM=MINGW64 c:\msys64\usr\bin\bash -l -c "PATH=\"$PATH\" /C/Users/Administrator/Desktop/myProject/Demo_C_C++/shell/textProcess/bookNoteHandler.sh" | find /v "/v:Displays all lines that don't contain the specified"
=========
I'm using LLDB with the latest OS X toolchain (lldb --version says lldb-340.4.110).
I tried to debug executable which produces lots of output into stdout.
Previously it was possible to suppress output by redirecting it, e.g. to /dev/null.
But after latest OS X toolchain update it has started producing the following error:
(lldb) run >/dev/null
error: invalid JSON
Has something changed in LLDB in that area? Like adding some syntax for specifying stdin/stdout/stderr redirects. Can't find any clue in LLDB docs or mailing lists. Also I can suppose it is Apple-specific LLDB bug.
P.S.
I know that my problem can be temporary solved by running:
sudo lldb -w -n <executable> in separate terminal window, which will tell LLDB to wait for new process with the given name and then attach to that process. In that case I can run my executable in another terminal window with stdin redirected to /dev/null.
But I feel highly uncomfortable with that workflow, because stdout redirect just works in GDB on my Linux machine. Breaking the habits is always uncomfortable.
(lldb) process launch -o /dev/null -- <OTHER ARGUMENTS>
will do what you want. You can also make an alias to do this:
(lldb) command alias silent-run process launch -o /dev/null --
then:
(lldb) silent-run a b c
will run your program, redirect stdout to /dev/null, and pass a, b and c as arguments.
When I run a program as usually everything is fine, but when I run it via keybinding (bind -x '"\C-]":qr') terminal is messed up?
Thats the program: https://github.com/naquad/QuickRun
How to fix that? Is that a program fault? Or bind?
It figures out that bind -x is not indented to run interactive programs or programs that use TUI (curses and similar). To run such program one should use a macro:
bash '"\C-]":"\C-u\C-kyour command\C-j"'
this is for emacs mode. Key by key:
\C-] - keysequence to bind
\C-u\C-k - clear line (first one - delete until cursor, second one - delete after cursor)
command
\C-j - accept line aka enter
I like emacs's gdb mode a lot better than GDB's command line or TUI modes, but there are some programs that want a "debugger command line" program that it can take and run in an environment it sets up.
I'm wondering if there's a simple way to make emacs pop up in gdb mode using a command line substitute for gdb.
Thanks in advance.
Put this in your .bashrc:
gdbtool () { emacs --eval "(gdb \"gdb
--annotate=3 $*\")";}
Then you can run "gdbtool programToDebug"
Source: http://www.inet.net.nz/~nickrob/