I want to set up an Automator Quick Action that runs the bbdiff command, and passes it the selected files in the Finder.
I created a Quick Action, and set it to receive "files or folders" in "Finder.app".
Then I added the "Run Shell Script" action, and set the shell to "/bin/bash", and to Pass Input "as arguments". The script is:
/usr/local/bin/bbdiff "$1" "$2"
If I run that script manually from Automator or Terminal (replacing the arguments with real filenames) it prompts me to authorize the host program to control BBEdit, and then it works.
But if I run it from the Finder, I get this error:
The action “Run Shell Script” encountered an error: “You must allow bbdiff to send events to the BBEdit application.
Use tccutil reset AppleEvents to reset the system's permissions, and try again.
bbdiff: error: -1743”
I tried running tccutil reset AppleEvents and running the action again, but it showed the same error.
I also tried adding bbdiff, /bin/bash, and Finder to the Accessibility and Full Disk Access tabs of System Preferences > Privacy, but nothing changed. It looks like you need to add something to the Automation tab, which can't be done manually.
How can I get it to allow a UNIX command like bbdiff to control an application?
UPDATE:
I managed to work around this by using a "Run AppleScript" action, instead of "Run Shell Script", with this script:
on run {input, parameters}
tell application "BBEdit" to compare (item 1 of input) against (item 2 of input)
return input
end run
The first time I ran it, I got the prompt to allow Finder to control BBEdit, and then it worked.
But this wouldn't work for other shell scripts, so the question is still open.
In my case, I was able to fix it simply by closing the currently opened BBEdit then opening it again. In my case, I was doing a BBEdit update before the error appears.
Related
how to configure better errors for ROR on linux with firefox. Better errors gem is useful to open rails application error file with line number from browser only, so it will be less time consuming for developer to correct the error and no need to search file and line separately
First of all download and install sublime url handler patch to handle the url with line number. Download sublime-url-handler.
Goto to development.rb file and add BetterErrors.editor = :sublime
Goto firefox and type about:config in url and hit enter
Right click and create new property with boolean type with name " network.protocol-handler.expose.subl" set "False".
Restart firefox.
Run your rails app and get the error link page, click on error link it will ask open open with if sublime-url-hanlder is shown here well done choose and cheers if not shown than give your sublime executable path here and done.
Remember give sublime executable path only not /usr/bin/subl, or shared lib path. You can find the executable path by running subl and see the process details like "ps -eaf | grep subl" copy the path and give this path in firefox choose application.
I am creating a batch file that needs to open a second batch script in a separate cmd window. I can use all my code successfully if I use the "call" command instead of "start" but that doesn't launch the script in its own window. I have gotten this error many times in the past and its always related to the start command. I change how I do the process and all works well. Why is the start command causing this error and how can I fix it? Below is a sample of my code.
start "" /w "k:\Bundle Support files\record serial.cmd"
The second batch file opens and completes all tasks except the last one which is
goto :exit
:exit
I have changed the last command in the file several times and it always makes it through the entire batch but the last command that would finish that batch fails with the "not enough storage is available to process this command" error. This happens on multiple machines (varying hardware) and multiple OS's. I have attempted the IRPStackSize fix with no luck. Any suggestions as to why I am getting this error?
Thanks,
Kevin
I have encountered a similar problem and the solution for me was rather strange. It appears that setting the title of the window to nothing ("") causes the error.
So, instead of
start "" /w "k:\Bundle Support files\record serial.cmd"
try
start "Placeholder Name" /w "k:\Bundle Support files\record serial.cmd"
I can't test whether this will work in your case (and I doubt it matters as you're long gone) but hopefully this will help someone experiencing any similar errors.
Replace goto :exit with goto :EOF. Do not define the EOF label (it is predefined).
That's what the START command does when you launch a cmd. If you ran START cmd you wouldn't expect CMD to exit immediately - it stays there ready for use. So you either CALL a cmd file and it will finish, or you START a cmd, and it will not finish - but you can make it finish by using the EXIT command. The issue of the stack overflow was also answered correctly by SEIPIA - instead of using start "" filename.cmd, put something between the quotes to act as the title - that will prevent the stack overflow error.
I'm very new to IDL (trying to do a POC for someone using it) and I am trying to run an external command. The line of code I have added is this:
spawn, 'C:\Program Files\ITT\IDL\IDL80\products\envi48\save_add\visual.exe'
I thought this was all that was needed to launch an external command. When I run the app, i can use the debugger to step through the code, and when I get to this line and Step over, my executable does not run. I see no messages in the debugger indicating any type of error.
I put the file visual.exe in the directory and can run it by hand with no issues. It just seems to step right over the code without executing it or reporting any error.
You can use the form:
spawn, cmd, result, errResult
to get the any error messages that might be generated from the cmd. In your particular case, I think you need to quote the path to the executable because of the space in the path.
Your usage of the spawn command is correct. Perhaps visual.exe is exiting prematurely
for some reason (for example, maybe the working directory when run via spawn isn't what
your external program is expecting.)
You might try writing a little script that starts visual.exe, then does a pause,
and then spawn the wrapper script instead of visual.exe directly. That might
give you a chance to see any error messages before the DOS window disappears.
I've got a console application that crashes with an I/O error 6 when the output is redirected to a file. It probably has something to do with the fact that the console application changes the text color, which doesn't make much sense in a file.
This works: c:\dir\app.exe
This crashes: c:\dir\app.exe >out.txt
When I supply >out.txt as a parameter in the IDE (run\parameters\parameters\), I just get >out.txt as a parameter.
How can I debug the application with the stdout redirected to a file instead of the console?
Redirection is made by the command line interpreter, in windows it is cmd.exe
To debug the application, just launch a cmd.exe with propers arguments to launch your application and redirect the output, for example:
cmd.exe /c "yourapplication.exe >redirect.txt"
To make this happen from inside IDE in order to debug, configure cmd.exe as the host application (Run/Parameters):
Put a breakpoint where you want to stop, and launch a new cmd.exe (Project/Load process) with "Run to first source" after load action:
And you're done... the debugger must stop the application at your breakpoint.
You could try remote debugging:
at the beginning of the application, add a ReadLn; which gives you time to attach to the process from within Delphi
start the application from a command line (specifying the >out.txt parameter)
in Delphi, connect with the app process (Run | Attach to Process...), set a breakpoint and then switch to the application to enter a key
Hint: a debugger breakpoint can also be set in code:
asm
int 3
end;
Make sure it isn't failing due to directory permissions. Fully-qualify the output file path to somewhere that you're guaranteed to be able to write. Otherwise, Windows7 may be playing games with the directory. (VirtualStore stuff).
I get the following when I start my Zsh.
Usage: prompt <options>
Options:
-c Show currently selected theme and parameters
-l List currently available prompt themes
-p [<themes>] Preview given themes (defaults to all)
-h [<theme>] Display help (for given theme)
-s <theme> Set and save theme
<theme> Switch to new theme immediately (changes not saved)
It seems to be set by some theme file, since the same text is here.
How can you disable the notification in Zsh?
This isn't a startup message. It's the error/default help message displayed when the prompt command is used without arguments or erroneous arguments. Find out where you're using it, and fix/delete it.
You'll want to search through the files that zsh loads on startup, here is a list from their documentation
Look for a misconfigured prompt command line and try commenting it out or better fixing it.