On: Q: A faster re-implementaiton of jq written in Rea...

[diggan]

1 is easy to work around (handy tip incoming for any tools that _seem_ to not support stdin but actually do, as stdin is also available as a file in unix):

    echo '{"foo": "bar"}' | query-json ".foo" /dev/stdin

[saagarjha → diggan]

Tools that accept filenames often expect you give them a real file, as they’ll do things on it that may not be supported by the various “it’s a file descriptor pretending to be something on disk” solutions.

[diggan → saagarjha]

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

[ebg13 → diggan]

Anything that seeks, which you can't do on a pipe.

[waterhouse → diggan]

atop parsing its logfiles.

  # Cuts off partway through:
  zcat atop.log.gz | atop -r /dev/stdin | less
  # Works fine:
  zcat atop.log.gz > atop && atop -r atop | less

That said, I agree with your experience that /dev/stdin usually works for programs that read a file straight in.

[aasasd → diggan]

`file` on BSD/OSX has this notice for the option '-s':

> Normally, file only attempts to read and determine the type of argument files which stat(2) reports are ordinary files. This prevents problems, because reading special files may have peculiar consequences.

One example that comes to mind is /dev/urandom, which sucks randomy values out of the entropy pool (at least in Linux)—and the pool can be exhausted, or at least it could back in the day, not sure about now. Other possible cases are things in /proc (though unlikely), and particularly stuff like serial ports—where presumably reading could gobble data intended for some drivers or client software.

[ogdrhr → diggan]

Not the best example here, but try to open a file descriptor in VSCode. I had a scenario where I wanted to diff a file on two different servers with a user-specified diff tool, and certain ones won't even operate in a read-only manner.

[centimeter → diggan]

Seeking doesn’t work on stdin for example. Or mmapping, I imagine

[viraptor → diggan]

Untested, but I expect unzip will fail because it keeps metadata after the files, so needs to seek back. (Unless they detect the pipe and buffer everything instead)

[boomlinde → diggan]

fseek(3) etc, and using stat(2) to determine allocation sizes springs to mind as things you might want to do on a normal file that will not work as expected on a character device.

[chriswarbo → diggan]

I try to avoid the dummy files /dev/stdin, /dev/stdout and /dev/stderr, since I've been bitten when they're not available, or when I hit permission denied errors.

Two examples I can remember off the top of my head:

- Nix build scripts

- OpenMoko

[gpderetta → diggan]

alternatively in bash:

   query-json ".foo" <(echo '{"foo": "bar"}')

[davesnx → diggan]

but indeed, it's a nice workaround!

[davesnx → diggan]

query-json --kind=inline would support reading from stdin, I didn't spend time on the Cmdliner enough!