3 ms·

That only works if there is a type of object for each and every type of output you will ever need. In my experience, there are often commands which just output

That only works if there is a type of object for each and every type of output you will ever need. In my experience, there are often commands which just output text, and I need to parse them somehow, which leads to an awkward flood of Out-String | { $_ | Select-String -Pattern "etc." } type commands which are hard for me to get right. Perhaps that's just a reflection of my lack of experience with PowerShell, but assuming commands have a stable CLI interface (which most commands do in the *nix world), it's much easier for me to simply parse things with sed/awk/grep.

Pet_Ant 4y ago
> That only works if there is a type of object for each and every type of output you will ever need. Everything returned by the built-in commands is. If you are calling some executable, yeah, then you'll need to wrap it. I do recommend wrapping commonly used executables with things that return PowerShell objects. Tedious at first but as you build up over time you find yourself straying into string parsing less and less.
- crabbone 4y ago
  > I do recommend wrapping commonly used executables with things that return PowerShell objects. I'd better spend my time writing a different shell. This sounds like a life-long with ever increasing number of bugs nightmare to support kind of project.
  - injidup 4y ago
    And what would your different shell do with a command that just returned plain text. You have the same parsing problem. Powershell gives you a standard object system to work with that if you lift stuff into are then available to everything else. With text shells everyone ends up writing a different parser each time for each small script.
    - bheadmaster 4y ago
      > And what would your different shell do with a command that just returned plain text It would give me tools like sed/grep/awk/tr/cut/etc., and allow easy capturing of output into variables and performing bash substitutions. IMHO, that's much more powerful than PowerShell's Select-String.
      - AnIdiotOnTheNet 4y ago
        ...its the exact same damn thing. Parse text, put it into variables. PowerShell has the equivalent of all those same tools. The big difference is that you don't have to use them for every goddamned command.
        bheadmaster 4y ago
        > PowerShell has the equivalent of all those same tools. Really? What are the equivalents?
        majkinetor 4y ago
        Select-String and Select-Object cover all those. Also, you can use linux tools in PowerShell, but that is not the point, it is back to stone age moment. Shell scripts shouldn't be other name for text parsing.
        bheadmaster 4y ago
        Select-String covers grep (regex match) and Select-Object doesn't do anything for text parsing. You cannot use linux tools in PowerShell in most cases, since they aren't installed by default. > Shell scripts shouldn't be other name for text parsing. That may be true, but like any other ideal - it's just that, and ideal. In the real world a lot of shell scripting requires parsing unstructured text from various command outputs and files. PowerShell works great in its own microcosm of objects and commands that manipulate objects, but as soon as you step out of that comfort zone it becomes awkward to use.
  - majkinetor 4y ago
    > I'd better spend my time writing a different shell. That is funny and shows tremendous lack of understading of shell complexity. Perhaps your own OS next ?
    - bheadmaster 4y ago
      I assume they meant "writing in a different shell". The literal comment indeed doesn't make much sense.
    - crabbone 4y ago
      I answered this question a few comments above: no. I was correct the first time. My biggest problems with Unix shell as it is, and if I cannot change the OS interface, are process groups, handling of exit codes and using exit codes in boolean context. If I were to work on a shell alternative to standard Unix shell, I'd remove the reliance on system calls related to creating pipes and process groups and would do this in the shell to escape the wrong way it's currently done by the system. Another thought I have is re-designing the work with processes and their output in the way similar to Erlang's ports. I'm not sure this can be done in all instances, but I would definitely give it a try. There are other minor evils, like return vs exit that needs to be solved... but, I really don't have a plan for making my own shell, so all the above is just based on particular pain points I had with it over the years, so, I don't really plan on making my own shell. But, equally, and even more so, I have absolutely no intention to use PowerShell, especially because I'd have to maintain hundreds of unrelated pieces of code, each with its own versioning history and a huge compatibility matrix. That just sounds like insanely boring and unproductive way to spend my life.
majkinetor 4y ago
> Perhaps that's just a reflection of my lack of experience with PowerShell Obviously. If you create pwsh script that is longer then equivalent bash script and more confusing, then you are doing it wrong. One almost never parses string in pwsh, unless string parsing is your primary task itself. Contrary, in bash, you always parse text, no matter what you want to do, which is defocusing and hard to maintain, and has cross-OS problems even in *nix land (solaris vs red had comes to mind and their respective ls/stat output which differs).
- bheadmaster 4y ago
  > One almost never parses string in pwsh Assuming that there are object-based commands that do everything that you need, which is quite a generous assumption.

Pet_Ant 4y ago

> That only works if there is a type of object for each and every type of output you will ever need. Everything returned by the built-in commands is. If you are calling some executable, yeah, then you'll need to wrap it. I do recommend wrapping commonly used executables with things that return PowerShell objects. Tedious at first but as you build up over time you find yourself straying into string parsing less and less.

crabbone 4y ago
> I do recommend wrapping commonly used executables with things that return PowerShell objects. I'd better spend my time writing a different shell. This sounds like a life-long with ever increasing number of bugs nightmare to support kind of project.
- injidup 4y ago
  And what would your different shell do with a command that just returned plain text. You have the same parsing problem. Powershell gives you a standard object system to work with that if you lift stuff into are then available to everything else. With text shells everyone ends up writing a different parser each time for each small script.
  - bheadmaster 4y ago
    > And what would your different shell do with a command that just returned plain text It would give me tools like sed/grep/awk/tr/cut/etc., and allow easy capturing of output into variables and performing bash substitutions. IMHO, that's much more powerful than PowerShell's Select-String.
    - AnIdiotOnTheNet 4y ago
      ...its the exact same damn thing. Parse text, put it into variables. PowerShell has the equivalent of all those same tools. The big difference is that you don't have to use them for every goddamned command.
      - bheadmaster 4y ago
        > PowerShell has the equivalent of all those same tools. Really? What are the equivalents?
        majkinetor 4y ago
        Select-String and Select-Object cover all those. Also, you can use linux tools in PowerShell, but that is not the point, it is back to stone age moment. Shell scripts shouldn't be other name for text parsing.
        bheadmaster 4y ago
        Select-String covers grep (regex match) and Select-Object doesn't do anything for text parsing. You cannot use linux tools in PowerShell in most cases, since they aren't installed by default. > Shell scripts shouldn't be other name for text parsing. That may be true, but like any other ideal - it's just that, and ideal. In the real world a lot of shell scripting requires parsing unstructured text from various command outputs and files. PowerShell works great in its own microcosm of objects and commands that manipulate objects, but as soon as you step out of that comfort zone it becomes awkward to use.
- majkinetor 4y ago
  > I'd better spend my time writing a different shell. That is funny and shows tremendous lack of understading of shell complexity. Perhaps your own OS next ?
  - bheadmaster 4y ago
    I assume they meant "writing in a different shell". The literal comment indeed doesn't make much sense.
  - crabbone 4y ago
    I answered this question a few comments above: no. I was correct the first time. My biggest problems with Unix shell as it is, and if I cannot change the OS interface, are process groups, handling of exit codes and using exit codes in boolean context. If I were to work on a shell alternative to standard Unix shell, I'd remove the reliance on system calls related to creating pipes and process groups and would do this in the shell to escape the wrong way it's currently done by the system. Another thought I have is re-designing the work with processes and their output in the way similar to Erlang's ports. I'm not sure this can be done in all instances, but I would definitely give it a try. There are other minor evils, like return vs exit that needs to be solved... but, I really don't have a plan for making my own shell, so all the above is just based on particular pain points I had with it over the years, so, I don't really plan on making my own shell. But, equally, and even more so, I have absolutely no intention to use PowerShell, especially because I'd have to maintain hundreds of unrelated pieces of code, each with its own versioning history and a huge compatibility matrix. That just sounds like insanely boring and unproductive way to spend my life.

majkinetor 4y ago

> Perhaps that's just a reflection of my lack of experience with PowerShell Obviously. If you create pwsh script that is longer then equivalent bash script and more confusing, then you are doing it wrong. One almost never parses string in pwsh, unless string parsing is your primary task itself. Contrary, in bash, you always parse text, no matter what you want to do, which is defocusing and hard to maintain, and has cross-OS problems even in *nix land (solaris vs red had comes to mind and their respective ls/stat output which differs).

bheadmaster 4y ago
> One almost never parses string in pwsh Assuming that there are object-based commands that do everything that you need, which is quite a generous assumption.