I wish to run a script in the boot process, and I need it to run as late as possible, preferably after the actual Android GUI is available.
I tried placing it under 'on fs', in the init.rc, but it doesn't seem late enough, and I'm not sure the build I'm working with provides things like 'post-fs'.
So my question is actually split into two:
Where in the AOSP build folder can I start looking for the property list (Not very familiar with it, I'm a low-level guy) that can be used in init.rc (i.e. 'on property:name=value').
Is there a way to run the script only after the GUI is available?
Related
I'm trying to figure out if I can launch a pre-built Alteryx workflow without launching the Designer - and without having Alteryx Server.
I came across a helpful post on Alteryx uses by #Runonthespot that, among other things, addressed running workflows from the command line, but doesn't go into detail. That discussion is here: https://stackoverflow.com/a/30469848/4313331. I don't have the rep to comment on his post and the question is closed.
He writes:
"Flows are runnable from the commandline on a server, and easiest way I've found (besides using Alteryx's own scheduler) is to save as an "App", and then run from the command line using the Alteryx engine executable, passing it parameters via xml file. You can save a sample xml parameter file from your flow by hitting the magic wand button (after saving the flow as a .yxwz (app)) This brings up a panel that lets you set the variables, and that panel has a handy "save" button which generates an xml file in the right format."
So, I'm looking for more info on this process. Is it simply a question of using Alteryx Server? Or is this a more interesting work around?
Thanks.
Yes, you can run a workflow (used generally to refer to a workflow, macro, or analytical app) without launching the Designer. You'll first need to understand how to run the workflow from the command line. The AlteryxEngineCmd.exe executable runs a workflow. It is located in the Alteryx install path in the bin subfolder. Here is where mine is located:
C:\Program Files\Alteryx\bin
It allows an additional parameter of an XML file with interface values. This is documented for analytical apps ONLY though it does work for macros as well. This is based on my extensive use of this undocumented feature.
Below are two examples:
AlteryxEngineCmd.exe MyWorkflow.yxmd
AlteryxEngineCmd.exe MyAnalyticApp.yxwz AppValues.xml
You can see a post here:
Alteryx Command Line Help
I prefer to wrap the command in a batch file and execute that for more control.
Now that you understand how to run the workflow from the command line, you can execute it anytime you want without launching Designer. Furthermore, you can use Windows Scheduler or a third-party tool to run the command or the batch file on a schedule.
Finally, you do need a license which enables API & Command Line w/ Scheduler. This is less expensive than Alteryx Server.
Have you tried C:\Program Files\Alteryx\bin\AlteryxEngineCmd.exe? It doesn't require server.
https://help.alteryx.com/2019.1/Command_Line.htm
If restrained by budget, you don't need a scheduler license (enables the AlteryxEnginecmd.exe), you can use a windows mouse clicker or even Powershell, to run the Designer though, without manual intervention.
i have been assigned to present about 'run'command in selenium IDE but icant found any related examples or documentation
I make a lot of use of the run command. I use it to make up a test out of building blocks.
So, if I'm testing something that sits behind a login form, then I might have a test which is the happy path for login, and then a series of tests to test the feature. I don't want to have to have the login steps in each test - as if the login functionality changes I'd need to rebuild all of my scripts.
So, in this case, I'd have a test called #login (I use # to prefix those that are building blocks for easy identification and so that they float to the top of the list of tests in the IDE view) which would do the simplest thing possible to log in successfully.
When writing my tests for the new feature, I'd start with the following
Command: run
Target: #login
which I know will do a happy path login.
I can then build on top of that with the test steps for my new functionality
I'm in the process of trying to write a VSCode extension to support basic SNES application development. I already have a basic grammar definition and build task, so I have syntax highlighting, and am able to build my project with Ctrl+Shift+B using the bass v14 assembler, but now I'm trying to figure out how to launch the project using launch.json. I've already worked through the official docs and played around with the mock debugger project, but I can't seem to figure out how to adapt it for my extension. To start, I'm using the bsnes-plus emulator as my debugger. There isn't really any command-line or IPC interface that will actually allow me to implement a proper debug adapter, so all I really want to do is to run the program and pass it my output file to launch. For the time being, I'm assuming that bsnes-plus.exe is located in my $PATH, but eventually I'll try and figure out the best practices for external executable dependencies for an extension.
So here are my current questions:
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
At one point, I was able to get the launch command to open bsnes-plus, but not load the game, and when I closed it, VSCode complained that the debugger terminated unexpectedly and immediately re-opened bsnes-plus. How do I avoid this? Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
This is entirely up to the debug extension. It's just passed through to the debug adapter. It usually corresponds to the specific app/script being debugged though, not the runtime that's running it, so I would suggest it should be your compiled application.
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
You can put it any other field. In Dart, we have a dartPath field that can be passed through to the debug adapter. It's usually populated silently by the DebugConfigurationProvider.resolveDebugConfig though (we detect the SDK by searching PATH) so the user never needs to add it.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
You can't make your own variables, but using resolveDebugConfig you can manipulate the launch config yourself before it's passed to the debug adapter, which probably allows you to do what you need here (eg. you could do a string replace on program - or you could even just add it if it's not set, allowing a launch.json-less launch too).
Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
I'm not sure what happened here without more details, but having a debug adapter probably makes the most sense - for example if you want to make the Stop/Restart buttons work on the toolbar, you'd probably want a debug adapter that can terminate and/or restart the process.
I'm tasked with reducing a 50-page installation manual to "much less"; a bunch of applications need to be installed in a specefic order, with specific options, and so on. Can I use any of the popular installers (WiX, NSIS, Inno Setup) to automate this process, or do I need to use Powershell?
I've read about what these installers can do, and as far as I can see they're designed to install one application to one computer -- I haven't seen that or even if they can be used to control other installers in a very detailed fashion -- "use this, this, and this option on this wizard page, but not that one on the next wizard page, and install to this path, then enter these details (users, whatever)".
Am I wildly over-understanding what these tools can do? Given that I need to do this, what's the best way to go about it?
Update 2: I learn that installers do offer silent install by way of a config file. Neat! I'm currently looking at NSIS (spawning Powershell scripts and other installers) as the option that's easiest to just start & go with. I like that I don't need a custom IDE for it. But I'm also wondering wether NSIS is (soon) obsolete, in a Windows 7&10 world?
You should look at WiX with a custom bootstrapper UI. That can be used to install any number of setups in whatever order you want. The tricky question is whether all those setups need to show their own UIs, one after the other. If they can all be installed silently with command line paramaters, then your WiX bootstrapper could show your UI to collect all the options, and then install each of the setups silently while you show progress for the entire operation. You could also get a single entry for the entire package in Programs&Features. So something like WiX could do it, but the UI requirements could make it awkward.
PowerShell CAN do it, but it's through invoking COM objects and sending keys to the window, so it's not the BEST way to do it. I'm going to repost something I posted yesterday to a similar question about using PowerShell to uninstall some unwanted software.
QFT:
PowerShell isn't going to interact with the prompts... you can't just tell it to click "Next" in an executable because it can't see it.
You can send keys to it though. You're really just using COM objects.
So, first, get your process ID by setting a variable that contains an array, the data for which is defined by the name of your process. Let's say your process is called, "Uninstall" and the process is ALREADY RUNNING:
$a = Get-Process | ?{$_.Name -eq "Uninstall"}
Start the COM:
$wshell = New-Object -ComObject wscript.shell;
Bring the uninstallation program with this process ID to the front so we can send it keystrokes:
$wshell.AppActivate($a.id)
Give it a few seconds to bring that window forward. I chose 5, but if your machine isn't stressed, 2 is probably enough:
Start-Sleep 5
Now start telling it what keys you want to send. The syntax here is this: whatever is in the () is what will be sent. The position in the single-quote is the keystroke to send, after the comma is how long you want it to wait before proceeding. Assuming the first screen is "Next" you can send your first command by telling PowerShell to send the ENTER key and wait 5 seconds:
$wshell.SendKeys('~',5)
The wait function is optional, but for your purposes, you're definitely going to want it. (If you don't want it $wshell.SendKeys('~') would send the ENTER key and immediately move to the next command.)
Walk through the uninstallation yourself manually, using all keystrokes, and for any keystroke you send, pay attention to how long it takes before the next part of uninstallation is loaded, and wait longer than that with your script (e.g. if it processes your ENTER key instantaneously, I'd have it wait 3 or 5 seconds before it sends the next command. If it takes 5 seconds to load, I'd tell it to wait 10 seconds before sending the next command).
Letters are letters, and numbers are numbers. Most non-commands are just assigned to their keys (meaning if you want to type "K" your command would just be $wshell.SendKeys('K')) You can get the rundown for the specific keys here: https://msdn.microsoft.com/en-us/library/office/aa202943(v=office.10).aspx.
/QFT
You may want to look into Auto-It, but that's based on pixel, last I checked, so if you run it on machines with different screen resolution, it can cause problems.
How you approach this really depends on if these other installers supports silent mode and/or answer files. This page list the options for some of the popular installers.
If they do and you decide to use NSIS then you would just do something like this:
Name "BundleInstaller"
OutFile "bundlesetup.exe"
RequestExecutionLevel Admin
Page Components # Comment out this if you don't want the user to have a choice
Page InstFiles
Section -Init
InitPluginsDir # $PluginsDir directory is deleted when the installer quits
SetOutPath "$PluginsDir"
SectionEnd
Section "Foo v1.2.3"
DetailPrint "Installing Foo"
File "FooSetup.exe"
ExecWait '"$PluginsDir\FooSetup.exe" /S /D=$ProgramFiles\Foo' # This is the syntax for NSIS installers
SectionEnd
Section "Bar 2015"
DetailPrint "Installing Bar 2015"
File "BarSetup.msi"
ExecWait '"MSIEXEC" /qb /i "$PluginsDir\BarSetup.msi" REBOOT=ReallySuppress'
SectionEnd
Section -Cleanup
SetOutPath "$Temp" # Release current directory lock on $PluginsDir
SectionEnd
If this solution is not possible then you are looking at some form of automation like the other answers have suggested.
I'd say there are two forms of automation; one where the app you are automating has to be the active window and the other where you send messages instead of keystrokes.
Just sending Enter to the active window with some sleep's thrown in is of course the easy solution but it can break if somebody starts interacting with the machine.
NSIS supports commands like FindWindow and SendMessage and I assume AutoHotkey does as well. The advantage to using FindWindow to find a specific HWND and then sending it a message directly is of course that the application does not have to have keyboard focus. This approach requires a bit more work but the end result is better because you only use SendMessage after finding the right window (and you can make sure the window/control is visible and enabled etc) so you know the application is in a known state without having to hope that the sleep was long enough...
Installing other installers is no problem with any decent installer builder.
These other installers are either msi, exe or zip files.
I do not assume that the installers (for SQL database servers and the like) offer silent install (by way of a million command-line parameters or a config file).
I highly doubt I can launch these installers in silent mode (with a million command line parameters)... :-(
Fetch the installer for the SQL database server and check it.
Most of the installers offer a silent install.
msi or exe files created by another installer builder accept CLI arguments to select components and set the target path
even exe files created as SFX archives accept a target path for the unpackaging
some installers do not provide all form-fields of their GUI configuration dialogs as CLI parameters. for those installers you would need a post-configuration step, which might simply consist of copying a default config file into the application folder
Yes, its also possible to center an installer around the idea of "gui automation" or "inserting keystrokes" using AutoIt, AutoHotkeys or any other Automation tool from inside the main installer.
You would need to build an automation script for each installer and execute it from the main installer. Its probably nice for testing and replaying the individual component installations.
But YAGNI.
Given that I need to do this, what's the best way to go about it?
Make a full run and note all the installation steps.
list the installers you need
find the download urls
download the installers
download additional tools you need (unzip?)
for each installer check the CLI arguments it accepts
check if you get a decent default configuration, when leaving some CLI args away
install each installer from the CLI into your target location
Then translate the steps you have into the Installer builder of your choice. Its mostly copy pasting CLI commands into Exec() or ShellExec() calls, followed by copying config files and fiddling around with cross-component configuration.
I haven't seen that or even if they can be used to control other installers in a very detailed fashion
Just think of all the game installers shipping DirectX or the pre-packaged web-development stacks like XAMPP or WPN-XM (speaking of the last: you might take a look at this InnoSetup script file).
A wrapped installation of multiple software components is pretty common.
I have a command-line application that I want to run in a build configuration for the duration of the build, then shut it down at the end when all other build steps have completed.
The application is best thought of as a stub server, which will have a client run against it, then report its results. After the tests, I shut down the server. That's the theory anyway.
What I'm finding is that running my stub server as a command line build step shuts down the stub server immediately before going to the next build step. Since the next build step depends on the server running, the whole thing fails.
I've also tried using the custom script option to run both tools one after another in the same step, but that results in the same thing: the server, launched on the first line, is shut down before invoking the second line of the script.
Is it possible to do what I'm asking in TeamCity? If so, how do I do it? Please list any possibilities, right up to creating a plugin (although the easier, the better).
Yes you can, you can do that in a Nant script, have Teamcity run the script, look for spawn and the nantContrib waitforexit.
However I think you would be much better off creating a mock class that the client uses only when running the tests. Instead of round tripping to the server during the build as that is can be a bit problematic, sometimes ports are closed, sometimes the server hangs from the last run, etc. That way you can run the tests, make sure the code is doing the right thing when the mock returns whatever it needs to return etc.