Bringing the Unix philosophy to the 21st century (2019)

Post by kbrazil » Mon, Aug 23, 2021, 8:33 PM UTC

hjek wrote: post #138

kbrazil wrote: post #133

Earlier quoted context omitted.

Ah, yes - that locale is not supported. From the Caveats section: For best results set the LANG locale environment variable to `C` or `en_US.UTF-8`. For example, either by setting directly on the command-line: $ LANG=C date | jc --date It is possible to add support for more locales and you can always override the built in parsers with your own plugin to support it.

Yea, however this means that @ape4's point still stands: > But, um, seems slightly kludgy to be obvious. What if the `ifconfig` format changes slightly.

Post by eadmund » Mon, Aug 23, 2021, 9:08 PM UTC

iainmerrick wrote: post #122

lfnoise wrote: post #94

Earlier quoted context omitted.

You parse the s-exprs and execute them in the context of a namespace of data constructors. Then you can have whatever data structures in memory that are defined by the constructors. This is NOT equivalent to having one data structure to cover both as Lua does. It is having one text format that can construct any kind of data structure in memory for which you have constructors defined.

Okay, but we’re talking about a lingua franca for exchanging plain old data between different programs. You would have to pick your data constructors in advance. I’m saying that arrays and maps give good bang for the buck, so you don’t really need to define anything beyond those. And if you accept that, having special syntax for arrays and maps is more convenient and readable than S-exprs.

    (menu
      (id file)
      (value File)
      (popup
        (item (value New) (onclick "CreateNewDoc()"))
        (item (value Open) (onclick "OpenDoc"))
        (item (value Close) (onclick "CloseDoc()"))))

    {"menu": {
      "id": "file",
      "value": "File",
      "popup": {
        "menuitem": [
          {"value": "New", "onclick": "CreateNewDoc()"},
          {"value": "Open", "onclick": "OpenDoc()"},
          {"value": "Close", "onclick": "CloseDoc()"}
        ]
      }
    }}

Post by noisy_boy » Tue, Aug 24, 2021, 6:04 AM UTC

__MatrixMan__ wrote: post #144

noisy_boy wrote: post #117

Earlier quoted context omitted.

Typically informational messages/log message. Ideally yes logging should go to stderr but some applications that intercept the file descriptors consider anything to stderr as error and it is not always possible to change the handling for those applications. E.g. Octopus Deploy[0] does this: it doesn't outright fail the step assuming other "successful" steps happen after that but if the last command writes to stderr,…

I guess I just wanted to be on a high horse and declare that anybody who puts something other than what you asked for on stdout is doing it WRONG. But you're right, fixing the universe to fit the convention isn't always in the cards. If I could design it all from scratch I'd have a convention for getting a program to tell me: - info, user prompts, debug -> stderr - foo data, bar data -> stdout That way I could use th…

    set_var() {
        local -n vname=$1   # use nameref for indirection
        # some processing and assign value
        vname="abcd"
    }

    use_var() {
        local output
        set_var output # call function to populate the variable
        echo "output=$output"
        unset -n output
    }

    use_var

Post by asoneth » Tue, Aug 24, 2021, 2:49 PM UTC

pjmlp wrote: post #67

u801e wrote: post #63

Earlier quoted context omitted.

But json already has quotes, commas, brackets and braces :-)

Yeah, apparently finding misplaced quotes, commas, brackets and braces is magically easier than misplaced parentheses. :)

Post by lambdaba » Tue, Aug 24, 2021, 8:15 PM UTC

laumars wrote: post #124

lambdaba wrote: post #106

Earlier quoted context omitted.

Are you using one of these exclusively? Which one have you chosen and why?

I use murex exclusively. It’s still beta quality so not totally bug free but the bugs are rarely showstoppers and it’s still in active development so fixes are usually just one GitHub issue away. I don’t use it on servers, I stick with Bash for that. But I do use it as my primary local shell. As for why murex, that’s a combination of personal preference and simply not being aware of other shells until after I’d alrea…