9 ms·

I've used Linux for a decade-and-a-half, but I've never totally loved the shell, because of the need to learn this sort of pointless arcana. PowerShell was a ma

by sjellis 10y ago

I've used Linux for a decade-and-a-half, but I've never totally loved the shell, because of the need to learn this sort of pointless arcana. PowerShell was a massive step forward, and I had hoped that an Open Source, cross-platform equivalent would develop so that we could get past the current local maxima of 1970s-era design. It's rather weird that the Open Source equivalent of PowerShell is now...PowerShell. Even if you don't like Microsoft or .NET, if you care about shells I'd recommend trying out PowerShell Core for an hour or two. It's only when you use it for a bit that you start to realize that you can guess commands based on the rules and actually be right and how big an improvement that actually is, rather than the current UNIX method of having to memorize more and more obscure trivia in order to get the computer to do what you want. I'm not sure if PowerShell itself is a long-term answer because of the .NET and Microsoft dependencies, but it gets lot of things right. It's time we dropped the "Bash is good enough" arguments. There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny.

rollthehard6 10y ago
I dunno, I'm a long term *NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now) I am now involved in more Powershell scripting on Windows than I have ever done before. I don't see - Get-Content -Tail 10 FILE as an improvement on - tail -10 FILE I think when it comes to the combination of intuitive command names and terseness when required, VMS' DCL is still unsurpassed. Having commands with sensible names that can the be shortened and a really useable HELP system was a major plus and I've not seen anything match that since.
- CJefferson 10y ago
  To me, the main advantage of Powershell is filename handling. I know that if I do everything just right, then my scripts will handle filenames with spaces/newlines/other crazy characters, but I always mess up somehow. Nowadays if I ever want a script I'll distribute to people who might have spaces in directories, I write it in python even if it would be a 4 line bash script, just to avoid the issue.
  - dijit 10y ago
    I've never really had a problem with spaces in path names. You should be quoting variables when they're used though, there is a shell style guide put out by google that deals with this stuff. https://google.github.io/styleguide/shell.xml?showone=Quoting#Quoting https://google.github.io/styleguide/shell.xml?showone=Quotin...
- sjellis 10y ago
  Well, once you know that PowerShell uses the verb "Get" for fetching data, and the noun "Content" for file contents then those are reusable bits of knowledge that slot together with other verbs and nouns. It's easy to hold in your head and build your knowledge over time, and better yet, the third-party add-ons obey the common conventions, so you can experiment with confidence. When you learn the *NIX command-line from scratch, everything is special cases, so the whole experience is peering at man pages and slowly rote-learning commands and options. The only commonality is that if you try to guess, you'll probably be wrong. My patience with the philosophy of independent tools hit breaking point a while ago, when I had to start learning the different CLI tools from rival cloud providers - so much to learn, and no consistency at all.
  - pjc50 10y ago
    I think this is one of those "familiarity" and "expectation" issues that are very subjective. Rather like python's divisive significant whitespace. I've tried to like powershell, but when I wanted "grep" I ended up having to do: Select-String "str" -Path foo.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt .. because it has broken defaults such as truncating output to terminal width even when written to a file. Then there's the weirdness around enabling script execution (rather more complicated than +x) and the remote execution system is much stranger than ssh.
    - sjellis 10y ago
      My first brushes with PowerShell were deeply frustrating, because I kept trying to write things the way that I expected them to work (from Bash). After a while I gave in and sat through a tutorial, and found that once I did things the way PowerShell wanted, I found it enjoyable to work with. That's just my personal experience. FWIW, the script execution thing was dropped for the latest versions of Windows, and PowerShell Core (thankfully). I agree that the remoting is not much fun - SSH for Windows is currently due in October, so I presume that PowerShell will get SSH support around then.
- xg15 10y ago
  > I dunno, I'm a long term NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now) But I think this is the point. PowerShell (or the spirit of it) would be more useful for new users because they don't need to spend time memorizing every single command and can start being productive earlier. It probably makes less of a difference if the commands are already part of your muscle memory. Though to be fair, CMD is a lot more quirky and inconsistent than modern bash. So before the advent of PowerShell, I think you could have made the same argument on favor of ...nix and against windows.
slavik81 10y ago
Using powershell left a really sour taste in my mouth. I felt I was promised that objects and types would prevent errors, but it just feels like everything is harder and mistakes are just as easy. For example, 'diff (cat a.txt) (cat b.txt)' does something very different from what you'd expect, but works OK for most inputs. The perfect combination for putting bugs into production. I still like that powershell exists. Especially on Windows where they needed it most. On Linux, though, I'd rather stick with the devil I know.
mastazi 10y ago
> I've never totally loved the shell I don't understand your point, PowerShell is a shell too, just like Bash or Zsh. When you call less, more or any other tool from Powershell, you still retain all the problems that are mentioned in the article. I think the article was focusing more on the ecosystem than anything.
- sjellis 10y ago
  The ecosystem creates problems that don't exist with PowerShell, which is more like a cross-platform programming language that sits above the OS than the traditional *NIX arrangement of an OS-specific collection of a shell (with some built-ins) plus a grab-bag of third-party tools. Like Python, Node.js etc., PowerShell has one development team that will now be delivering one implementation across all of the operating systems. There's a packaging system included, so that third-party modules can also be uniformly deployed. The first-party and third-party stuff all has to follow the same rules and end up as modules in the same PowerShell installations, which avoids the long-running inconsistencies between tools, like man vs. info and different styles of option parsing. At the moment, different versions of Windows do ship with different versions of PowerShell, which is annoying, but it's the same product and you can install new PowerShell versions on older systems to get a consistent environment across your machines.
  - fps 10y ago
    The UNIX philosophy of "do one thing, well" and "write many programs that work together" is contrary to powershell's idea of having all the tools you need as built-ins to your shell. The minute you need something that the "one development team" hadn't thought of, or decided wasn't important enough to ship, you have to either port it to powershell as a plugin or write something more complex to handle your workflow. For all it's cruft and baggage, the fact that there's not "one way to do things" and is continually expandable is part of what endears UNIX to it's users.
    - sjellis 10y ago
      The fact that PowerShell needs modules to fully work with something is definitely an issue - we'll have to see whether people start writing the modules to make PowerShell fully functional on *NIX. You can call existing command-line tools, or methods from the underlying .NET Core installation, but those are really just work-arounds. To be fair, every programming or automation platform has that issue: Python and Ansible succeeded because people did like the basic systems enough to write code to extend their usefulness.
bechampion 10y ago
doing simple "df" "du" "find -exec" it still complex/verbose TODAY using powershell , I find disgusting that you compare bash to powershell (I'm not even talking about speed)
- bechampion 10y ago
  even tho the commands mentioned above aren't bash built-ins
chriswarbo 10y ago
> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny. I think the article was more critical of commercial Unix vendors than Linux. From the article: > Oddly, FreeBSD has done the most sensible thing; they've outright replaced more with less. There is a /usr/bin/more but it's the same binary as less and as you can see the more manpage is just the less manpage. OpenBSD has done the same thing but has a specific manpage for more instead of just giving you the less manpage. > On Linux, more is part of the util-linux package but its manpage outright tells you to use less instead The Free/OpenBSD choice seems sensible; presumably there are Linux distros which do the same. I imagine that if, say, Ubuntu or Debian makes a choice like this, it would propagate quite quickly to other distros; it would presumably be less of a breaking change than switching /bin/sh from bash to dash. > It's time we dropped the "Bash is good enough" arguments. I've rarely heard anyone claim "Bash is good enough". I do agree with the argument that bash is overused, and anything more than a trivial script should be done in a "proper" language (e.g. Python, which is installed by default on pretty much all Linux distros and OSX). I'm not sure if there's a clear winner(s) for interactive use (i.e. a pareto improvement). Many use zsh, but I don't think it goes far enough. More radical alternatives like fish, ipython, etc. seem too fragmented at the moment. Maybe there needs to be momentum from a high-profile distro shipping such a shell as its default (while maintaining /bin/sh, /usr/bin/env bash, etc. for compatibility with existing scripts)
- sjellis 10y ago
  After using Xonsh and PowerShell, I'd be pretty happy if a Linux distribution did break from the pack and ship a radical alternative as the default, with a legacy bash installation as you describe. Incremental changes probably won't spread uniformly - when Ubuntu switched to dash, the Fedora developers explicitly decided that they would not ship dash and would continue with bash, because they have to maintain total compatibility. In discussions of the new PowerShell release I've seen quite a few comments that boil down to "PowerShell is fine for Windows, but we don't need it on Linux", and I feel that, yeah, we do need a much better shell because what we have is nowhere near the best that can be done. Everybody that's used *NIX for a long period of time has to adapt to the classic shell way of doing things, but we shouldn't be pushing this mess on the next generation.
NoGravitas 10y ago
I kind of feel like Linux people have gotten used to using Python (or similar?) for anything that is complex enough that shell is not enough. Which is also not perfectly suited to the domain, but enough that learning a third thing to do sysadmin-type scripting is not appealing.
Twirrim 10y ago
> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny. When do you even need to tell them this? Does it fundamentally change how they use the tool somehow? No, they'll see that you pipe stuff through less and that's it. Heck, I've been using Linux for 15+ years, and about 10 of those full time. The first I ever heard that "less is more" was probably ~3 years ago. It just doesn't matter. What you're complaining about is esoteria (that is still littered all over the Windows ecosystem, e.g. the fingerprints of 8.3 file names still persist, long after it ceased to be a thing)
- sjellis 10y ago
  The Linux command-line experience is mostly composed of esoterica, and less vs. more is actually one of the least bad of a thousand paper cuts. I just couldn't resist taking a dig at the pun. One thing that this thread has really brought into focus for me is that we treat the *NIX shells differently, because we are used to them, but IMO we ought to hold the shell to the same standards that we'd apply to any programming environment. If a new programming language with a REPL shipped today that was the quality of the shell experience that we've currently got, we'd think that it was ridiculous.

by sjellis 10y ago

rollthehard6 10y ago

I dunno, I'm a long term *NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now) I am now involved in more Powershell scripting on Windows than I have ever done before. I don't see - Get-Content -Tail 10 FILE as an improvement on - tail -10 FILE I think when it comes to the combination of intuitive command names and terseness when required, VMS' DCL is still unsurpassed. Having commands with sensible names that can the be shortened and a really useable HELP system was a major plus and I've not seen anything match that since.

CJefferson 10y ago
To me, the main advantage of Powershell is filename handling. I know that if I do everything just right, then my scripts will handle filenames with spaces/newlines/other crazy characters, but I always mess up somehow. Nowadays if I ever want a script I'll distribute to people who might have spaces in directories, I write it in python even if it would be a 4 line bash script, just to avoid the issue.
- dijit 10y ago
  I've never really had a problem with spaces in path names. You should be quoting variables when they're used though, there is a shell style guide put out by google that deals with this stuff. https://google.github.io/styleguide/shell.xml?showone=Quoting#Quoting https://google.github.io/styleguide/shell.xml?showone=Quotin...
sjellis 10y ago
Well, once you know that PowerShell uses the verb "Get" for fetching data, and the noun "Content" for file contents then those are reusable bits of knowledge that slot together with other verbs and nouns. It's easy to hold in your head and build your knowledge over time, and better yet, the third-party add-ons obey the common conventions, so you can experiment with confidence. When you learn the *NIX command-line from scratch, everything is special cases, so the whole experience is peering at man pages and slowly rote-learning commands and options. The only commonality is that if you try to guess, you'll probably be wrong. My patience with the philosophy of independent tools hit breaking point a while ago, when I had to start learning the different CLI tools from rival cloud providers - so much to learn, and no consistency at all.
- pjc50 10y ago
  I think this is one of those "familiarity" and "expectation" issues that are very subjective. Rather like python's divisive significant whitespace. I've tried to like powershell, but when I wanted "grep" I ended up having to do: Select-String "str" -Path foo.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt .. because it has broken defaults such as truncating output to terminal width even when written to a file. Then there's the weirdness around enabling script execution (rather more complicated than +x) and the remote execution system is much stranger than ssh.
  - sjellis 10y ago
    My first brushes with PowerShell were deeply frustrating, because I kept trying to write things the way that I expected them to work (from Bash). After a while I gave in and sat through a tutorial, and found that once I did things the way PowerShell wanted, I found it enjoyable to work with. That's just my personal experience. FWIW, the script execution thing was dropped for the latest versions of Windows, and PowerShell Core (thankfully). I agree that the remoting is not much fun - SSH for Windows is currently due in October, so I presume that PowerShell will get SSH support around then.
xg15 10y ago
> I dunno, I'm a long term NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now) But I think this is the point. PowerShell (or the spirit of it) would be more useful for new users because they don't need to spend time memorizing every single command and can start being productive earlier. It probably makes less of a difference if the commands are already part of your muscle memory. Though to be fair, CMD is a lot more quirky and inconsistent than modern bash. So before the advent of PowerShell, I think you could have made the same argument on favor of ...nix and against windows.

slavik81 10y ago

Using powershell left a really sour taste in my mouth. I felt I was promised that objects and types would prevent errors, but it just feels like everything is harder and mistakes are just as easy. For example, 'diff (cat a.txt) (cat b.txt)' does something very different from what you'd expect, but works OK for most inputs. The perfect combination for putting bugs into production. I still like that powershell exists. Especially on Windows where they needed it most. On Linux, though, I'd rather stick with the devil I know.

mastazi 10y ago

> I've never totally loved the shell I don't understand your point, PowerShell is a shell too, just like Bash or Zsh. When you call less, more or any other tool from Powershell, you still retain all the problems that are mentioned in the article. I think the article was focusing more on the ecosystem than anything.

sjellis 10y ago
The ecosystem creates problems that don't exist with PowerShell, which is more like a cross-platform programming language that sits above the OS than the traditional *NIX arrangement of an OS-specific collection of a shell (with some built-ins) plus a grab-bag of third-party tools. Like Python, Node.js etc., PowerShell has one development team that will now be delivering one implementation across all of the operating systems. There's a packaging system included, so that third-party modules can also be uniformly deployed. The first-party and third-party stuff all has to follow the same rules and end up as modules in the same PowerShell installations, which avoids the long-running inconsistencies between tools, like man vs. info and different styles of option parsing. At the moment, different versions of Windows do ship with different versions of PowerShell, which is annoying, but it's the same product and you can install new PowerShell versions on older systems to get a consistent environment across your machines.
- fps 10y ago
  The UNIX philosophy of "do one thing, well" and "write many programs that work together" is contrary to powershell's idea of having all the tools you need as built-ins to your shell. The minute you need something that the "one development team" hadn't thought of, or decided wasn't important enough to ship, you have to either port it to powershell as a plugin or write something more complex to handle your workflow. For all it's cruft and baggage, the fact that there's not "one way to do things" and is continually expandable is part of what endears UNIX to it's users.
  - sjellis 10y ago
    The fact that PowerShell needs modules to fully work with something is definitely an issue - we'll have to see whether people start writing the modules to make PowerShell fully functional on *NIX. You can call existing command-line tools, or methods from the underlying .NET Core installation, but those are really just work-arounds. To be fair, every programming or automation platform has that issue: Python and Ansible succeeded because people did like the basic systems enough to write code to extend their usefulness.

bechampion 10y ago

doing simple "df" "du" "find -exec" it still complex/verbose TODAY using powershell , I find disgusting that you compare bash to powershell (I'm not even talking about speed)

bechampion 10y ago
even tho the commands mentioned above aren't bash built-ins

chriswarbo 10y ago

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny. I think the article was more critical of commercial Unix vendors than Linux. From the article: > Oddly, FreeBSD has done the most sensible thing; they've outright replaced more with less. There is a /usr/bin/more but it's the same binary as less and as you can see the more manpage is just the less manpage. OpenBSD has done the same thing but has a specific manpage for more instead of just giving you the less manpage. > On Linux, more is part of the util-linux package but its manpage outright tells you to use less instead The Free/OpenBSD choice seems sensible; presumably there are Linux distros which do the same. I imagine that if, say, Ubuntu or Debian makes a choice like this, it would propagate quite quickly to other distros; it would presumably be less of a breaking change than switching /bin/sh from bash to dash. > It's time we dropped the "Bash is good enough" arguments. I've rarely heard anyone claim "Bash is good enough". I do agree with the argument that bash is overused, and anything more than a trivial script should be done in a "proper" language (e.g. Python, which is installed by default on pretty much all Linux distros and OSX). I'm not sure if there's a clear winner(s) for interactive use (i.e. a pareto improvement). Many use zsh, but I don't think it goes far enough. More radical alternatives like fish, ipython, etc. seem too fragmented at the moment. Maybe there needs to be momentum from a high-profile distro shipping such a shell as its default (while maintaining /bin/sh, /usr/bin/env bash, etc. for compatibility with existing scripts)

sjellis 10y ago
After using Xonsh and PowerShell, I'd be pretty happy if a Linux distribution did break from the pack and ship a radical alternative as the default, with a legacy bash installation as you describe. Incremental changes probably won't spread uniformly - when Ubuntu switched to dash, the Fedora developers explicitly decided that they would not ship dash and would continue with bash, because they have to maintain total compatibility. In discussions of the new PowerShell release I've seen quite a few comments that boil down to "PowerShell is fine for Windows, but we don't need it on Linux", and I feel that, yeah, we do need a much better shell because what we have is nowhere near the best that can be done. Everybody that's used *NIX for a long period of time has to adapt to the classic shell way of doing things, but we shouldn't be pushing this mess on the next generation.

NoGravitas 10y ago

I kind of feel like Linux people have gotten used to using Python (or similar?) for anything that is complex enough that shell is not enough. Which is also not perfectly suited to the domain, but enough that learning a third thing to do sysadmin-type scripting is not appealing.

Twirrim 10y ago

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny. When do you even need to tell them this? Does it fundamentally change how they use the tool somehow? No, they'll see that you pipe stuff through less and that's it. Heck, I've been using Linux for 15+ years, and about 10 of those full time. The first I ever heard that "less is more" was probably ~3 years ago. It just doesn't matter. What you're complaining about is esoteria (that is still littered all over the Windows ecosystem, e.g. the fingerprints of 8.3 file names still persist, long after it ceased to be a thing)

sjellis 10y ago
The Linux command-line experience is mostly composed of esoterica, and less vs. more is actually one of the least bad of a thousand paper cuts. I just couldn't resist taking a dig at the pun. One thing that this thread has really brought into focus for me is that we treat the *NIX shells differently, because we are used to them, but IMO we ought to hold the shell to the same standards that we'd apply to any programming environment. If a new programming language with a REPL shipped today that was the quality of the shell experience that we've currently got, we'd think that it was ridiculous.