I am trying to create an Automator Service that runs an applescript that eventually runs a bash script to ssh/scp to a server:
--
I have this applescript that saves my current photoshop document and calls a bash script to scp the image to a server. The bash script then runs ssh to do some stuff on said server with the image.
I have an ssh-askpass file and it seems to work well in most situations. I even tried reinstalling it to make sure I didn't goof on permissions, but it seems to be in good shape.
If I just run the applescript through Applescript Editor, it works fine and goes through ssh-askpass.
I want to create an Automator action (using the "service" template) to run my applescript, so I can just make it into a keyboard shortcut.
If I just run the script in Automator, everything works fine. Unfortunately, when I try to use the service outside automator (ie App Menu > Services), it seems that my Automator action is not attempting to go through ssh-askpass at all (which I verified with temporary logging)- everything works fine up to that point.
I looked into it a bit more, and it appears that a similar issue occurs when I try to run the applescript from the terminal (and not Applescript Editor)
--
Is there something different I need to do to ensure that an applescript (in Automator) uses ssh-askpass?
I found the issue. In the bash script I was calling, I was exporting the SSH_ASKPASS path, but not the display:
export DISPLAY=":0"
Apparently the AppleScript Editor (and XCode and Automator) does the exports for you, which is why it was working in those cases.
If you have control over your account on the server (e.g. shell account), I would just generate an SSH keypair and use it for authentication. That way, you can truly automate the exchange and not have to deal with ssh-askpass at all.
See http://paulkeck.com/ssh/ for a guide to making and deploying SSH keys.
Related
I developed a GUI application for macOS to record video from a computer screen. Can I add support command line? Example,
$myapp -start // Start recording video
$myapp -stop // Stop recording video
and etc.
If it's possible, then how can I implemented it?
It would probably make more sense to create a dedicated command-line tool, built by its own target, and include that as a "helper" executable in your application bundle.
You can then have your application install that as a command-line tool in /usr/local/bin/ by copying it, creating a hard link, etc. If it's a completed tool consider also installing a man page for it.
I want to be able to distribute my Sikuli script and allow the end user to run the script without installing Sikuli, my only problem at this point is not knowing what dependencies Sikuli needs to run (besides JAVA). With this knowledge I simply want to create a zip file for my user's machines that they can unzip into a folder and run the script.
Assuming you are using SikuliX as a command line script and not the IDE(IDE should probably work same way too. but I have not much experience with it) , you can simply copy the whole SikuliX folder to another PC and it will usually work straight away. As you mentioned yourself, the only requirement is Java.
I'm trying to make a custom remote for unified remote server in windows 8.1
The sample scripts have os.start(command). It works for something like calc, but I'm trying to launch a metro app 'netflix://' and Lua doesn't seem to want to accept it - I think it's not taking the front slashes.
Is there a way to get Lua to launch a metro app in windows? Thanks
Assuming you mean os.execute() command, to run commands that open files and run based on protocol association, you need to use start command:
os.execute("start http://google.com")
If you need to put the parameter in quotes, then make sure to include a pair of empty quotes as the first parameter:
os.execute([[start "" "netflix://..."]])
For os.start(), it seems that you have to pass the whole path to a command. The Unified Remote API states that it should match installed applications, but I believe it might only be applicable to applications with binaries in the PATH, which is why their example of calc works.
With this in mind, and knowing that start works well directly from PoweShell, this command does what we need:
os.start("C:\\WINDOWS\\system32\\cmd.exe", "/c", "start", "netflix:");
Answering this old question since it's the top google hit when looking for launching windows10 apps with Lua for Unified Remote
As a side note, due to limitations on the Netflix Win10 app, I ended up simply opening Firefox and giving it the Netflix URL. Assuming default installation:
os.start("C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe", "https://www.netflix.com");
I'm looking at simplifying the initial developer setup at my company by using Vagrant. On the surface, it seems pretty nice: I write a Vagrantfile once and commit it, and then new developers just install VirtualBox and Vagrant, git clone our project's source code, and type vagrant up, and they have a running web app, with all the dependencies handled automatically.
The one piece that I'm not sure about is the repl. It's common to run the command to start a shell with the web server's environment, for experimentation or testing or debugging or whatever. (I mean something like rails console. I'm sure every web framework has something similar.)
How do Vagrant users typically do this? Do you just keep a vagrant ssh window open, and run your repl in there? It seems awkward to have to use (potentially) a different window (and operating system) for just this one thing. But in order to run it natively, I'd need to install the whole development environment natively, which defeats the purpose of Vagrant in the first place.
Am I overthinking this? Is there some other practice that people typically use for this?
I think you are overthinking this a bit -- most modern deveopment requires an open command prompt or three, having it be SSH'd into a different box isn't really much different than running it locally in many cases.
Another angle for some things -- like code and scaffolding generation -- is to run those on the local box. Since there is that shared folder it will land on the server and you don't need to switch environments.
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.