6 ms·

> On the other hand, if Windows had a proper shell and cli tools, like cygwin with zsh, but native and not Ubuntu layer inside - that would be tremendous. It i

> On the other hand, if Windows had a proper shell and cli tools, like cygwin with zsh, but native and not Ubuntu layer inside - that would be tremendous. It is PowerShell, and it really is. Until recently I thought Windows had poor CLI support, and I discovered PowerShell and now I favor it even more than bash. Am I crazy? Possibly, but PowerShell is truly a piece of gem in the CLI history. It is a thoughtfully crafted product regarding what "command-line interface" should look like.

Eun 10y ago
I am using WSL with success, it usualy gets the job done.
jrimbault 10y ago
But why is it that the PowerShell terminal emulator is (graphically) even worse than a tty ? I've worked on ttys more agreeable on the eyes than Windows terminal emulators. Windows is supposed to have better font support than Linux. Also, if someone here has an answer: Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason?
- SippinLean 10y ago
  Fair criticism, but PowerShell is just under the hood, most devs on Windows use cmder or similar.
  - jrimbault 10y ago
    Adding to that: I use ConEmu.
    - tracker1 10y ago
      +1 for conemu, though I wish the ux was closer to iterm2's
  - flukus 10y ago
    I stick with cygwin and tmux. I still find it easier to write scripts in bash than powershell.
- yokohummer7 10y ago
  It is not only ugly but also slow. One of the pain points while using PowerShell. It seems that Microsoft didn't care much about the emulator until recently. Thankfully things are changing, it was improved a bit in the Windows 10 anniversary update and Microsoft promised to improve it further. I'm optimistic about it.
- yokohummer7 10y ago
  > Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason? Windows' way of program executable placement is using the holy Registry. It's called 'Application Registration'[1] and was introduced to reduce the needs to modify the system-wide PATH variable. (They thought it was a bad idea to modify a system variable so frequently, and I partially agree.) You can find registered applications in `HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths`. Very few programs use that feature, which is unfortunate, but popular applications like Chrome and Firefox register themselves in it. That's why you can invoke `chrome` in the 'Run' dialog. Edit: Another context to add: at the time App Paths was added, to modify PATH you had to edit AUTOEXEC.BAT manually which was painful. Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2] [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ee8... [2] https://blogs.msdn.microsoft.com/oldnewthing/20110725-00/?p=10073 https://blogs.msdn.microsoft.com/oldnewthing/20110725-00/?p=...
  - e12e 10y ago
    Hm, interesting. I suppose this is what http://scoop.sh http://scoop.sh should be using? (The per-user setting, "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"). Oddly it appears the python2.7 installer uses this (global setting), but not the python3.x one (It would seem that python2 could register python.exe (as it currently does), and python3 could register python3.exe (as it currently does not)). It certainly doesn't seem to make much sense for python3 to have an option to add itself to the path environment variable, and an option to change the path length limit - but apparently not an option to use this "modern" way of registering itself? (Unless, python2 and python3 installers, when fighting it out, default to only registering python2... which makes sense, but is painful). But based on a windows hyper-v vm with only python3 installed, it looks like python3 does not use this setting.
  - MaulingMonkey 10y ago
    > Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2] I should note there are still length limits - in practice you'll run into issues with as few as 2047 characters: https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation https://support.microsoft.com/en-us/help/830473/command-prom... Debugging this is really annoying, as one of my coworkers found out when one too many applications decided to add multiple paths to PATH (for example, nVidia CodeWorks has added no less than 8 subdirectories of C:\NVPACK\ to PATH to support Android development - for gradle, ant, jdk, ndk, and the android SDK's support, build-tools, platform-tools, and regular tools.) Said coworker ended up spending some time using directory junctions to shorten the paths in PATH to the point where his dev environment was useful again.
- flukus 10y ago
  > Also, if someone here has an answer: Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason? This get's to the real issue of what makes powershell so horrible. It's not that anyone loves bash scripts, it's that there are a tonne of great utilities that bash script tie together. Windows doesn't have this.
Keyframe 10y ago
I made a wrong statement. PowerShell is a great shell! I want a shell and gnu chain from coreutils onwards within Windows. Babun takes me close, but not close enough. Namely it's slow as hell, 64-bit is no really there, and it's cygwin. I'm one of those "runs Vim and writes their own Makefiles and uses GCC and stuff like that doesn't like cygwin" guys.
- corndoge 10y ago
  Then why not run your favorite *nix and stick windows in a VM for the few applications that don't support Linux?
  - Keyframe 10y ago
    Great question. I use, all the time, applications which need full speed and full GPU support of which some are only on Linux and some are only on Windows and there's some overlap where most from both are on MacOS. Simple VM doesn't cut it, I've tried.
    - floatboth 10y ago
      What about the other way around, Windows host + *nix VMs? I run FreeBSD in VirtualBox, forwarding apps to VcXsrv via PuTTY. Works very well. I even made a tray icon script to launch that setup https://github.com/myfreeweb/xvmmgr/blob/master/xvmmgr.psm1 https://github.com/myfreeweb/xvmmgr/blob/master/xvmmgr.psm1 :)
- yokohummer7 10y ago
  I see. I'm also kinda a "runs Vim and writes Makefiles" guy, but I'm more hopeful about the Ubuntu layer being more seamlessly integrated into the native rather than waiting for Cygwin to improve. After all, WSL is official, and Microsoft seems to put a lot of efforts into it. As a side note, like you said, Cygwin is slow. I once measured how much time compiling things consumed on both Cygwin/MSYS2 and WSL. `./configure` was 3 times faster on WSL, and `make` was 2 times faster. I assume the reason to be WSL's process management being lighter. This is another reason I'm looking forward to see the improvements to WSL's native integration.
shadowmint 10y ago
It is a thoughtfully crafted product regarding what "command-line interface" should look like. How so? I've never appreciated what's actually good about powershell... you pass objects around? So...? Is that a thing that's useful? If you want to just automate a task, having intermediate objects that are serializable (eg. strings) so you can `foo ... > blah` and inspect the value of blah before continuing (`cat blah | command2...`) has always seemed far more tangibly useful. Having methods on an object you can invoke like a REPL for the OS sounds like a good idea, but I've never actually found it useful; its like the python REPL; useful for prototyping and doing stuff after you've imported the 50 packages and setup all of the environment, but once you open a new instance, you've got to spend the time doing that before you can actually do any work; and its useless for scripting. ...but, powershell gets a lot of love from people; so what do you actually find it useful for? Honestly curious, I've only ever touched it briefly and then swapped over to other things.
- HelloNurse 10y ago
  I'm using a large corpus of Powershell scripts, mostly written by enthusiastic Microsoft consultants, and even if I know exactly what they do I cannot stand the mysterious imports, the sequences of script invocations and bare statements that leave the session with the desired invisible state (and, conversely, closing and reopening the session after every major command just in case), the automagical option handling, and so on.
  - Karrot_Kream 10y ago
    To play devil's advocate, UNIX sh shell scripts are pretty mysterious too, and often leave the local environment polluted and other such no-nos.
    - HelloNurse 10y ago
      Environment variables (and files) are very easy to inspect and change, the invisible bunch of objects in a Powershell session are not.
  - 10y ago
rconti 10y ago
Maybe it's great for Windows, but it's not great for working on Unix machines, which many of us do. I'd be more open to Windows if trying to manage Unix boxes from it wasn't like trying to build a ship in a bottle. I always feel like I have one hand tied behind my back trying to do my job in Windows. For simple web browsing and office work and such, it's fine.
stinos 10y ago
I discovered PowerShell and now I favor it even more than bash Same here. Might be biased because I never completely mastered bash as I don't use it that much. But after the first bit of the learning curve is over the rest just seems to go automatically with seemingly way less searching the internet: things are just easier to discover and figure out by yourself, and that also makes it easier to remember them. Plus you can visually debug it. Also some of the bash things I'm addicted to (autojump and fzf) have some pretty good clones for PS, namely ZLocation and PSFzf, those are real timesavers for navigation/history search for me.
city41 10y ago
But powershell is an all or nothing proposition. At my job, the majority use OSX. I use Linux. Since we all use bash, there's very little friction here. I can't "just use powershell" in this scenario at all.
- tintoy 10y ago
  Actually that's changing - PowerShell Core works anywhere .NET Core does (including OSX and Linux). https://github.com/PowerShell/PowerShell#-powershell https://github.com/PowerShell/PowerShell#-powershell (although that doesn't account for personal preference, of course)
  - city41 10y ago
    That does help, and is welcome. But convincing a team to switch something as fundamental as their shell is an uphill battle. I'm sure PowerShell is great (I've never used it), but shells always struck me as the kind of thing where "good enough is good enough".
nikdaheratik 10y ago
PowerShell is very serviceable, but it has weird points of failure. Especially with some FOSS projects that seem to think cmd is the furthest they will go as far as Windows support, then they completely choke on powershell. I think if I liked the rest of the .Net toolkit more, I'd be more enthused about it. It makes things livable on Windows, which is better than the dark days of Vista/7.
thomastjeffery 10y ago
Powershell may be good (I wouldn't know), but the terminal emulator (cmd) is absolute garbage. Even in Windows 10, you still have to edit the registry just to use a decent font, There isn't a reasonable way to change the colors, &c. I honestly can't tell what has changed in cmd since Windows NT. Sure, there has not been much progress with terminal emulators in the past couple decades, but in Windows there has literally been none at all.

Eun 10y ago

I am using WSL with success, it usualy gets the job done.

jrimbault 10y ago

But why is it that the PowerShell terminal emulator is (graphically) even worse than a tty ? I've worked on ttys more agreeable on the eyes than Windows terminal emulators. Windows is supposed to have better font support than Linux. Also, if someone here has an answer: Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason?

SippinLean 10y ago
Fair criticism, but PowerShell is just under the hood, most devs on Windows use cmder or similar.
- jrimbault 10y ago
  Adding to that: I use ConEmu.
  - tracker1 10y ago
    +1 for conemu, though I wish the ux was closer to iterm2's
- flukus 10y ago
  I stick with cygwin and tmux. I still find it easier to write scripts in bash than powershell.
yokohummer7 10y ago
It is not only ugly but also slow. One of the pain points while using PowerShell. It seems that Microsoft didn't care much about the emulator until recently. Thankfully things are changing, it was improved a bit in the Windows 10 anniversary update and Microsoft promised to improve it further. I'm optimistic about it.
yokohummer7 10y ago
> Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason? Windows' way of program executable placement is using the holy Registry. It's called 'Application Registration'[1] and was introduced to reduce the needs to modify the system-wide PATH variable. (They thought it was a bad idea to modify a system variable so frequently, and I partially agree.) You can find registered applications in `HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths`. Very few programs use that feature, which is unfortunate, but popular applications like Chrome and Firefox register themselves in it. That's why you can invoke `chrome` in the 'Run' dialog. Edit: Another context to add: at the time App Paths was added, to modify PATH you had to edit AUTOEXEC.BAT manually which was painful. Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2] [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ee8... [2] https://blogs.msdn.microsoft.com/oldnewthing/20110725-00/?p=10073 https://blogs.msdn.microsoft.com/oldnewthing/20110725-00/?p=...
- e12e 10y ago
  Hm, interesting. I suppose this is what http://scoop.sh http://scoop.sh should be using? (The per-user setting, "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"). Oddly it appears the python2.7 installer uses this (global setting), but not the python3.x one (It would seem that python2 could register python.exe (as it currently does), and python3 could register python3.exe (as it currently does not)). It certainly doesn't seem to make much sense for python3 to have an option to add itself to the path environment variable, and an option to change the path length limit - but apparently not an option to use this "modern" way of registering itself? (Unless, python2 and python3 installers, when fighting it out, default to only registering python2... which makes sense, but is painful). But based on a windows hyper-v vm with only python3 installed, it looks like python3 does not use this setting.
- MaulingMonkey 10y ago
  > Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2] I should note there are still length limits - in practice you'll run into issues with as few as 2047 characters: https://support.microsoft.com/en-us/help/830473/command-prompt-cmd.-exe-command-line-string-limitation https://support.microsoft.com/en-us/help/830473/command-prom... Debugging this is really annoying, as one of my coworkers found out when one too many applications decided to add multiple paths to PATH (for example, nVidia CodeWorks has added no less than 8 subdirectories of C:\NVPACK\ to PATH to support Android development - for gradle, ant, jdk, ndk, and the android SDK's support, build-tools, platform-tools, and regular tools.) Said coworker ended up spending some time using directory junctions to shorten the paths in PATH to the point where his dev environment was useful again.
flukus 10y ago
> Also, if someone here has an answer: Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason? This get's to the real issue of what makes powershell so horrible. It's not that anyone loves bash scripts, it's that there are a tonne of great utilities that bash script tie together. Windows doesn't have this.

Keyframe 10y ago

I made a wrong statement. PowerShell is a great shell! I want a shell and gnu chain from coreutils onwards within Windows. Babun takes me close, but not close enough. Namely it's slow as hell, 64-bit is no really there, and it's cygwin. I'm one of those "runs Vim and writes their own Makefiles and uses GCC and stuff like that doesn't like cygwin" guys.

corndoge 10y ago
Then why not run your favorite *nix and stick windows in a VM for the few applications that don't support Linux?
- Keyframe 10y ago
  Great question. I use, all the time, applications which need full speed and full GPU support of which some are only on Linux and some are only on Windows and there's some overlap where most from both are on MacOS. Simple VM doesn't cut it, I've tried.
  - floatboth 10y ago
    What about the other way around, Windows host + *nix VMs? I run FreeBSD in VirtualBox, forwarding apps to VcXsrv via PuTTY. Works very well. I even made a tray icon script to launch that setup https://github.com/myfreeweb/xvmmgr/blob/master/xvmmgr.psm1 https://github.com/myfreeweb/xvmmgr/blob/master/xvmmgr.psm1 :)
yokohummer7 10y ago
I see. I'm also kinda a "runs Vim and writes Makefiles" guy, but I'm more hopeful about the Ubuntu layer being more seamlessly integrated into the native rather than waiting for Cygwin to improve. After all, WSL is official, and Microsoft seems to put a lot of efforts into it. As a side note, like you said, Cygwin is slow. I once measured how much time compiling things consumed on both Cygwin/MSYS2 and WSL. `./configure` was 3 times faster on WSL, and `make` was 2 times faster. I assume the reason to be WSL's process management being lighter. This is another reason I'm looking forward to see the improvements to WSL's native integration.

shadowmint 10y ago

It is a thoughtfully crafted product regarding what "command-line interface" should look like. How so? I've never appreciated what's actually good about powershell... you pass objects around? So...? Is that a thing that's useful? If you want to just automate a task, having intermediate objects that are serializable (eg. strings) so you can `foo ... > blah` and inspect the value of blah before continuing (`cat blah | command2...`) has always seemed far more tangibly useful. Having methods on an object you can invoke like a REPL for the OS sounds like a good idea, but I've never actually found it useful; its like the python REPL; useful for prototyping and doing stuff after you've imported the 50 packages and setup all of the environment, but once you open a new instance, you've got to spend the time doing that before you can actually do any work; and its useless for scripting. ...but, powershell gets a lot of love from people; so what do you actually find it useful for? Honestly curious, I've only ever touched it briefly and then swapped over to other things.

HelloNurse 10y ago
I'm using a large corpus of Powershell scripts, mostly written by enthusiastic Microsoft consultants, and even if I know exactly what they do I cannot stand the mysterious imports, the sequences of script invocations and bare statements that leave the session with the desired invisible state (and, conversely, closing and reopening the session after every major command just in case), the automagical option handling, and so on.
- Karrot_Kream 10y ago
  To play devil's advocate, UNIX sh shell scripts are pretty mysterious too, and often leave the local environment polluted and other such no-nos.
  - HelloNurse 10y ago
    Environment variables (and files) are very easy to inspect and change, the invisible bunch of objects in a Powershell session are not.
- 10y ago

rconti 10y ago

Maybe it's great for Windows, but it's not great for working on Unix machines, which many of us do. I'd be more open to Windows if trying to manage Unix boxes from it wasn't like trying to build a ship in a bottle. I always feel like I have one hand tied behind my back trying to do my job in Windows. For simple web browsing and office work and such, it's fine.

stinos 10y ago

I discovered PowerShell and now I favor it even more than bash Same here. Might be biased because I never completely mastered bash as I don't use it that much. But after the first bit of the learning curve is over the rest just seems to go automatically with seemingly way less searching the internet: things are just easier to discover and figure out by yourself, and that also makes it easier to remember them. Plus you can visually debug it. Also some of the bash things I'm addicted to (autojump and fzf) have some pretty good clones for PS, namely ZLocation and PSFzf, those are real timesavers for navigation/history search for me.

city41 10y ago

But powershell is an all or nothing proposition. At my job, the majority use OSX. I use Linux. Since we all use bash, there's very little friction here. I can't "just use powershell" in this scenario at all.

tintoy 10y ago
Actually that's changing - PowerShell Core works anywhere .NET Core does (including OSX and Linux). https://github.com/PowerShell/PowerShell#-powershell https://github.com/PowerShell/PowerShell#-powershell (although that doesn't account for personal preference, of course)
- city41 10y ago
  That does help, and is welcome. But convincing a team to switch something as fundamental as their shell is an uphill battle. I'm sure PowerShell is great (I've never used it), but shells always struck me as the kind of thing where "good enough is good enough".

nikdaheratik 10y ago

PowerShell is very serviceable, but it has weird points of failure. Especially with some FOSS projects that seem to think cmd is the furthest they will go as far as Windows support, then they completely choke on powershell. I think if I liked the rest of the .Net toolkit more, I'd be more enthused about it. It makes things livable on Windows, which is better than the dark days of Vista/7.

thomastjeffery 10y ago

Powershell may be good (I wouldn't know), but the terminal emulator (cmd) is absolute garbage. Even in Windows 10, you still have to edit the registry just to use a decent font, There isn't a reasonable way to change the colors, &c. I honestly can't tell what has changed in cmd since Windows NT. Sure, there has not been much progress with terminal emulators in the past couple decades, but in Windows there has literally been none at all.