3 ms·

> 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 ar

> 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
        Select-Object is for head/tail as poster mentioned that. Also, it can be used for accessing parsed content similar to awk, for example: '1,2,3,4,5' -split ',' | select -Index 3,5 > You cannot use linux tools in PowerShell in most cases, since they aren't installed by default. The same as jq and specific variants of tools you mention. Not like you can't install them in single line: winget/choco install awk,grep,jq,less... > In the real world a lot of shell scripting requires parsing unstructured text from various command outputs and files. No it doesn't. I do shell scripting for more then decade in PowerShell and I can count how many times I parsed the text. The most used one is simple split like with `$paths = $Env:PATH -split ';|:'`, but other then that no. I used select-string only couple of times in decade, on all OSes. > but as soon as you step out of that comfort zone it becomes awkward to use. That is true for literary anything. Actually pwsh does great with 'native' tools too, and there is even MS module to help with "native app wrapping". See [1] and [2] Today its more or less regular to have json output which can be trivially read by pwsh ConvertFrom-Json [1] https://devblogs.microsoft.com/powershell/native-commands-in-powershell-a-new-approach https://devblogs.microsoft.com/powershell/native-commands-in.... [2] https://redmondmag.com/articles/2020/12/11/powershell-crescendo-preview.aspx https://redmondmag.com/articles/2020/12/11/powershell-cresce...
  - crabbone 4y ago
    All I really need from a different shell is a mechanism to not accidentally throw away exit codes (eg. when piping) and not using exit codes as boolean. I mean, if I cannot change the OS interface, of course. The way process groups work today is a footgun a lot of people don't even know they have. I really couldn't care less about plain text. It doesn't bother me. What PoverShell "gives me" is another spoonful of sugar in my already sweet tee. It's really unnecessary / would just make my life more miserable.
- 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.

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
        Select-Object is for head/tail as poster mentioned that. Also, it can be used for accessing parsed content similar to awk, for example: '1,2,3,4,5' -split ',' | select -Index 3,5 > You cannot use linux tools in PowerShell in most cases, since they aren't installed by default. The same as jq and specific variants of tools you mention. Not like you can't install them in single line: winget/choco install awk,grep,jq,less... > In the real world a lot of shell scripting requires parsing unstructured text from various command outputs and files. No it doesn't. I do shell scripting for more then decade in PowerShell and I can count how many times I parsed the text. The most used one is simple split like with `$paths = $Env:PATH -split ';|:'`, but other then that no. I used select-string only couple of times in decade, on all OSes. > but as soon as you step out of that comfort zone it becomes awkward to use. That is true for literary anything. Actually pwsh does great with 'native' tools too, and there is even MS module to help with "native app wrapping". See [1] and [2] Today its more or less regular to have json output which can be trivially read by pwsh ConvertFrom-Json [1] https://devblogs.microsoft.com/powershell/native-commands-in-powershell-a-new-approach https://devblogs.microsoft.com/powershell/native-commands-in.... [2] https://redmondmag.com/articles/2020/12/11/powershell-crescendo-preview.aspx https://redmondmag.com/articles/2020/12/11/powershell-cresce...
- crabbone 4y ago
  All I really need from a different shell is a mechanism to not accidentally throw away exit codes (eg. when piping) and not using exit codes as boolean. I mean, if I cannot change the OS interface, of course. The way process groups work today is a footgun a lot of people don't even know they have. I really couldn't care less about plain text. It doesn't bother me. What PoverShell "gives me" is another spoonful of sugar in my already sweet tee. It's really unnecessary / would just make my life more miserable.
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.