Ok, I'll give Windows 7 this: it's privilege separation is much more manageable. I don't have to right-click to "run as" to do elevation - it just prompts me, as necessary, to select an admin-enabled account to do the operations. Makes it easier/more practical to run with a plain user account. FINALLY.Now, if the lazy app writers would address privilege levels in their programs. Not EVERYTHING needs to run with system or administrator privileges.
Showing posts with label windows. Show all posts
Showing posts with label windows. Show all posts
Wednesday, September 1, 2010
Wednesday, August 25, 2010
The Kind of Hacks That Make You Feel Like You've Got a Furball
Ok, so, I had to dig through the script-fu memory banks to try to help a storage guy build a parameterized script to control the creation of metaluns on a CLARiiON array.
Now, the guy I'm working with is very much a "Windows guy". His way of doing things has been the "click-click-click-click-click" way. For better or worse, when you need to do tasks in a large-scale environment, all that clicking becomes very tedious. Being a Windows guy, his first impulse was to try scripting on Windows (*facepalm*). Needless to say, that proved an odious task. So, he asked if I could help him.
A lot of my scripting-fu relies on "finger memory". Basically, if I have an end state in mind, my hands just sort of vomit forth the code needed to reach that end state. Walking someone through that process can be rather painful, especially when you're as big into regex as I am and they have no clue. That, and having to simultaneously tutor on vi during the process just raises the aggro-stakes.
At any rate, the operation he needed to do required creating a script that used six variables to do the work. The first run through the script, we simply hard-coded the variables so we could vet the overall logic flow. Obviously, hard-coding a dynamic task is sub-optimal. So, we then went through the process or converting the hard-coded variables to ones that were set via passing parameters to the script at the command line.
Guy I'm working with is decently clued, so he didn't want a completely "blind" script (one with absolutely no validity checking). He wanted for the script to, at the very least, ensure that the user passed the requisite number of arguments. Should the script user fail to do so, they'ed get a usage statement. So, what was the most effective way to determine whether the number of arguments passed matched the number of arguments that the script needed in order to do it's job?
After mulling it over, I came up with the following bit of ugliness:
If you've got ideas on a more elegant approach within a /bin/sh-type construct, I'd love to hear it. Probably going to have to shred that, any way, when we add in the other bounds-checking.
Now, the guy I'm working with is very much a "Windows guy". His way of doing things has been the "click-click-click-click-click" way. For better or worse, when you need to do tasks in a large-scale environment, all that clicking becomes very tedious. Being a Windows guy, his first impulse was to try scripting on Windows (*facepalm*). Needless to say, that proved an odious task. So, he asked if I could help him.
A lot of my scripting-fu relies on "finger memory". Basically, if I have an end state in mind, my hands just sort of vomit forth the code needed to reach that end state. Walking someone through that process can be rather painful, especially when you're as big into regex as I am and they have no clue. That, and having to simultaneously tutor on vi during the process just raises the aggro-stakes.
At any rate, the operation he needed to do required creating a script that used six variables to do the work. The first run through the script, we simply hard-coded the variables so we could vet the overall logic flow. Obviously, hard-coding a dynamic task is sub-optimal. So, we then went through the process or converting the hard-coded variables to ones that were set via passing parameters to the script at the command line.
Guy I'm working with is decently clued, so he didn't want a completely "blind" script (one with absolutely no validity checking). He wanted for the script to, at the very least, ensure that the user passed the requisite number of arguments. Should the script user fail to do so, they'ed get a usage statement. So, what was the most effective way to determine whether the number of arguments passed matched the number of arguments that the script needed in order to do it's job?
After mulling it over, I came up with the following bit of ugliness:
It's not exactly "ideal", but it's a start. How suitable it will end up being in the context of the final script is yet to be seen.#!/bin/ksh NUMVARS=0 for i in "$@" do echo "Args for $0 is $i" NUMVARS=$(($NUMVARS + 1)) done echo $NUMVARS if [ ${NUMVARS} -lt 6 ] then echo "Insufficient arguments" fi
If you've got ideas on a more elegant approach within a /bin/sh-type construct, I'd love to hear it. Probably going to have to shred that, any way, when we add in the other bounds-checking.
Subscribe to:
Posts (Atom)