6 ms·

You know what also offers cross-platform automation and has packages available on all named operating systems? Bash.

by jitl 9y ago

mrguyorama 9y ago
The massive paradigm shift that is powershell (ie object based instead of text based) gives it enough space to exist alongside bash. It will not replace bash, and at least on other platforms I highly doubt it's supposed to, as powershell is so heavily Windows focused
- AnIdiotOnTheNet 9y ago
  Which is very unfortunate in my opinion. Powershell does the UNIX philosophy better than the equivalent traditional toolset by a wide margin. Bourne shell is a clumsy, ugly, footgun-laden automation language and the toolset uses text formatting and parsing in its piping io. The whole thing could really stand to be rethought.
  - mpweiher 9y ago
    > Powershell does the UNIX philosophy better than the equivalent traditional toolset How so? Remember that the "text" convention was not chosen haphazardly, but rather very consciously.
    - wvenable 9y ago
      The convention was chosen back when both CPU and memory were also many orders of magnitude less. Also chosen back when many principles of good software design were still in their infancy. Decisions made 40 years ago were based on entirely different constraints and with a lot less history.
    - bitwize 9y ago
      And it's wrong. Nearly everything taught to you by Unix is wrong. The textual format convention is wrong because text needs to be parsed and unparsed, which is slow and error-prone. Moving objects with clearly defined APIs between programs is more performant and robust. To move objects between machines, use a binary format like Cap'n Proto, which requires no parsing. The only thing text gives you is viewability/editability with vi or nano; with a well-defined, open binary format, tools can be easily written to view and manipulate the raw data streams. Unix's I/O model is broken because it has no intrinsic support for asynchronous I/O. The POSIX aio API sucks, nobody uses it, and it doesn't allow the single syscall check-for-data-and-kickoff-overlapped-I/O-if-not-found that's practically an idiom in Windows (at least not under Linux, where it's implemented in user space via helper processes). The standard multiprocessing primitives in Unix are broken. fork() starts a new process with the same memory image, possessing the same system resources as the old -- convenient in 1979 but highly dangerous in the presence of threads. The correct approach would be to specify a new image to load and run, as in posix_spawn or Windows CreateProcess. In short, fuck Unix and fuck the Unix Philosophy.
      - mpweiher 9y ago
        > slow and error-prone And yet in all my tests Unix was at least an order of magnitude faster than PowerShell. Considering the data doesn't back you, I'd watch my proclamations.
        justinsaccount 9y ago
        A specific implementation not being particularly optimized does not mean the underlying concept is flawed.
        josefx 9y ago
        The claim was that text based tools are slower, right now that is clearly not the case. Of course a comparison between the current implementation of powershell and unix tools is not quite fair, they only had twelve years after all and unix had ~fourty. I would give them annother three decades to catch up.
        mhermher 9y ago
        Compiled code generally runs faster than plain-text interpreted code, even with no compiler optimizations. How about those tools? The whole point was that text parsing is an additional overhead that will make things slower. It's trivially true.
        flukus 9y ago
        How does powershell pass objects from one process to another? Presumably there's a serialization/deserialization step involved? This could easily be slower than copying test around.
        mhermher 9y ago
        There doesn't have to be. It could just pass references to memory addresses of the object, or even just a copy of the raw binary data. If both the passer and the receiver understand the class of the object, then there is no serialization/deserialization necessary.
    - justinsaccount 9y ago
      If the text format was chosen responsibly most unix utilities could output data in a machine readable TSV mode with a standardized header and escaping format, not the mess we have now.
  - mrguyorama 9y ago
    powershell also kind of has an awful UX, and a serious discoverability problem. I know powershell can do literally anything I want, but god help me find out what it's called Not to mention the way it reports errors to the user is incredibly verbose. However, it seems very par for the course for a strong Microsoft tool. If you are able to get in the correct headspace, it's magical. I'm just sad I have to sell my soul to the cult to use it
    - AnIdiotOnTheNet 9y ago
      >serious discoverability problem I find this an odd assertion since powershell lets you tab-complete cmdlets and argument options and has Get-Member.
      - mrguyorama 9y ago
        I wasn't even able to discover that!
        useerup 9y ago
        This is all you need to get started: Get-Help, Get-Command Everything from there on is discoverable through what you learn from those 2 cmdlets
        deleted 9y ago
        [deleted]
    - ZenoArrow 9y ago
      > "powershell also kind of has an awful UX, and a serious discoverability problem." There are points of criticism I could level at PowerShell, but discoverability is not one of them. If you want to explore PowerShell without using any formal tutorials, I'd recommend five commands: * Get-Verb * Get-Alias * Get-Help * Get-Module * Get-Command Get-Verb is useful as it gives you clues about the PowerShell naming convention. Aside from aliases, the vast majority of the commands in PowerShell start with one of the verbs listed by Get-Verb. You can use tab completion to cycle through all currently available commands, e.g. type "Get" (without quotes) then keep pressing the tab key to see the available commands (that are currently loaded). Get-Alias shows you the command aliases that have been setup for use in your PowerShell session. The reason I recommend it here is twofold: 1. The aliases provided by default are assigned to the most commonly used commands, so Get-Alias can give you a shortlist of commands that are good to explore first. 2. If you have prior experience with the Windows command line or the Linux terminal, Get-Alias will give you clues about what different commands do. For example, dir and ls are both aliases for Get-ChildItem. Get-Help gives you access to command documentation. One hint I'd give about help in PowerShell is if you need to update the PowerShell help available on your machine, run Update-Help from an elevated command prompt (e.g. on Windows, run PowerShell as an administrator before running Update-Help). If you haven't got local admin permissions, Get-Help is still useful, and will point you in the direction of relevant online documentation if it can't find the help documentation locally. Get-Module lists the commands by the module they're found in. By default it only shows the modules that are currently loaded, but with Get-Module -ListAvailable you can see all the modules you can choose from. In later versions of PowerShell running a command automatically loads the module it's in (in earlier versions you have to use Load-Module beforehand if the module wasn't already loaded). Note that the -ListAvailable option could've been discovered using Get-Help (e.g. Get-Help Get-Module). Get-Command allows you to explore the metadata about a command. You're better off reading up on what it can do (Get-Help Get-Command would be a decent start), but to give you one example of why you might find it useful when starting out is that it lets you explore the parameter sets associated with a command. Parameter sets are ways of allowing different groups of parameters to be used with a single command. For example, if you're testing the network connection of computers on a work network, you may choose to reference the computer by IP address, or you may reference the computer by computer name. In this case, parameter sets are a way of making one of those parameters mandatory. Note that commands have a default parameter set, and if you try running a command with mandatory parameters in the default parameter set without passing them in, it will request the minimum information the command requires to function. With all that said, I'd leave Get-Command alone until you're more familiar with the basic operations in PowerShell. As a final piece of advice, if you're on Windows I would recommend using PowerShell ISE when you start out. It might not look as pretty as VS Code (which also has decent PowerShell support), but it's good at exposing what you need to write effective PowerShell scripts. I use it regularly at work, even for simple tasks that the standalone PowerShell command line would work for. Also worth noting that it ships with Windows, simply search for PowerShell ISE using the Windows menu search.
justinsaccount 9y ago
> cross-platform automation > bash Nope. Show me the script that gets a list of mounted filesytems for locally attached disks and flags any that are larger than 20G and are more than 90% full. Since it is cross platform it will run the same on linux/bsd/os x and windows, right?
- blacksmith_tb 9y ago
  I haven't used the Windows Subsystem for Linux much, but shouldn't it be possible to have a bash script that runs on all of them? (though it might take some testing against the environment, for things like osx's /Volumes etc.)
  - maxsilver 9y ago
    I use WSL daily, and yes you can see your entire C:\ drive in WSL under /mnt/c/, and all the common directory commands work, so running a bash script is 'cross-platform' in that way. That's sort of cheating though. In that instance, Bash isn't really being cross platform, so much as Windows bent over backwards to re-implement lots of Linux underneath Bash, so Bash could treat Linux and Linux (on Windows) identically. Or to restate that: If Linux apps get to claim they are 'cross-platform' because of WSL, then Windows apps get to claim they are 'cross-platform' because you could run them in WINE.
  - justinsaccount 9y ago
    Exactly.. It's sort of possible.. if nothing goes wrong and you remember to run df in posix mode and you manage to parse the output correctly.
- rkeene2 9y ago
  Don't forget about AIX, Solaris, and IRIX :-)
  - vram22 9y ago
    And HP-UX, Ultrix, Tru64, and probably a few more. https://en.wikipedia.org/wiki/HP-UX https://en.wikipedia.org/wiki/HP-UX I used HP-UX for a while; it was good. In fact I first wrote this Unix utility [1] (and later an IBM developerWorks article about it) on an HP-UX system, for a big manufacturing client. HP-UX was pretty stable and had a good patch management system. Had some good tools from HP on top of the OS, such as GlancePlus, Ignite-UX, Process Resource Manager, etc., and another high-end one called MC ServiceGuard. https://en.wikipedia.org/wiki/Ultrix https://en.wikipedia.org/wiki/Ultrix https://en.wikipedia.org/wiki/Tru64_UNIX https://en.wikipedia.org/wiki/Tru64_UNIX Edit: Sorry, forgot to add the link I quoted above. Done now: [1] https://jugad2.blogspot.in/2014/09/my-ibm-developerworks-article.html https://jugad2.blogspot.in/2014/09/my-ibm-developerworks-art... It's a tutorial on the topic: Developing a Linux command-line utility (in C).
seabrookmx 9y ago
I would have said Python. My rule of thumb is that if a bash script is > 10-20 lines or needs a function, then I rewrite it in Python. It's simply way more readable. The main downside to using Python is that if you're running on a minimal system, in a container, or on Windows, Python is a large install. But I don't see how porting Powershell to _nix solves that issue. _nix systems are more common in most web-centric companies nowadays. If you're a company that uses both you're better off installing Python on your Windows boxes IMO since they probably have bigger disks anyways to handle the large OS.
- ZenoArrow 9y ago
  > "But I don't see how porting Powershell to _nix solves that issue." I'd say the main reason to install PowerShell on Linux is if you want to use the tools for managing Azure. Aside from that, there are other scripting languages that are have a more mature library ecosystems on Linux.

You know what also offers cross-platform automation and has packages available on all named operating systems? Bash.

by jitl 9y ago

You know what also offers cross-platform automation and has packages available on all named operating systems? Bash.

The massive paradigm shift that is powershell (ie object based instead of text based) gives it enough space to exist alongside bash. It will not replace bash, and at least on other platforms I highly doubt it's supposed to, as powershell is so heavily Windows focused

AnIdiotOnTheNet 9y ago
Which is very unfortunate in my opinion. Powershell does the UNIX philosophy better than the equivalent traditional toolset by a wide margin. Bourne shell is a clumsy, ugly, footgun-laden automation language and the toolset uses text formatting and parsing in its piping io. The whole thing could really stand to be rethought.
- mpweiher 9y ago
  > Powershell does the UNIX philosophy better than the equivalent traditional toolset How so? Remember that the "text" convention was not chosen haphazardly, but rather very consciously.
  - wvenable 9y ago
    The convention was chosen back when both CPU and memory were also many orders of magnitude less. Also chosen back when many principles of good software design were still in their infancy. Decisions made 40 years ago were based on entirely different constraints and with a lot less history.
  - bitwize 9y ago
    And it's wrong. Nearly everything taught to you by Unix is wrong. The textual format convention is wrong because text needs to be parsed and unparsed, which is slow and error-prone. Moving objects with clearly defined APIs between programs is more performant and robust. To move objects between machines, use a binary format like Cap'n Proto, which requires no parsing. The only thing text gives you is viewability/editability with vi or nano; with a well-defined, open binary format, tools can be easily written to view and manipulate the raw data streams. Unix's I/O model is broken because it has no intrinsic support for asynchronous I/O. The POSIX aio API sucks, nobody uses it, and it doesn't allow the single syscall check-for-data-and-kickoff-overlapped-I/O-if-not-found that's practically an idiom in Windows (at least not under Linux, where it's implemented in user space via helper processes). The standard multiprocessing primitives in Unix are broken. fork() starts a new process with the same memory image, possessing the same system resources as the old -- convenient in 1979 but highly dangerous in the presence of threads. The correct approach would be to specify a new image to load and run, as in posix_spawn or Windows CreateProcess. In short, fuck Unix and fuck the Unix Philosophy.
    - mpweiher 9y ago
      > slow and error-prone And yet in all my tests Unix was at least an order of magnitude faster than PowerShell. Considering the data doesn't back you, I'd watch my proclamations.
      - justinsaccount 9y ago
        A specific implementation not being particularly optimized does not mean the underlying concept is flawed.
        josefx 9y ago
        The claim was that text based tools are slower, right now that is clearly not the case. Of course a comparison between the current implementation of powershell and unix tools is not quite fair, they only had twelve years after all and unix had ~fourty. I would give them annother three decades to catch up.
        mhermher 9y ago
        Compiled code generally runs faster than plain-text interpreted code, even with no compiler optimizations. How about those tools? The whole point was that text parsing is an additional overhead that will make things slower. It's trivially true.
        flukus 9y ago
        How does powershell pass objects from one process to another? Presumably there's a serialization/deserialization step involved? This could easily be slower than copying test around.
        mhermher 9y ago
        There doesn't have to be. It could just pass references to memory addresses of the object, or even just a copy of the raw binary data. If both the passer and the receiver understand the class of the object, then there is no serialization/deserialization necessary.
  - justinsaccount 9y ago
    If the text format was chosen responsibly most unix utilities could output data in a machine readable TSV mode with a standardized header and escaping format, not the mess we have now.
- mrguyorama 9y ago
  powershell also kind of has an awful UX, and a serious discoverability problem. I know powershell can do literally anything I want, but god help me find out what it's called Not to mention the way it reports errors to the user is incredibly verbose. However, it seems very par for the course for a strong Microsoft tool. If you are able to get in the correct headspace, it's magical. I'm just sad I have to sell my soul to the cult to use it
  - AnIdiotOnTheNet 9y ago
    >serious discoverability problem I find this an odd assertion since powershell lets you tab-complete cmdlets and argument options and has Get-Member.
    - mrguyorama 9y ago
      I wasn't even able to discover that!
      - useerup 9y ago
        This is all you need to get started: Get-Help, Get-Command Everything from there on is discoverable through what you learn from those 2 cmdlets
      - deleted 9y ago
        [deleted]
  - ZenoArrow 9y ago
    > "powershell also kind of has an awful UX, and a serious discoverability problem." There are points of criticism I could level at PowerShell, but discoverability is not one of them. If you want to explore PowerShell without using any formal tutorials, I'd recommend five commands: * Get-Verb * Get-Alias * Get-Help * Get-Module * Get-Command Get-Verb is useful as it gives you clues about the PowerShell naming convention. Aside from aliases, the vast majority of the commands in PowerShell start with one of the verbs listed by Get-Verb. You can use tab completion to cycle through all currently available commands, e.g. type "Get" (without quotes) then keep pressing the tab key to see the available commands (that are currently loaded). Get-Alias shows you the command aliases that have been setup for use in your PowerShell session. The reason I recommend it here is twofold: 1. The aliases provided by default are assigned to the most commonly used commands, so Get-Alias can give you a shortlist of commands that are good to explore first. 2. If you have prior experience with the Windows command line or the Linux terminal, Get-Alias will give you clues about what different commands do. For example, dir and ls are both aliases for Get-ChildItem. Get-Help gives you access to command documentation. One hint I'd give about help in PowerShell is if you need to update the PowerShell help available on your machine, run Update-Help from an elevated command prompt (e.g. on Windows, run PowerShell as an administrator before running Update-Help). If you haven't got local admin permissions, Get-Help is still useful, and will point you in the direction of relevant online documentation if it can't find the help documentation locally. Get-Module lists the commands by the module they're found in. By default it only shows the modules that are currently loaded, but with Get-Module -ListAvailable you can see all the modules you can choose from. In later versions of PowerShell running a command automatically loads the module it's in (in earlier versions you have to use Load-Module beforehand if the module wasn't already loaded). Note that the -ListAvailable option could've been discovered using Get-Help (e.g. Get-Help Get-Module). Get-Command allows you to explore the metadata about a command. You're better off reading up on what it can do (Get-Help Get-Command would be a decent start), but to give you one example of why you might find it useful when starting out is that it lets you explore the parameter sets associated with a command. Parameter sets are ways of allowing different groups of parameters to be used with a single command. For example, if you're testing the network connection of computers on a work network, you may choose to reference the computer by IP address, or you may reference the computer by computer name. In this case, parameter sets are a way of making one of those parameters mandatory. Note that commands have a default parameter set, and if you try running a command with mandatory parameters in the default parameter set without passing them in, it will request the minimum information the command requires to function. With all that said, I'd leave Get-Command alone until you're more familiar with the basic operations in PowerShell. As a final piece of advice, if you're on Windows I would recommend using PowerShell ISE when you start out. It might not look as pretty as VS Code (which also has decent PowerShell support), but it's good at exposing what you need to write effective PowerShell scripts. I use it regularly at work, even for simple tasks that the standalone PowerShell command line would work for. Also worth noting that it ships with Windows, simply search for PowerShell ISE using the Windows menu search.

justinsaccount 9y ago

> cross-platform automation > bash Nope. Show me the script that gets a list of mounted filesytems for locally attached disks and flags any that are larger than 20G and are more than 90% full. Since it is cross platform it will run the same on linux/bsd/os x and windows, right?

blacksmith_tb 9y ago
I haven't used the Windows Subsystem for Linux much, but shouldn't it be possible to have a bash script that runs on all of them? (though it might take some testing against the environment, for things like osx's /Volumes etc.)
- maxsilver 9y ago
  I use WSL daily, and yes you can see your entire C:\ drive in WSL under /mnt/c/, and all the common directory commands work, so running a bash script is 'cross-platform' in that way. That's sort of cheating though. In that instance, Bash isn't really being cross platform, so much as Windows bent over backwards to re-implement lots of Linux underneath Bash, so Bash could treat Linux and Linux (on Windows) identically. Or to restate that: If Linux apps get to claim they are 'cross-platform' because of WSL, then Windows apps get to claim they are 'cross-platform' because you could run them in WINE.
- justinsaccount 9y ago
  Exactly.. It's sort of possible.. if nothing goes wrong and you remember to run df in posix mode and you manage to parse the output correctly.
rkeene2 9y ago
Don't forget about AIX, Solaris, and IRIX :-)
- vram22 9y ago
  And HP-UX, Ultrix, Tru64, and probably a few more. https://en.wikipedia.org/wiki/HP-UX https://en.wikipedia.org/wiki/HP-UX I used HP-UX for a while; it was good. In fact I first wrote this Unix utility [1] (and later an IBM developerWorks article about it) on an HP-UX system, for a big manufacturing client. HP-UX was pretty stable and had a good patch management system. Had some good tools from HP on top of the OS, such as GlancePlus, Ignite-UX, Process Resource Manager, etc., and another high-end one called MC ServiceGuard. https://en.wikipedia.org/wiki/Ultrix https://en.wikipedia.org/wiki/Ultrix https://en.wikipedia.org/wiki/Tru64_UNIX https://en.wikipedia.org/wiki/Tru64_UNIX Edit: Sorry, forgot to add the link I quoted above. Done now: [1] https://jugad2.blogspot.in/2014/09/my-ibm-developerworks-article.html https://jugad2.blogspot.in/2014/09/my-ibm-developerworks-art... It's a tutorial on the topic: Developing a Linux command-line utility (in C).

seabrookmx 9y ago

I would have said Python. My rule of thumb is that if a bash script is > 10-20 lines or needs a function, then I rewrite it in Python. It's simply way more readable. The main downside to using Python is that if you're running on a minimal system, in a container, or on Windows, Python is a large install. But I don't see how porting Powershell to _nix solves that issue. _nix systems are more common in most web-centric companies nowadays. If you're a company that uses both you're better off installing Python on your Windows boxes IMO since they probably have bigger disks anyways to handle the large OS.

ZenoArrow 9y ago
> "But I don't see how porting Powershell to _nix solves that issue." I'd say the main reason to install PowerShell on Linux is if you want to use the tools for managing Azure. Aside from that, there are other scripting languages that are have a more mature library ecosystems on Linux.