1. 10
  1.  

  2. 2

    If working with JSON in PowerShell, I don’t often find myself using something like jc in between my request and deserialization steps.

    This is usually enough for quick things:

    $resp = curl <thing> | ConvertFrom-Json $resp.content

    or

    (curl <thing> | ConvertFrom-Json).content

    1. 1

      I would love if something like FreeBSD’s --libxo flag were commonly supported. I makes Iife so much easier, and it scales better as a solution than the likes of jc.

      1. 1

        The lack of fish is conspicuous here.

        1. 1

          It probably should be mentioned with all the other *nix shells, but it doesn’t really have any special built-in support beyond what the others have, unless I’ve forgotten something…

          1. 1

            it doesn’t really have any special built-in support beyond what the others have, unless I’ve forgotten something…

            Special? Maybe not. But different? Aye! To crib your example, what is in Bash

            $ myvar=$(dig www.google.com | jc --dig | jq -r '.[0].answer[0].data')
            $ echo $myvar
            64.233.185.104
            

            is in Fish

            $ set myvar (dig www.google.com | jc --dig | jq -r '.[0].answer[0].data')
            $ echo $myvar
            64.233.185.104
            
            1. 1

              But that’s not special support for JSON, and is just the fact that fish’s syntax is slightly different.

        2. 1

          Great post! Nice to see at least some convergence in alternative shells. Everyone agrees we want JSON :)

          1. 2

            We don’t. And the meme that PowerShell is “more powerful” of “better” because it uses objects with structure rather than plain text is finally dying.

            Text is the easiest and most versatile common denominator. If you want a serializable format for data structures, nothing stops you from using such a format, such as JSON. But to have this idea that every application will output some sort of object is very naive/silly. JC is a manually maintained hack that cannot possibly scale reliably.

            Applications output bytes. Raw bites are unintelligible to humans. The next most basic form of data is text. Terminals are compatible with text. There is no gain into forcing them an object format rather than just text. In essence what you guys want is removing a feature “because objects are better”. But you can already use JSON or whatever data structure serialization format you want. Whomever needs it uses it. The reason why most cli apps don’t use it is because they don’t need it and it wouldn’t make sense for them.

            Ls being a clear example. It’s primary for human consumption and has perfectly acceptable machine readability traits. Outputing a JSON object to list files is just silly.

            Disclaimer: I love JSON and use jq viciously every day.

            1. 4

              ls is a perfect example of how text alone is often insufficient. How many times have you seen a broken shell script because someone did ls -1 and forgot to quote correctly which broke file names with white space?

              1. 2

                And also it is annoying that ls has specific flags for sorting by date, by name, etc. And so does ps.

                The lack of structure / convention makes the tools more complicated

                1. 1

                  Very few. Most of the times there are no files with such names in the context of such shellscripts. 99% I see the pattern you mentioned, it is in the context of generated files, which names fall into an known domain. But ls -1 is non ambiguous AFAIK. You can’t have newlines in file names. What exactly would JSON buy us in that case?

                2. 1

                  Yeah that is precisely the argument I’m making in this set of posts:

                  https://www.oilshell.org/blog/tags.html?tag=software-architecture#software-architecture

                  Especially here:

                  https://www.oilshell.org/blog/2022/03/backlog-arch.html#csv-json-html-tables-records-documents

                  Text is still the lowest common denominator / narrow waist, and I spilled tens of thousands of words on that!

                  Lots of other shell authors disagree! I explicitly disagree with them on that – and I linked some long conversations linked in the posts.

                  But I definitely think shells should give you the OPTION of processing JSON if you want it. AND that is complementary to jq, since shell does more things than process data.

                  So in Oil text is primary. In other shells like PowerShell and nushell, tables / objects / etc. are primary.

                  The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually an Oil script).

                  This is because each alternative shell chooses a different kind of structured data as its narrow waist (.NET objects, tree-structured data, Racket data structures, and tables, respectively). Text is the most structured format they all agree on, and shell is the language of coarse-grained composition with text.

                  1. 1

                    But I definitely think shells should give you the OPTION of processing JSON if you want it. AND that is complementary to jq, since shell does more things than process data.

                    What’s wrong with the having specific tools that use it instead of jamming it into the shell? That has always been the Unix philosophy. A bunch of tools with specific well defined purposes. I suspect all these discussions are motivated by people not really mastering the old Unix toolset.

                    1. 3

                      Well bash has grown arrays and associative arrays – but not very well. So there’s one hint you need structured data in a shell.

                      https://www.oilshell.org/blog/2016/11/06.html

                      Another issue I mentioned – try typing the command to sort ls -l by date or by size, and ps by start time or CPU usage.

                      The lack of structure makes it impossible for ls and ps to have a “well defined purpose” – they both have mini-sorting languages are inconsistent. Ditto for find.

                      You’re making too big a leap – plenty of people have “mastered” Unix, and Unix shell, and still run into its limitations.