Dears,
This is my first time with PowerShell. Is this possible to log into several webpages via Script. So that I can run a script and I am logged into several webpages, instead of going into every one separately. This would save me a lot of time.
I searched through a web to find this but I only managed to find the code that opens a webpage..
Thank you very much for your help!
I don't think this is best suited for powershell, though it is possible. If you want to automate web actions then i'd suggest you look into using a library like selenium.
Most popular languages have a wrapper for selenium so you can write it in your language of choice. See this gist for an example of implementing it in powershell.
Related
so I'm trying to put together a pretty simple serverless application to learn the architecture better. It's a pretty basic thing - user uploads 23andme data, perl script converts the txt file into into vcf, that's uploaded to cloud storage, google genomics takes it from there and gives it to bigquery for annotation. Automating this into a pipeline would be pretty easy with a persistent vm, but I was hoping someone on here would know something obvious I'd just missed
I've got a decent idea of how to automate most of this into an automatic pipeline, but the perl script seems to be a bit of a sticking point. Might be because perl is one of a handful of languages I don't even know the basic syntax of, but does anyone have any recommendations on how I could make this work, short of just rewriting the 23andme-vbf script in Python or scrapping the 'serverless' part of this idea, since automating all of this would be pretty trivial with a persistent vm but I was hoping it might be something obvious I'd just missed.
It seems like other people have asked similar questions here in the past, but as of yet, I've been unable to find any of them with any answers.
This will be nontrivial even if you do know the basic syntax of Perl. One way that the Google Cloud supports Perl is to run a Mojolicious app inside a Perl Docker container. On your end, you would need to wrap your Perl script in a Mojolicious application that would be deployed to the cloud.
Perl is supported in Google App Engine as described by the Google Cloud Blog
There are examples around particularly for running Mojolicious applications such this Github Repo but I guess it depends largely on how you want to architect your solution.
Running your Perl application within a container may be the simplest approach.
You could try to convert the perl code to javascript using emscripten and run it with Cloud Functions.
There are some online tools that allow you to run perl through an interpreter created with emscripten, running javascript. You can try them out by pasting some perl code in the browser:
https://www.shlomifish.org/microperl-web-repl-v1/repl.html
https://gfx.github.io/perl.js/
This is probably not an easy task to accomplish if you have a large perl script, but could be a starting point.
Although there have been quite some posts on these topic, my question is little bit specific.
I need to parse few website and once done, I need to send some data to it. For example, say website A offers me a search tab, I need to programatically feed data to it. The resulting page might differ based on target site's updates.
I want to code such a crawler. So which tools/language would be best to realize this?
I am already well-versed in java and C, so anything based on these would be really helpful.
I would suggest using phantomjs. It's completely free and Windows, Linux, Mac are supported.
It is very simple to install.
It is very simple to execute using
command line.
Community is pretty big and solving straight-forward
problems is trivial.
It uses JavaScript as the scripting language so you'll be fine, I guess, with your Java background.
You'll have to get familiar with DOM structure. Well, you cannot write a crawler without knowing it (even in case you select completely visual solution).
Everything depends on how frequently the crawler should be executed: PhantomJs is great for long-term jobs. Use something else, visual, like iMacros in case you're looking for one-time solution. It can be used inside Mozilla as an extension (free of charge) and there's a standalone version that costs money.
Cheers
I'm adding Powershell support to an app as an internal automation/scripting language. One of the things I want to do is have a runtime environment where I can enter commands, get output, etc. So I started looking at implementing my own PSHost.
Then I imagined my future. Over time, I'll implement a prompt/command/execute/response+log loop, possibly a configurable UI, maybe some amount of debugging like simple breakpoints...
Oh no! I'll be writing my own ISE!
So my question is: is it possible to use the ISE for the Powershell scripting in my app? Perhaps through remoting? Perhaps through embedding of certain ISE components?
I haven't seen any way that ISE exposes its interface except as an end-user application. I have written a host, however, and it's not as bad as it sounds.
I package our server releases into zip files using a batch file (Windows), running the command-line version of WinZip. Previously we did this sort of thing "by hand" but I developed the process of automating it with a batch file.
The batch file has become quite complicated because our product is complicated (i.e., Which sections are we releasing this time? Are we releasing the config files as well?) and I'm starting to run into some frustrating limitations with batch files.
Would PowerShell be a good thing to investigate as an "upgrade" to the batch file? Or is that complete overkill given that most of what it would be doing is firing off DOS commands?
Bonus: can PowerShell consume .NET assemblies? As in, could I start doing the zipping with SharpZip?
If you have a working solution, then you don't need to go to powershell. Having said that, if you plan to make changes or improve the process then I would highly recommend powershell as the way to go. Powershell can access .Net assemblies...mostly. Some assemblies are structured in a way that makes it more difficult than others.
You can check here for some resources if you decide to look at powershell.
Initially I was really excited about PowerShell. Finally a powerful native shell on Windows. However, I quickly realized that compared to your favorite unix shell PowerShell is just way too verbose. Even doing simple stuff takes way too much typing compared to what you can do with bash and GNU tools for Win32.
I like the idea, that the shell knows about different types, but if I need to do that much additional work, I prefer just getting the necessary data with the various unix stream editors.
EDIT: I just had another look at PowerShell, and I have to admit, that it does have some really useful features that are not available for the traditional unix style tools.
For one the PowerShell owns all the commands which means that it can provide a much more coherent set of features. Parameters are treated uniformly, you can search for commands, parameters and so forth using wild cards which is really useful.
The second great feature is that PowerShell lets you enumerate sources which are normally not available to stream editors such as the Windows registry, the certificate store and so forth. Of course you can have tools that does this for you and present it as text, but the PowerShell approach is just really elegant IMO.
Take a look at PowerShell Community Extensions (PSCX), its FREE and it has Zip cmdlets:
Write-Zip
Write-BZip2
Write-GZip
http://www.codeplex.com/PowerShellCX
You should watch this presentation/discussion with Jeffrey Snover, PowerShell creator and architect. If you're not amazed by the technical details (lots of "wow" moments to be had), you'll be amazed by Jeffrey's enthusiasm :). Once you get the basics, it's easy to be very productive with PowerShell.
The answer is YES - PowerShell can use .NET assemblies. There is a bit of funny business involved in v1 if you need to wire up delegates and v2 makes that much more clean.
Just call LoadFile / LoadAssembly to get the appropriate libraries in memory and away you go
[Reflection.Assembly]::LoadFile('/path/to/sharpzip.dll')
$zip = new-object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.CreateZip('C:\Sample.zip', 'C:\BuildFiles\', 'true', '^au')
# note - I didn't actually test this code
# I don't have SharpZip downloaded - just read their reference.
Also note that the PowerShell Community Extensions support various compression methods like write-zip.
I've tried to replace one of the lengthy build batch files I use with power shell. I found it a pain: at least at that time, documentation focused on the funny verbiage and what cool, perly things you can do with it, but lacked in the "getting simple things done" category. I got it working, but the error handling was to shaky.
YMMV, try powershell, you might enjoy it. But try it before updating your build batches.
My solution: use a C# console application. I've got serious logging, exception handling, can use my utility functions, and if something doesn't work I have a real debugger. It's the first solution I like to modify.
I'm not sure about powershell, but might I recommend using something like IronPython (if you want to have access to the .NET libraries) or plain python? You get a full-blown programming language with very few limitations.
On the one hand, if it works, just leave it. But it sounds like this is something you'll be adding to over time, and of course your eventual successor/coworker who needs to edit the batch file will also need to understand it. If you're from a programming background then you may well find the power of Powershell makes your script a lot shorter and easier to read/maintain (for example, even just having full if statements and for/while loops). On the other hand if you're not overly familiar with programming, a lot of people find Powershell a bit daunting at first glance.
Regarding the .NET part, Powershell is built on top of .NET so yes, you can access .NET assemblies (but you should always see if there's a cmdlet available first).
I would recommend a book called "The Powershell Cookbook" by Lee Holmes, published by O'Reilly. It provides "recipes" which you can use for common tasks; this will probably speed up your time to implement the script, and it'll teach you Powershell along the way.
Our company is currently writing a GUI automation testing tool for compact framework applications. We have initially searched many tools but none of them was right for us.
By using the tool you can record test-cases and group them together to test-suites. For every test-suite there is generated an application, which launches the application-under-test and simulates user-input.
In general the tool works fine, but as we are using window handles for simulation user input, you can't do very many things. For example it is impossible for us to get the name of a control (we just get the caption).
Another problem using window handles is checking for a change. At the moment we simulate a click on a control and depending on the result we know if the application has gone to the next step.
Is there any other (simpler) way for doing such things (for example the message queue or anything else)?
Interesting problem! I've not done any low-level (think Win32) Windows programming in a while, but here's what I would do.
Use a named pipe and have your application listen to it. Using this named pipe as a communication medium, implement a real simple protocol whereby you can query the application for the name of a control given its HWND, or other things you find useful. Make sure the protocol is rich enough so that there is sufficient information exchanged between your application and the test framework. Make sure that the test framework does not yield too much "special behavior" from the app, because then you wouldn't really be testing the features, but rather your test framework.
There's probably way more elegant and cooler ways to implement this, but this is what I remember from the top of my head, using only simple Win32 API calls.
Another approach, which we have implemented for our product at work, is to record user events, such as mouse clicks and key events in an event script. This should be rich enough so that you can have the application play it back, artificially injecting those events into the message queue, and have it behave the same way it did when you first recorded the script. You basically simulate the user when you play back the script.
In addition to that, you can record any important state (user's document, preferences, GUI controls hierarchy, etc.), once when you record the script, and once when you play it back. This gives you two sets of data you can compare, to make sure for instance that everything stays the same. This solution gives you tests that not easy to modify (you have to re-record if your GUI changes), but that provide awesome regression testing.
(EDIT: This is also a terrific QA tool during beta testing, for instance: just have your users record their actions, and if there's a crash, you have a good chance of easily reproducing the problem by just playing back the script)
Good luck!
Carl
If the Automated GUI testing tool has knowledge about the framework the application is written in it could use that information to make better or more advanced scripts. TestComplete for example knows about Borland's VCL and WinForms. If you test applications build using Windows Presentation Foundation has advanced support for this build in.
use NUnitForms. I've used them with great success for single and multi threading apps and you don't have to worry about handles and stuff like that
Here are some posts about NUnitForms worth reading
NUnitForms and failed DragDrop registration - problem of MTA vs STA
Compiled application exe GUI testing with NUnitForms
I finally found a solution to communicate between the testing-application and the application-under-test: Managed Spy. It's basically a .NET application build on top of ManagedSpyLib.
ManagedSpyLib allows programmatic access to the Windows Forms controls of another process. For this it uses Window Hooks and memory-mapping files.
Thanks for all who helped me to get to this solution!
Managed Spy does not provide a solution for compact framework applications.
The company Jamo Solutions (www.jamosolutions.com) meets the requirements for automation testing on mobile devices, including .net compact framework applications.