|
Zaepho posted:[xml] $foo = '<xml><thing/></xml>' code:
|
# ? Aug 4, 2018 01:20 |
|
|
# ? Jun 3, 2024 21:46 |
|
anthonypants posted:That's...great. But it's more like this both are perfectly valid XML. There's also a .Net class you can use to pretty print it which I've done before but can;t recall the syntax off the top of my head.
|
# ? Aug 4, 2018 01:33 |
|
Zaepho posted:[xml] $foo = '<xml><thing/></xml>' Read before you post, the question wasn't about how to do it and you just regurgitated the exact method which anthonypants already mentioned in their own post. To expand on what nielsm said, standards-wise anything that isn't markup is just character data which can be anything really: https://www.w3.org/TR/xml/#syntax
|
# ? Aug 4, 2018 11:50 |
|
The Fool posted:Sanity check. You can store a password in DPAPI like this: code:
code:
|
# ? Aug 4, 2018 16:11 |
|
Is the thread gimmick not reading posts?
|
# ? Aug 4, 2018 16:43 |
|
cheese-cube posted:Is the thread gimmick not reading posts? My Read-Thread implementation is flaky, okay?
|
# ? Aug 4, 2018 17:18 |
|
Nth Doctor posted:My Read-Thread implementation is flaky, okay? Nah you're good, I'm pissing in the direction of Zaepho and peak debt.
|
# ? Aug 4, 2018 18:15 |
|
New Yorp New Yorp posted:Why can't you just store them as encrypted values in the build/release definition and pass them into the script when running? Because VSTS doesn't pass encrypted variables as enviroment variables, I would have to pass them as command line arguments which means they would end up getting logged in plain text. peak debt posted:You can store a password in DPAPI like this: DPAPI is encrypted per account and per machine. The entire point is to be able to store credentials in a way that doesn't require me pregenerating and storing them for a dozen servers.
|
# ? Aug 5, 2018 03:33 |
|
Does anyone know of a good resources for "best practices" around error handling? I understand the mechanics of the try-catch block but at work we've just got so much code that catches the error and throws "error: error" or some nonsense like that and I'm sure other people have solved this problem beyond "throw it all in a try-catch block and shrug your shoulders"
|
# ? Aug 7, 2018 23:38 |
|
FISHMANPET posted:Does anyone know of a good resources for "best practices" around error handling? I understand the mechanics of the try-catch block but at work we've just got so much code that catches the error and throws "error: error" or some nonsense like that and I'm sure other people have solved this problem beyond "throw it all in a try-catch block and shrug your shoulders" On my own scripts I usually throw an error regarding where the error happened so I don't have to step through the code every time, also I do logging of 'milestones' in the script, not sure what a standard is. I've also seen some scripts from our programmers that make .NET calls and they can pull back the error codes from that into a variable (or perhaps it's natively dumped into $error) and they'll give you that in the message. MF_James fucked around with this message at 23:45 on Aug 7, 2018 |
# ? Aug 7, 2018 23:43 |
|
It depends a lot on what the script's doing, too. Like maybe a script silently failing is okay, or maybe it needs to throw an error and stop processing immediately, or maybe it needs to return a different value, or maybe it needs to pass an error along to something else
|
# ? Aug 7, 2018 23:44 |
|
FISHMANPET posted:Does anyone know of a good resources for "best practices" around error handling? I understand the mechanics of the try-catch block but at work we've just got so much code that catches the error and throws "error: error" or some nonsense like that and I'm sure other people have solved this problem beyond "throw it all in a try-catch block and shrug your shoulders" It depends a bit—does a mechanism for recovery exist? If it’s an unrecoverable error there’s not much more you can do then stop and get the environmental variables to review what may have gone wrong. Some programs may require restaging or moving invalid files, etc so you can do cleanup work. You can break your errors out further by type and decide on actions based on specific known issues. Try/Catch can get as simple or complicated as you want to make it, it’s essentially an if/else for “does this code work”.
|
# ? Aug 7, 2018 23:46 |
|
This is all just in scripts we run, and I'm absolutely tired of seeing poo poo like this:code:
|
# ? Aug 8, 2018 00:37 |
|
FISHMANPET posted:This is all just in scripts we run, and I'm absolutely tired of seeing poo poo like this: I tend to leave my try/catch efforts out until everything else is solidly coded. I'll pepper my code with comments and send error messages directly to the console. Unless they're script-stopping, then I'll chuck a try/catch around them just to keep the script flowing until I've debugged. It also depends on what I'm being asked to return. Sometimes I'll throw a try/catch around something that could error out with nothing inside the catch {}, but sometimes I'll have multi-nested crap going on because someone at some point is going to be pissed if they can't see something in a log on the regular. But I'm a bit of a feral coder who likes to iterate rather than pseudo-code and refine, so YMMV.
|
# ? Aug 8, 2018 20:53 |
|
If you want to standardize your exception catching, you can write a function to rule over evaluating fatal/non-fatal errors and return values your script can handle in some sort of switch or other evaluation method:code:
|
# ? Aug 8, 2018 21:32 |
|
I'm not doing anything particularly crazy with Powershell scripts so I can't say it would work for everyone, but I don't use unfiltered try/catch blocks. I use a try/catch if a) what I'm doing has a non-negligible chance of directly throwing an exception, AND b) that exception is something that either is recoverable or requires me to do some cleanup. And then the catch block is scoped to the type of exception that I expect. If your script is deleting a list of files then absolutely catch System.IO.FileNotFoundException (and maybe whatever permissions errors evaluate to), log that something weird happened with that file, then continue and try to delete the rest. But if that action throws an OutOfMemoryException or something then the last thing you need is a try/catch swallowing it and just writing "Something went wrong!" to a log file. So in terms of standards I would start with never write catch without a list of types that you expect and will deal with in the catch block.
|
# ? Aug 8, 2018 22:53 |
|
Mega agreed, generally avoid blanket catching in final code unless you are a glutton for punishment. Like all things, there are exceptions () but always keep types in mind.
|
# ? Aug 8, 2018 23:06 |
|
Can someone point me to a VSCode and Git/VSTS for dummies blog post?My team has no version control whatsoever and this should be an easy thing for me to set up and get brownie points for. I've barely managed to get VSCode set up with a couple plugins for Powershell and VSTS. I tried setting up a Git repository in VSTS and I think I've managed to get VSTS to commit to my local repo but I can't get the changes to sync to VSTS.
|
# ? Aug 10, 2018 02:48 |
|
Your VSTS repo needs to be the remote origin for your local repo, then you commit and push and your changes will show up.
|
# ? Aug 10, 2018 06:04 |
|
The folks behind dbatools have a guide for how to contribute to their project using VSCode and Github. You'll have to swap out the URLs for your own repos, but it's a pretty clear step-by-step guide.
|
# ? Aug 10, 2018 16:40 |
|
For the purposes of testing a different file load mechanism someone wants me to split a 7.5GB text file into six equal portions. Am I overthinking it or is this all it really needs: code:
|
# ? Aug 21, 2018 19:50 |
|
I don't know if it was ever fixed but Powershell loops are hella slow, and some variations are like 10x slower than others (piping to ForEach-Object is particularly bad if I remember right). If you don't have to process the actual text then you just need FileStreams. Open the source file with one stream, create a new destination text file and open as a second stream, then just feed the first stream into the second in big chunks until you hit ~1.2GB. Then close that destination stream, open a new one and continue. If you loop line by line in PS it might take days.
|
# ? Aug 21, 2018 22:50 |
At the very least don't use Add-Content inside the loop like that. You should open all the output files before the loop and keep them open throughout.
|
|
# ? Aug 21, 2018 23:27 |
|
Scikar posted:I don't know if it was ever fixed but Powershell loops are hella slow, and some variations are like 10x slower than others (piping to ForEach-Object is particularly bad if I remember right). If you don't have to process the actual text then you just need FileStreams. Open the source file with one stream, create a new destination text file and open as a second stream, then just feed the first stream into the second in big chunks until you hit ~1.2GB. Then close that destination stream, open a new one and continue. If you loop line by line in PS it might take days. Is this why my stupid compare function takes forever? I mean, I'm doing a few hundred thousand loops (possibly a million+?) but I've never had a powershell script take 45 minutes to complete.
|
# ? Aug 21, 2018 23:34 |
|
Yeah for whatever reason I didn’t think to do outgoing streams too, which is obviously now. It took 2.5 hours but I’ll make the update and see what the difference is.
|
# ? Aug 22, 2018 00:29 |
|
Judge Schnoopy posted:Is this why my stupid compare function takes forever? I mean, I'm doing a few hundred thousand loops (possibly a million+?) but I've never had a powershell script take 45 minutes to complete. I think this is what I was thinking of: https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/08/getting-to-know-foreach-and-foreach-object/
|
# ? Aug 22, 2018 00:33 |
|
PierreTheMime posted:Yeah for whatever reason I didn’t think to do outgoing streams too, which is obviously now. It took 2.5 hours but I’ll make the update and see what the difference is. I'm doing ~2.5gb in ~15sec with: code:
|
# ? Aug 22, 2018 01:01 |
|
I reworked it using a StreamWriter and it is so much faster it's laughable (1.5GB in about 10 seconds) Edit: Semi-final code seems to work, probably a little bit more verbose than necessary, but let me know if anything pops out as "bad" since I'm always up for learning better methods. code:
PierreTheMime fucked around with this message at 15:54 on Aug 22, 2018 |
# ? Aug 22, 2018 02:42 |
|
Scikar posted:I think this is what I was thinking of: https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/08/getting-to-know-foreach-and-foreach-object/ Ahh, I exclusively used foreach statements so it wouldn't have impacted my script. Turns out a million loops just takes a long loving time to do!
|
# ? Aug 22, 2018 03:03 |
|
How do I read the HTTP response headers that I get back from a successful Invoke-RestMethod request? This stupid API has put the ID value that I need inside the header, rather than in the json. For example: code:
|
# ? Aug 23, 2018 21:48 |
|
I think you either get to use PowerShell Core, where this might be fixed, or to use something else.
|
# ? Aug 23, 2018 22:23 |
|
I don't know if it helps this situation at all, but the Powershell Core 6.x version of Invoke-RestMethod has a ResponseHeadersVariable outputs the return headers to a variable. If it's a only-need-it-once type thing, maybe Fiddler? Otherwise, you're stuck using Invoke-WebRequest and piping the data to a json.
|
# ? Aug 23, 2018 22:36 |
|
Fiddler is okay but Postman is super good at writing and testing REST statements.
|
# ? Aug 23, 2018 22:39 |
|
anthonypants posted:I think you either get to use PowerShell Core, where this might be fixed, or to use something else. sloshmonger posted:I don't know if it helps this situation at all, but the Powershell Core 6.x version of Invoke-RestMethod has a ResponseHeadersVariable outputs the return headers to a variable. gently caress me. Thanks. My script has to run on a VSTS hosted agent, so I don't think I can go the core route. drat, I was so close, why can't this stupid API return the id value that I need in the json rather than loving putting it in the header. So dumb.
|
# ? Aug 23, 2018 22:44 |
|
You could probably use PowerShell to make the REST calls via .NET?
|
# ? Aug 23, 2018 22:52 |
|
anthonypants posted:You could probably use PowerShell to make the REST calls via .NET? Haha yup, that's literally what I'm starting to test right now. Going to have to do this via .NET objects instead of that nice cmdlet. Sigh.
|
# ? Aug 23, 2018 22:56 |
|
CLAM DOWN posted:Haha yup, that's literally what I'm starting to test right now. Going to have to do this via .NET objects instead of that nice cmdlet. Sigh. Why not use Invoke-WebRequest? If the response is json just do, $stuff.Content | ConvertFrom-Json
|
# ? Aug 24, 2018 01:20 |
|
PBS posted:Why not use Invoke-WebRequest? If the response is json just do, $stuff.Content | ConvertFrom-Json
|
# ? Aug 24, 2018 01:24 |
|
PBS posted:Why not use Invoke-WebRequest? If the response is json just do, $stuff.Content | ConvertFrom-Json I forgot about ConvertTo/From-Json. I'll try that. I'm still annoyed that Invoke-RestMethod is lacking this.
|
# ? Aug 24, 2018 01:36 |
|
|
# ? Jun 3, 2024 21:46 |
|
anthonypants posted:Invoke-WebRequest isn't available in certain versions of PowerShell. Ah, that makes sense. CLAM DOWN posted:I forgot about ConvertTo/From-Json. I'll try that. I'm still annoyed that Invoke-RestMethod is lacking this. Yeah, it's dumb.
|
# ? Aug 24, 2018 01:41 |