7 ms·

I'm not a ssh expert (I live in the MS world), but powershell remote sessions (PSSession) seems like what you are talking about here... it's like running in a p

I'm not a ssh expert (I live in the MS world), but powershell remote sessions (PSSession) seems like what you are talking about here... it's like running in a powershell window on a remote machine.

emn13 12y ago
I'm not too confident powershell is really good enough to compete with the ancient unix shell. I've tried using it to automate windows machines, but it's certainly not a smooth experience. Part of that is the lack of a history of automation - basic things to do with processes and I/O are kind of schizophrenic. All of the basics are clearly unix inspired (standard streams, processes, redirection - this is all unix-like), but many windows tools use different conventions to exchange data and control channels - powershell has a real object model. In principle powershell's richer object model is a boon to automation - it's so much easier not to make mistakes if you don't need to massage your data through lots of slightly different text-based hacks, but the object model just isn't nearly pervasive enough. Sometimes you still need plain text/binary streams, and the transition isn't great. More fundamentally, the object model isn't well thought out - it's built on .NET, but that's clearly a single-process focused world view, and for a inter-process management tool, that poses problems. Even if sending objects between processes would work smoothly, there's the issue that objects don't compose or reflect as smoothly as text. It's hard to put your finger on, but for example, you can use things like regex's to do fairly fancy pattern matching on strings, and the equivalent for objects just isn't there in powershell. As a result, things work great if you're doing something that the underlying processes "want" you to do - but if you're trying to hack around some limitation, or try something novel, it's much more painful than in bash. I think it's also worth mentioning some practical problems: Powershell is really slow and heavy. You can cheaply pipe and juggle data in a unix shell, but by doing that in powershell I've seen machines grind to a halt. A fresh powershell instance has a working set of 100MB on my machine; bash: 5MB. That's a problem. Startup time, similarly, is slow. This isn't a problem if you're working purely interactively - no human is going to notice an extra 10ms here or there, but in scripting, you can easily start so many processes that the difference becomes very noticable. Powershell isn't terrible, but it just doesn't work as well as the unix shell, despite all the warts that has. Maybe some day everything will speak powershell, and it'll faster, smaller, and have a better story concerning pattern matching, but right now it's relatively ineffective compared to a plain unix shell, in my experience (which is windows centric).
- tracker1 12y ago
  Agreed on most of your points... PowerShell is by far the most powerful shell I've ever worked with on any platform... that said, I don't like it. It's very verbose. As a JS guy, these days most of my scripts run via node/iojs and are as platform agnostic as possible. More and more I know it only needs to run in linux, or is guiding dockerization. Even then, bash scripts tend to be easier to reason about.
  - dragontamer 12y ago
    You could always write JScript. Ha ha ha! http://blog.idleworx.com/2010/01/windows-scripting-host-and-javascript.html http://blog.idleworx.com/2010/01/windows-scripting-host-and-... I've seen a few open-source projects actually use this. (IIRC, it was WiX)
    - tracker1 12y ago
      Actually, I did do a bit of JScript WSH scripts back in the day, well before PowerShell was an option even. IT works relatively well... I even shoved some initial logic into a few of my node scripts for windows that would, if run from WSH relaunch themselves in node. The biggest issue with JScript in general is probably the lack of open options for certain classes of COM controls, that and COM collections are a beast (the enumeration wrapper you need in JScript is horrible). JScript was my preference just the same back with Classic ASP scripts. Could re-use my logic client and server-side, which usually worked out pretty well... though almost everybody used VBScript, which usually meant in a project both engines were loaded on the server. The other issue was runtime initialization for every request meant you were somewhat limited, though for a couple hundred users on a system at once around 1999-2002, it wasn't bad.
- nimish 12y ago
  PowerShell is far more usable than sh or even bash as a scripting language. It's more like perl or python were integrated into a nice little command processor, since you can use all the .net libs (though not without some irritating effort). The problem is the cmd host is garbage, the utilities aren't burned into people's brains like the unix ones are, and they have weird Windows specific issues, like not being able to fork off a subprocess.

I'm not a ssh expert (I live in the MS world), but powershell remote sessions (PSSession) seems like what you are talking about here... it's like running in a powershell window on a remote machine.

emn13 12y ago

I'm not too confident powershell is really good enough to compete with the ancient unix shell. I've tried using it to automate windows machines, but it's certainly not a smooth experience. Part of that is the lack of a history of automation - basic things to do with processes and I/O are kind of schizophrenic. All of the basics are clearly unix inspired (standard streams, processes, redirection - this is all unix-like), but many windows tools use different conventions to exchange data and control channels - powershell has a real object model. In principle powershell's richer object model is a boon to automation - it's so much easier not to make mistakes if you don't need to massage your data through lots of slightly different text-based hacks, but the object model just isn't nearly pervasive enough. Sometimes you still need plain text/binary streams, and the transition isn't great. More fundamentally, the object model isn't well thought out - it's built on .NET, but that's clearly a single-process focused world view, and for a inter-process management tool, that poses problems. Even if sending objects between processes would work smoothly, there's the issue that objects don't compose or reflect as smoothly as text. It's hard to put your finger on, but for example, you can use things like regex's to do fairly fancy pattern matching on strings, and the equivalent for objects just isn't there in powershell. As a result, things work great if you're doing something that the underlying processes "want" you to do - but if you're trying to hack around some limitation, or try something novel, it's much more painful than in bash. I think it's also worth mentioning some practical problems: Powershell is really slow and heavy. You can cheaply pipe and juggle data in a unix shell, but by doing that in powershell I've seen machines grind to a halt. A fresh powershell instance has a working set of 100MB on my machine; bash: 5MB. That's a problem. Startup time, similarly, is slow. This isn't a problem if you're working purely interactively - no human is going to notice an extra 10ms here or there, but in scripting, you can easily start so many processes that the difference becomes very noticable. Powershell isn't terrible, but it just doesn't work as well as the unix shell, despite all the warts that has. Maybe some day everything will speak powershell, and it'll faster, smaller, and have a better story concerning pattern matching, but right now it's relatively ineffective compared to a plain unix shell, in my experience (which is windows centric).

tracker1 12y ago
Agreed on most of your points... PowerShell is by far the most powerful shell I've ever worked with on any platform... that said, I don't like it. It's very verbose. As a JS guy, these days most of my scripts run via node/iojs and are as platform agnostic as possible. More and more I know it only needs to run in linux, or is guiding dockerization. Even then, bash scripts tend to be easier to reason about.
- dragontamer 12y ago
  You could always write JScript. Ha ha ha! http://blog.idleworx.com/2010/01/windows-scripting-host-and-javascript.html http://blog.idleworx.com/2010/01/windows-scripting-host-and-... I've seen a few open-source projects actually use this. (IIRC, it was WiX)
  - tracker1 12y ago
    Actually, I did do a bit of JScript WSH scripts back in the day, well before PowerShell was an option even. IT works relatively well... I even shoved some initial logic into a few of my node scripts for windows that would, if run from WSH relaunch themselves in node. The biggest issue with JScript in general is probably the lack of open options for certain classes of COM controls, that and COM collections are a beast (the enumeration wrapper you need in JScript is horrible). JScript was my preference just the same back with Classic ASP scripts. Could re-use my logic client and server-side, which usually worked out pretty well... though almost everybody used VBScript, which usually meant in a project both engines were loaded on the server. The other issue was runtime initialization for every request meant you were somewhat limited, though for a couple hundred users on a system at once around 1999-2002, it wasn't bad.
nimish 12y ago
PowerShell is far more usable than sh or even bash as a scripting language. It's more like perl or python were integrated into a nice little command processor, since you can use all the .net libs (though not without some irritating effort). The problem is the cmd host is garbage, the utilities aren't burned into people's brains like the unix ones are, and they have weird Windows specific issues, like not being able to fork off a subprocess.