When opening an appImage with double click, is there some way to automatically add command line arguments?
Why: on a fresh UBUNTU MATE 22.04 installation, I'm having problems with some appImages: most of them successfully open, others open and close immediately;
I'm experiencing this in particular with
mendeley-reference-manager-2.77.0-x86_64.AppImage
If launched by double click, it opens and close.
If launched from command line I get this error:
[21690:0908/111927.721030:FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye.
I found here a working solution, which successfully opens the appImage, namely launch the appImage with the following arguments:
./mendeley-reference-manager-2.77.0-x86_64.AppImage --disable-gpu-sandbox
Then, I was wondering if I can make the double-click launch the appImage with these arguments.
Thanks,
Valerio
I'm using AppImageLauncher for desktop integration. When first opening an AppImage file it creates a .desktop file with the execution command in ~/.local/share/applications. You can manually add the desired command line arguments there:
Exec=sh -c "/home/user/Applications/mendeley-reference-manager-2.80.1-x86_64.AppImage --disable-gpu-sandbox"
Reference
What is the windows equivalent to "./filename"
So for example I would usually compile by doing something like:
gcc -c homework1.c
gcc -o homework1 homework1.o
This would give me the executable names homework1
And for me to run the program, I would type: ( ./homework1 ) <-- ignore the parenthesis.
Usually I was write all my code in my schools Unix Shell thingy and I also compile it and run it there, but recently I think I took up all the disc space (because it says "disc quota exceeded").
Run cmd.exe
Go to where the program is example : cd C:\foder1\
Then type the program name with extension, for example : test1.exe or "test1.exe"
In windows (as in Linux) you can either run a program though a GUI interface or from a shell environment.
The GUI option is a program called Explorer, you navigate through the file system and double click executable files to run then. Executable typically have the extension '.exe' or '.bat', but there are others.
The shell environment in windows is called the 'command prompt', you can run it by going to the start menu and selecting 'run' or simply press the windows key and 'r' simultaneously. A box will popup, type 'cmd' (without the quotes) and hit enter - the command prompt should open. From there you can navigate the file system using commands like 'cd'. To run your executable type the name of the file (it should work with or without the '.exe').
A nice shortcut to open the command prompt already at a particular path, is to browse to the folder in Explorer, hold shift and then right-click the folder - the resulting context menu that pops up should have an option like 'open in command prompt'.
I built a Lazarus GUI application using Ubuntu and then took it onto Windows to compile. On Ubuntu I run it from the terminal like this:
./prg arg
It runs fine using the argument arg passed to it. On Windows this is what I did:
Create shortcut to exe
Edit shortcut and include the argument.
To run on Windows, I run the shortcut.
It works fine but there's an additional terminal window opening behind the application, when I run the shortcut. When the application exits, the window closes with it. The terminal window is empty.
On Windows, before compiling I had to uncheck the -WG switch in compiler options. This was because althought the app is GUI-based, there is a simple routine that checks for the argument passed at command line and uses Writeln to output a message if there were errors.
My key question is why is this terminal window coming up on Windows and how do I get rid of it or suppress it?
Thanks!
(1) Make sure you have set {$APPTYPE GUI} in your code. Otherwise there will be always a "terminal" opened on windows.
(2) Maybe you are confusing a "real" shortcut (*.lnk) with cmd/batch file? The latter also opens a terminal that dies when the lauched app closes.
Here are my files:
launcher.applescript
tell application ":path:to:applescript:apps:shell-script-launcher.app" to launch
shell-script-launcher.app [AppleScript, saved as Application]
do shell script "say starting script"
Desired behavior:
Run "launcher.applescript" from AppleScript Editor
Listen for "starting script"
Actual behavior:
Running the "shell-script-launcher.app" by opening it manually in the finder yields expected behavior
Running the "launcher.applescript" opens the "shell-script-launcher.app" but it never executes the shell script.
I've tried saving the app as "Run Only" as well as "Stay Open". Still no progress. What do you recommend. The final result must be an Application instead of an Applescript.
Conceptually:
the run command launches and runs an application hidden
the activate command launches, runs, and activates the application (makes it the frontmost application)
launch, according to Apple, "Launches an application, if it is not already running, but does not send it a run command."
for AppleScript-based applications this should mean that they're loaded, but not executed (i.e., their - implicit or explicit - on run handler is NOT invoked), but in practice that is not true up to 10.9 - see below.
it is unclear (to me) what exactly that means for non-AppleScript-based applications
Here's how Apple thinks it works with AppleScript-based applications, which is only true starting with OSX 10.10 (Yosemite):
A script can send commands to a script application just as it can to other applications. To launch a non-stay-open application and run its script, use a launch command followed by a run command, like this:
launch application "NonStayOpen"
run application "NonStayOpen"
The launch command launches the script application without sending it an implicit run command. When the run command is sent to the script application, it processes the command, sends back a reply if necessary, and quits.
Broken behavior on OSX 10.8, 10.9 (fixed in OSX 10.10):
launch by itself is enough to run the application and is indeed the only command that works with AppleScript-based applications.
Any attempt to execute run or activate (whether in addition to launch or not) runs the application - even twice when run from AppleScript editor(!; just once with osascript) - but reports failure <appName> got an error: Connection is invalid.
This strikes me as bug.
Not sure how OSX versions <= 10.7 behave.
Note: I've witnessed the non-executing behavior with launch once, but every non-stay-open AppleScript-based test app I've created from scratch on OS X 10.9.2 and OS X 10.8.5 also executes the script with launch - contradicting what the documentation says.
Please let me know if your system behaves differently and/or how older versions behave. On what OSX version was the app that doesn't execute with launch created?
On OSX 10.10, behavior is consistent with the documentation, with one thing worth noting:
If the intent is to launch and run in one step, run application is sufficient - no need for a separate launch application command first.
Options
#user309603's pragmatic solution simply uses do shell script with the standard open utility to bypass the problem - this should work, regardless of whether the application is AppleScript-based or not:
do shell script "open " & ¬
quoted form of POSIX path of ¬
alias ":path:to:applescript:apps:shell-script-launcher.app"
If you know the type of application you're invoking up front:
to run an AppleScript-based app: best to use run script file, as #regulus6633 recommends - this has the added advantage that the invoked AppleScript-based application can return objects directly to the caller:
run script file ":path:to:applescript:apps:shell-script-launcher.app"
Note: There's also load script file, which indeed lets you merely load script code without executing it right away.
to run non-AppleScript apps: use run / activate to run the app hidden / frontmost:
run application ":path:to:applescript:apps:shell-script-launcher.app"
You could use run even with AppleScript-based applications and simply ignore errors with try ... end try, as #atonus suggests - the downside is that you won't be able to detect actual failure to invoke the application.
You can mitigate this by selectively ignoring only the specific Connection invalid error (which assumes this error would not legitimately occur) [no longer needed on OSX 10.10]:
try
run application "Macintosh HD:Applications:_Sandbox-AppleScript0.app"
on error number -609 # 'Connection is invalid' error that is spuriously reported
# simply ignore
end try
Finally, on OSX <= 10.9, you could try to simply use the launch command (though that didn't work for the OP, possibly due to working on a <= 10.7 OSX version):
launch application ":path:to:applescript:apps:shell-script-launcher.app"
However, that is not advisable for two reasons:
In OSX 10.10, Apple has fixed the launch behavior to no longer execute also, so your code will break when run there.
While non-AppleScript apps typically do run (hidden) when invoked with launch, the documentation says that AppleScript "does not send it a run command" and "allows you to open an application without performing its usual startup procedures, such as opening a new window" - what that exactly means is not clear and different applications seem to handle this differently.
Applescript has the "run script" command. It works on applescripts or applescript applications. So if I have your app on my desktop then this works...
set appPath to (path to desktop as text) & "shell-script-launcher.app"
run script file appPath
Have you tried open?
do shell script "open 'path/to/applescript/apps/shell-script-launcher.app' && say starting script"
Put it between "try" keywords.
try
tell application ":path:to:applescript:apps:shell-script-launcher.app" to activate
end try
Save your script as an application.
Add the desired script into the Script folder (see path below)
Run as follows, change per type of script you want to run...
property theApplicationPath : the path to me as text <br/>
property theShellScriptPath : theApplicationPath & "Contents:Resources:Scripts:test.command"<br/>
property theShellScript : the quoted form of POSIX path of theShellScriptPath<br/>
<br/>
tell application "Terminal" to (do shell script "/bin/bash " & theShellScript)
<br/>
Boom, Bob's your uncle! At least for me.
It is quite simple, you just have to use the normal do shell script, for example:
do shell script "open " & ¬
quoted form of POSIX path of ¬
alias ":path:to:applescript:apps:shell-script-launcher.app"
This may be helpful but I'm not an expert on this subject. I this case I found the double launching behaviour (on Yosemite, I haven't used any other version of OS X) very annoying and digging around I found one can check if it is already running.
This script is so I can launch a new terminal whenever I like.
if application "Terminal" is running then
tell application "Terminal"
activate
do script ""
end tell
else
tell application "Terminal" to activate
end if
I am trying to start a dxl script with command line. But i am getting lots of warnings and errors.
When I try this script on doors gui , it works fine but when i try on this command line without gui, it doesn't.
Here is the image of warnings :
Here is the commandline script :
"%ProgramFiles%\IBM\Rational\DOORS\9.3\bin\doors.exe" -d 36677#bie -u "xxx yyy" -P don -b "d:\workset\mc\addins\Devel\exporterRTF.dxl"
Why it doesn't work with commandline ? Any help, idea etc is appreciated.
EDIT :
this is a link which i try to run : myprogram.dxl
this is a link which is imported in my running script include in myprogram.dxl
this is a link which is secondly imported in my running script include in myprogram.dxl
There are other settings you need to run in Batch mode (pulled from the DOORS help):
Runs Rational DOORS in batch mode. Rational DOORS starts without the GUI (it suppresses the login screen and the database explorer), runs the specified DXL program, and then stops.
In batch mode you normally need other switches like -user, -password and -project to log in and specify the current project.
The parameter of the -batch switch specifies the file that contains the DXL program that you want to run in batch mode.
You probably need a current project specified. Also you may need to add a command at the end of your script to exit DOORS if you don't want the session to stay open.
The errors that you list seem like regular DXL errors, so if you need more assistance than this, you will need to post some of the code.
EDIT:
If you put all of the files into one does it run? Another option may be to include the Addins path on your command line. I believe the issue is that the batch mode is not recognizing the included files as part of the same scope.