PowerShell?

Coding
#1

I’ve been investigating Windows PowerShell today, and it struck me that it might have the potential to be a pretty useful tool to add to the arsenal…

We’re a pretty C# heavy studio, using it for the vast majority of our tools and pipelines, and PowerShell’s interoperability with .Net seems intriguing. I was curious if anyone else had any experience with PowerShell and might share some of their findings??

Thanks in advance!

edit: here’s a video with some of the capabilities…

http://channel9.msdn.com/shows/The+DFO+Show/The-DFO-Show-Windows-Vista-and-Windows-PowerShell/

#2

一、忌超时加热：食品放入微波炉解冻或加热，若忘记取出，不锈钢板如果时间超过2小时，则应丢掉不要，以免引起食物中毒。 二、忌将普通塑料容器放入微波炉加热：一是热的食物会使容器变形，二是普通塑料会放出有毒物质，污染食物，危害人体健康。 三、忌将肉类加热至半熟后再用微波炉加热：因为在半熟的食品中细菌仍会生长，不锈钢管第二次再用微波炉加热时，由于时间短，不可能将细菌全杀死。冰冻肉类食品须先在微波炉中解冻，然后再加热为熟食。 四、忌使用金属器皿：因为放入炉内的铁、铝、不锈钢、搪瓷等金属器皿，微波炉在加热时会与之产生电火花并反射微波，既损伤炉体又做不熟食物。 五、忌再冷冻经微波炉解冻的肉类：因为肉类在微波炉中解冻后，实际上已将外面一层低温加热了，在此温度下细菌可以繁殖，虽再冷冻可使其繁殖停止，却不能将活菌杀死。已用微波炉解冻的肉类，如果再放入冰箱冷冻，必须加热至全熟。 六、忌使用封闭容器：加热液体时应使用阔口容器，不锈钢板因为在封闭容器内食物加热产生的热量不容易散发，使容器内压力过高，易引起喷爆事故。即使在煎煮带壳食物时，也要事先用针或筷子将壳膜刺破，以免加热后引起爆裂、飞溅弄脏炉壁。 七、忌使保鲜膜接触食物：使用保鲜薄膜时，在加热过程中最好不要让其直接接触食物，可将食物放入大碗底，用保鲜膜平封碗口或不用保鲜膜而直接用玻璃或瓷器盖住，这样也可将水汽封住，使加热迅速均匀。在取出食物前，可将保鲜膜刺破，以避免它黏到食物上。 八、忌油炸食品：因高温油会出现飞溅导致明火。如万一不慎引起炉内起火时，切忌开门，而应先关闭电源，待火熄灭后再开门降温。 九、忌将微炉置于卧室：同时应注意微波炉上的散热窗栅不要被物品覆盖。 十、忌长时间在微波炉前工作：开启微波炉后，不锈钢管 人应远离微波炉或人距离微波炉至少在1米之外。 有些朋友习惯把瓶装水倒在杯子里放入微波炉加热，用来沏茶。但是当把茶一放入杯中，杯子里的水就立即冒出大量的气泡，其中的水竟然突然沸腾起来，而且沸腾十分剧烈，杯子中90%的水都炸裂了出来，令人心惊胆战！ 这是杯子中有一部分水处于过热状态的缘故，也就是说，这部分水的温度实际上已经高过沸点，也就是高过在正常情况下应该变成水蒸气的温度。杯子里的水在微波炉中之所以没有沸腾，那是因为水中缺乏形成气泡的成核中心（凝结核）。 若用水壶烧水就不会出现这种现象，不锈钢板因为水壶有粗糙的内表面，而且有从壶底升起的热水搅动，这些都可以使水正常沸腾。液体内的湍流也能够加强形成气泡的成核过程，为了预防这种事情发生，用微波炉加热任何液体，加热后都必须让它在炉内静置至少一分钟，然后再开门动它。

#3

I was just wondering if there was anyone out there using PowerShell and thought I’d do a search.

I’ve been using it extensively for automation and tools specifically because cmd.exe is kind ancient and our game engine is all .net. I’ve been loving it.

#4

I just use it to automate things here for my development, it is nice.

#5

We settled on scripting host here. Downside for powershell - it’s an optional install for XP which just doesn’t work for us because artists need admin rights to install it and for that we have to call IT. Powershell is supposedly the successor for scripting host so it’s probably a great tool.

At least it beats writing batch scripts and it offers standard string and file manipulation commands. That alone is just awesome :slight_smile:

#6

I’ve read many blog posts about it and it seems pretty nifty. However I’d consider something like python/IronPython a more likely candidate for things we need to do in the TA role- I’m loathe to introduce yet more languages by choice, especially one outside of our traditional domain.

#7

We usually use this for tool deployment to artist machines as a super fail-safe method.

It would be awesome if we could use Python, but there’s some downsides to Python.
The correct python version needs to be installed on the target machine, and then it should be in the system path. If we want to query the x64 registry from python (e.g. to find out if Maya x64 is installed) then we actually need to launch the script from a x64 python installation. However some people have x86 python installed on x64 machines, or there are multiple Python installations on the machine… at this point things just get really complicated (at least more complicated than you want when just writing a simple tool deployment script!).
Compiling Python scripts with py2exe isn’t an option either since we still need separate x64 and x86 binaries. Also we rob ourselves of the ability to quickly change scripts on the go if needed.

I have to say we’re an outsourcer and the specs of our workstations vary WIDELY because some client’s tools require/only-work-with XP, Win7,x64,x86,etc. Some of our client’s tools have the bad habit of modifying the systems pretty heavily. So we always have to assume the worst when we deploy anything…

I haven’t tried powershell because we want something that ships with every windows version from XP up, but scripting host can be scripted in Visual Basic or Javascript. TAs pick up Javascript pretty quickly - even more so if they happened to work with Web apps or Unity before.

Right now we code the installation scripts in javascript. We copy files, query the registry, read .ini files, even create custom maya shelves all in javascript. Only UIs we do in Python because it’s easier for the TAs to code them there. Since the UI doesn’t do much it’s safe to just compile it with py2exe (so we don’t depend on an installed python interpreter) and call it from the javascript.

Finally the decision of what to use goes like this: we use scripting host where we would have used batch files in the past. We use scripting host if we cannot guarantee that python is installed on a machine. We use scripting host if we want the script to be x64 aware and capable of accessing win x64 specifics. Everything else -> python.

1 Like
#8

That’s not true. You can query either 32 or 64 bit registry hives from either 32 or 64 bit Python. You just have to explicitly specify one of these redirection flags:

KEY_WOW64_64KEY
KEY_WOW64_32KEY

Without that it will assume you want the hive that matches the architecture of the requesting program. See this MSDN page for more details.

Regarding Powershell, I’ve liked what I’ve seen and been meaning to use it more.

#9

We switch to the x86 hive and query the values we need, then we switch to the x64 hive and query the values we need, just as described. But when launched as 32 bit app the switching didn’t accomplish anything. In this case we got the x86 values twice. We had this issue in Python and later in scripting host (when launching via 32 bit cscript.exe on a 64 bit system). So it only worked when launched from x64.
Since we didn’t get any error messages and ran out of time we finally gave up on it :frowning:

We solved the problem going to scripting host (not just because of that, but it was a factor in the decision). It always executes in the bit depth matching your system.

Maybe there’s something wrong with our call to switch the hive, but it does work on x64… I have to admit I ran out of knowledge here.

Edit: also the registry is locked by IT on our system, so it just allows read-only access. Maybe that has something to do with it…