5 ms·

I wonder if this could be accomplished in a more general way with a fourth standard file descriptor for structured data. stdjson basically.

tgv 5y ago
A pipe only conveys stdout. You could redirect 4>&1 1>/dev/null, but you'd have to rewrite all tools to generate both stdout and stdjson anyway.
- oarsinsync 5y ago
  > You could redirect 4>&1 1>/dev/null For anyone confused by this, 1 is the output to stdout, and 4 is being redirected to where 1 goes, which is stdout. Unrelated to that, 1 (what’s actually being output to stout by the application) is being redirected to /dev/null. The order of operations matters. If 1 was redirected to /dev/null first, then 4 would also end up in /dev/null. As it stands now, that doesn’t happen.
  - tgv 5y ago
    Good one. I did look it up before I posted, too. I’m never 100% sure.
  - im3w1l 5y ago
    So you are supposed to read it from right to left? "First take 1 and throw it away. Next put 4 in 1." Is that how it works?
    - kubanczyk 5y ago
      Not quite. Left to right: copy the descriptor 1 onto descriptor 4, change descriptor 1 to result of open("/dev/null"). The >& is for copying the descriptor not for aliasing ("hardlinking") it. The descriptor is the "fd" argument, e.g.: write(int fd, const void *buf, size_t count)
    - vultour 5y ago
      No, it’s like assigning variables. The second part overwrites the value of 1, but the first part is still using the old value.
    - dgrunwald 5y ago
      No, it's from left to right. It's basically just syntax for a series of dup2() calls. "4>&1 1>/dev/null" means: streams[4] = streams[1]; streams[1] = open("/dev/null");
chubot 5y ago
What's wrong with plain old stdout? Lots of people do this with JSON (jq, etc.) and CSV or TSV (csvkit, etc.), XML/HTML, and more. That's how I generate much of the https://www.oilshell.org/ https://www.oilshell.org/ site. It's just a tree of files and various shell commands, some of which I wrote myself. I do think we need something better than CSV and TSV for tabular data though. They both have serious flaws (not being able to represent values with tabs, etc.!)
carlhjerpe 5y ago
I had this thought half a year ago. Anything not to have to parse text make me happy. Though i guess learning to parse command output helps you learn how to parse other text down the line.
xpe 5y ago
I see this as requiring considerable work. For JSON, I don't see the payoff (relative to more expressive type systems). JSON was designed to work within different constraints. All in all, this suggests moving beyond JSON. Sometimes the new ways are best... I often find that redesigns / rewrites can be transformative. The same benefits less often accrue to incremental changes. Practically, in my experience, when a group (or organization) is not under a severe time and budget crunch, redesigns seem more palatable. The results are more likely to be simpler, even if they are not as familiar.

tgv 5y ago

A pipe only conveys stdout. You could redirect 4>&1 1>/dev/null, but you'd have to rewrite all tools to generate both stdout and stdjson anyway.

oarsinsync 5y ago
> You could redirect 4>&1 1>/dev/null For anyone confused by this, 1 is the output to stdout, and 4 is being redirected to where 1 goes, which is stdout. Unrelated to that, 1 (what’s actually being output to stout by the application) is being redirected to /dev/null. The order of operations matters. If 1 was redirected to /dev/null first, then 4 would also end up in /dev/null. As it stands now, that doesn’t happen.
- tgv 5y ago
  Good one. I did look it up before I posted, too. I’m never 100% sure.
- im3w1l 5y ago
  So you are supposed to read it from right to left? "First take 1 and throw it away. Next put 4 in 1." Is that how it works?
  - kubanczyk 5y ago
    Not quite. Left to right: copy the descriptor 1 onto descriptor 4, change descriptor 1 to result of open("/dev/null"). The >& is for copying the descriptor not for aliasing ("hardlinking") it. The descriptor is the "fd" argument, e.g.: write(int fd, const void *buf, size_t count)
  - vultour 5y ago
    No, it’s like assigning variables. The second part overwrites the value of 1, but the first part is still using the old value.
  - dgrunwald 5y ago
    No, it's from left to right. It's basically just syntax for a series of dup2() calls. "4>&1 1>/dev/null" means: streams[4] = streams[1]; streams[1] = open("/dev/null");

chubot 5y ago

What's wrong with plain old stdout? Lots of people do this with JSON (jq, etc.) and CSV or TSV (csvkit, etc.), XML/HTML, and more. That's how I generate much of the https://www.oilshell.org/ https://www.oilshell.org/ site. It's just a tree of files and various shell commands, some of which I wrote myself. I do think we need something better than CSV and TSV for tabular data though. They both have serious flaws (not being able to represent values with tabs, etc.!)

carlhjerpe 5y ago

I had this thought half a year ago. Anything not to have to parse text make me happy. Though i guess learning to parse command output helps you learn how to parse other text down the line.

xpe 5y ago

I see this as requiring considerable work. For JSON, I don't see the payoff (relative to more expressive type systems). JSON was designed to work within different constraints. All in all, this suggests moving beyond JSON. Sometimes the new ways are best... I often find that redesigns / rewrites can be transformative. The same benefits less often accrue to incremental changes. Practically, in my experience, when a group (or organization) is not under a severe time and budget crunch, redesigns seem more palatable. The results are more likely to be simpler, even if they are not as familiar.