In .lldbinit in macOS 10.13.3 I define an alias:
command alias pl process launch --stop-at-entry --
so that inside lldb run from the command line I can say something like:
pl ~/path-to-filename
However, when I examine argv I see that lldb has not performed path expansion on the ~.
Of course, the session fails, lldb can't find the file, but if at the bottom I rerun the session with r, the ~ resolves to the absolute path.
The alias is not the issue because if I run process launch inside lldb
with:
process launch --stop-at-entry -- ~/path-to-filename
lldb still refuses to resolve ~. And, it seems bizaare to me, lldb does the expected right thing, resolve ~, when doing r to rerun the debug session. Is this a bash issue, a bug in lldb, a feature or pilot error? I don't know whether this behavior also occurs in the Xcode gui, because I don't use it. It makes me wan't to barf.
(lldb) help pro lau
Launch the executable in the debugger.
[...]
-X <boolean> ( --shell-expand-args <boolean> )
Set whether to shell expand arguments to the process when launching.
(lldb) help r
'r' is an abbreviation for 'process launch -X true --'
Related
If I debug a command line app from Xcode, I get a different $PATH than if I run the same app from a terminal session.
For example, when run from a Terminal:
$env | grep "PATH="
//output: PATH=/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
...
From an Xcode debug session:
let environment = ProcessInfo.processInfo.environment
print(environment["PATH"] ?? "No PATH found")
//output: /Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
As a result, some command line apps are unavailable while debugging.
How do I get the terminal window $PATH environment variable within an Xcode debugging session?
As Martin R said in his comment, the environment passed to GUI programs is different than that used by shell applications.
I never found a simple solution to the problem. I suspect that the environment paths are set either with launchctl or a default is provided to GUI apps.
Finally, I ended up changing the environment used by class Process (Swift). Though not perfect (and certainly more complicated than I'd hoped), it works. You can find the entire implementation I used at: GitHub
So I'm getting some pretty strange behaviour when I try to use an Automator service to open new emacs (GNU Version 25.2 with spacemacs) buffers.
In my terminal, the command emacsclient -a '' -c works as expected, opening a new buffer through emacsclient. However, when I make a service in Automator which simply runs a (/bin/bash) shell script:
emacsclient -a '' -c
I get an error message:
The action “Run Shell Script” encountered an error: “emacsclient: could not get terminal name”
On suspicions that this was due to Automator not using some default PATH variable, I tried the following instead:
PATH=/usr/local/bin:$PATH
emacsclient -c
which produced the same error as before.
Next I tried
PATH=/usr/bin:/usr/local/bin export PATH;
emacsclient -c
which produced a different error message:
The action “Run Shell Script” encountered an error: “emacsclient: invalid option -- c
Try `emacsclient --help' for more information”
however why I try that script in my terminal it also gives a similar error which doesn't make much sense to me.
If anyone has suggestions for how to fix this I'd really appreciate it.
The problem is the shell script is running an old version of emacsclient in /usr/bin you need to run the one in Emacs.app/Contents/MacOS/bin/emacsclient. Delete the PATH line and you can use a solution listed here for running emacsclient inside automator Running a macOS service for open with emacs failed with "emacsclient: could not get terminal name mac"
Say my debugger stops at a breakpoint. Is there any way to run/send arbitrary Perl code to the debugger?
For example, say I stop the debugger at a location with the statement:
$DB::single = 1
I would like to be able to:
Type and execute general Perl statements from the debugger prompt
Run scripts
Anything you type in the debugger that isn't recognized as a debugger command is interpreted as perl and run. You can run a file using require or do, although I'm not sure what you have in mind when you say "interactively" run code from another file.
I'm debugging a perl script with a lot of command-line arguments.
Is it possible to restart the execution of the script (using the R command of perl debugger) using a different set of arguments?
Since I've got a lot of breakpoints and watches defined I don't want to exit the debugger and restart it with the new args...
You could set a breakpoint at the start, restart it with R, and define the #ARGV you want in the debugger.
First time perl user and I am trying to debug some script to follow project logic and of course syntax.
Using cygwin after entering at command line $
$ perl -d sample.pl
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(sample.pl:5): print 'Hello world.'; # Print a message
DB<1>
It hangs at the DB<1> line. I cannot enter anything at the prompt.
Is there a reason why this post is inappropriate? or how is this not clear?
This is the actual program code:
#!/usr/local/bin/perl
#
# Program to do the obvious
#
print 'Hello world.'; # Print a message
I upgraded my cygwin installation at home and ran into a similar problem (though maybe not the exact same problem -- the perl debugger still responds to my input but does not display my input, and fubars my input even after I quit the debugger). In the meantime while I figure what is going on, my workaround is to fire up xemacs, launch a shell (M-x shell), and run the perl debugger from the emacs buffer.
If this works for you, then there is something funky going on with your cygwin terminal settings. If your debugger hangs even in an emacs buffer, then something else funky is going on but I have no idea what it could be.
Sorry for reviving this three-year-old question, but I believe to have been hit with the same problem, and to have found the solution.
In my case, perl -de0 invokes infocmp from ncurses, which hangs in a weird way (can't kill it). And infocmp seemed to be a victim of my Avast anti-virus which is listed under BLODA as affecting Cygwin. Disabling it resolved the issue -- see if you have any of the listed applications and try disabling it (perhaps also try safe mode).
Also, simply renaming infocmp.exe allowed perl -d to run normally. In the end I used this approach and left my Avast running.
It could also be a different executable that perl -d is starting -- try to run whatever hangs with strace, see what is the last executable mentioned and try to see if that is the culprit.