4 ms·

What is Mac Pro's shell? You mean your shell on OS X? And what did you find so bad with Powershell?

kabdib 13y ago
The "terminal" on MacOS X. It has: - tabs - cut and paste that actually works - various ways to focus windows - hey, search! ... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in 1982 or so. Yeah, I know you can buy more whizzy shells. But MS really has no excuse for letting the NT console system rot as much as it has. Given that their programmers use it /all the time/, I find it hard to believe that someone hasn't written something better. (PowerShell overshot the mark, and wound up being unusable).
- yuhong 13y ago
  I think CONHOST/CSRSS is to blame for this not CMD.
  - kabdib 13y ago
    As far as I can tell, they're joined at the hip. You /could/ redo one without redoing the other. No problem. But the result would be poor. :-/
- msie 13y ago
  Aside from good cut&paste behaviour, one of the biggest problems with cmd.exe is you cannot resize the window horizontally larger than its set size by dragging on the window side. I do this when I see wrapped text from the output of a command. And if you experience wrapped text in a window smaller than its max size, enlarging the window doesn't reflow the text! Oh I see the same problem happens in Powershell too. :-(
  - to3m 13y ago
    Powershell and the command prompt use the same underlying console subsystem, that handles character-mode programs running and displaying their output in a window. It's a core part of Windows, rather than something supplied by each program. The console system doesn't provide a TTY, as in Unix, but instead uses a CGA/MDA text mode metaphor: a matrix of (character,colour) pairs. This leaves no information about the text that's been printed, per se - it's more like the text equivalent of a bitmap. No carriage returns, no tabs, just an arrangement of characters that happened to have been put in the right places. If you widen the screen, there's not much Windows can do except for leave the new area blank, because it has no idea at all which line breaks are significant and which were just wrapped. (And indeed, if you resize the buffer in the console window's properties, this blanking is exactly what it does.) There's sort-of nothing wrong with this system, in that it makes sense for a certain style of text-mode GUI console program, that were at one point exceedingly popular in MS-DOS - but unfortunately, it's not so hot for the TTY style of console program that everybody uses these days :) (Fingers crossed for a much-needed shakeup, but this nonsense has stuck around for so long - I don't think that console properties dialog has changed one pixel since Windows NT 4 - that it's probably a bit late now. Meanwhile, one solution might be to run cmd.exe with a better class of terminal emulator - emacs will do this.)
- derleth 13y ago
  So it isn't a shell. It's more like xterm, then, right?
  - wiml 13y ago
    Yes. In fact it's called Terminal.app; it's just a terminal emulator, but one that doesn't particularly suck. The shell is ordinary bash (or ksh or zsh or whatever; I forget what the default is).
- p4bl0 13y ago
  You are mixing the shell and the terminal. (But you're probably right that neither of them is good on Windows.)
- manojlds 13y ago
  So all your complaints are against the terminal emulator, which everyone agrees is bad. Use something like ConEmu. Here's Scott Hanselman on ConEmu - http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsolePromptWeveBeenWaitingFor.aspx http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol... > PowerShell overshot the mark, and wound up being unusable You haven't still any points against Powershell and continue to pile up on it.
  - eropple 13y ago
    ConEmu can't fully replicate the CSRSS terminal behavior. It breaks pretty grossly when using advanced console functionality that works correctly in CSRSS's own terminal.

The "terminal" on MacOS X. It has: - tabs - cut and paste that actually works - various ways to focus windows - hey, search! ... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in 1982 or so. Yeah, I know you can buy more whizzy shells. But MS really has no excuse for letting the NT console system rot as much as it has. Given that their programmers use it /all the time/, I find it hard to believe that someone hasn't written something better. (PowerShell overshot the mark, and wound up being unusable).

yuhong 13y ago
I think CONHOST/CSRSS is to blame for this not CMD.
- kabdib 13y ago
  As far as I can tell, they're joined at the hip. You /could/ redo one without redoing the other. No problem. But the result would be poor. :-/
msie 13y ago
Aside from good cut&paste behaviour, one of the biggest problems with cmd.exe is you cannot resize the window horizontally larger than its set size by dragging on the window side. I do this when I see wrapped text from the output of a command. And if you experience wrapped text in a window smaller than its max size, enlarging the window doesn't reflow the text! Oh I see the same problem happens in Powershell too. :-(
- to3m 13y ago
  Powershell and the command prompt use the same underlying console subsystem, that handles character-mode programs running and displaying their output in a window. It's a core part of Windows, rather than something supplied by each program. The console system doesn't provide a TTY, as in Unix, but instead uses a CGA/MDA text mode metaphor: a matrix of (character,colour) pairs. This leaves no information about the text that's been printed, per se - it's more like the text equivalent of a bitmap. No carriage returns, no tabs, just an arrangement of characters that happened to have been put in the right places. If you widen the screen, there's not much Windows can do except for leave the new area blank, because it has no idea at all which line breaks are significant and which were just wrapped. (And indeed, if you resize the buffer in the console window's properties, this blanking is exactly what it does.) There's sort-of nothing wrong with this system, in that it makes sense for a certain style of text-mode GUI console program, that were at one point exceedingly popular in MS-DOS - but unfortunately, it's not so hot for the TTY style of console program that everybody uses these days :) (Fingers crossed for a much-needed shakeup, but this nonsense has stuck around for so long - I don't think that console properties dialog has changed one pixel since Windows NT 4 - that it's probably a bit late now. Meanwhile, one solution might be to run cmd.exe with a better class of terminal emulator - emacs will do this.)
derleth 13y ago
So it isn't a shell. It's more like xterm, then, right?
- wiml 13y ago
  Yes. In fact it's called Terminal.app; it's just a terminal emulator, but one that doesn't particularly suck. The shell is ordinary bash (or ksh or zsh or whatever; I forget what the default is).
p4bl0 13y ago
You are mixing the shell and the terminal. (But you're probably right that neither of them is good on Windows.)
manojlds 13y ago
So all your complaints are against the terminal emulator, which everyone agrees is bad. Use something like ConEmu. Here's Scott Hanselman on ConEmu - http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsolePromptWeveBeenWaitingFor.aspx http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol... > PowerShell overshot the mark, and wound up being unusable You haven't still any points against Powershell and continue to pile up on it.
- eropple 13y ago
  ConEmu can't fully replicate the CSRSS terminal behavior. It breaks pretty grossly when using advanced console functionality that works correctly in CSRSS's own terminal.