dig output differs when sending to terminal vs piping (no IDN)

https://github.com/kellyjonbrazil/jc/discussions/740

@Zegnat said :

That was a lot of information. I am again going to try and only get down to your original problem. I am just trying to recreate whatever issue you are having with jc on the dig output.

I am now testing with:

复制

* Debian 12.15 (from `cat /etc/debian_version`)

* jc 1.22.5 (freshly installed `apt install jc`)

* DiG 9.18.49-1~deb12u2-Debian

* Konsole terminal / xterm-256color

When I try to run your original query:

bash复制

dig ANY ◕‿◕.ST @dns.google | jc --dig -p

I can now confirm that the output includes:

json复制

    "question": {
      "name": "\\226\\151\\149\\226\\128\\191\\226\\151\\149.ST.",
      "class": "IN",
      "type": "ANY"
    },

Full response

Interestingly it looks like this is actually behaviour coming from dig. So this might not be fixable by jc. We can see this in action by switching jc for any other tool, e.g. just cat:

bash复制

dig ANY ◕‿◕.ST @dns.google | cat -

This tells us exactly what dig is piping through. And it is:

复制

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ANY ◕‿◕.ST @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15886
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;\226\151\149\226\128\191\226\151\149.ST. IN ANY

;; AUTHORITY SECTION:
ST.                     1266    IN      SOA     ns1.bahnhof.net. hostmaster.nic.ST. 2511388119 3600 900 1209600 86400

;; Query time: 26 msec
;; SERVER: 8.8.4.4#53(dns.google) (TCP)
;; WHEN: Wed Sep 02 21:31:51 CEST 2026
;; MSG SIZE  rcvd: 107

No IDN!

But when I run without the pipe:

复制

; <<>> DiG 9.18.49-1~deb12u2-Debian <<>> ANY ◕‿◕.ST @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52137
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;◕‿◕.st.                        IN      ANY

;; ANSWER SECTION:
◕‿◕.st.         3600    IN      SOA     ns1.ip❤10.ws. .ip❤10.ws. 2025110538 300 60 420 60
◕‿◕.st.         3600    IN      NS      ns2.ip❤10.ws.
◕‿◕.st.         3600    IN      NS      ns1.ip❤10.ws.
◕‿◕.st.         3600    IN      A       158.69.126.137
◕‿◕.st.         3600    IN      A       147.79.115.130
◕‿◕.st.         3600    IN      MX      10 smtp.◕‿◕.st.
◕‿◕.st.         10800   IN      TXT     "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"
◕‿◕.st.         3600    IN      AAAA    2607:5300:60:9389::1
◕‿◕.st.         3600    IN      AAAA    2a02:4780:28:5295::1
◕‿◕.st.         10800   IN      SPF     "v=spf1 ip4:158.69.126.137/32 ip6:2607:5300:60:9389:17:4c1:0:1a/128 ~all"

;; Query time: 276 msec
;; SERVER: 8.8.8.8#53(dns.google) (TCP)
;; WHEN: Wed Sep 02 21:33:53 CEST 2026
;; MSG SIZE  rcvd: 418

It seems like there is something in dig that is trying to guess what type of file descriptor it is writing to and then changing what it wants to output.

The jc parsing actually works. If we fool dig into thinking it writes to a terminal and not to a pipe, then jc gives us the correct output:

bash复制

script -q -c "dig ANY ◕‿◕.ST @dns.google" /dev/null | jc --dig -p

Now our JSON has:

json复制

    "question": {
      "name": "◕‿◕.st.",
      "class": "IN",
      "type": "ANY"
    },

Full response