The environment variable isn't much better, both are akin to using a global var in your reentrant code, but at least STDDATA_FD is less likely to collide than 3.

Can't wait for scripts using this variable for something unrelated to break when they call my scripts.

This should be a parameter or argv[0]-based.

▲

bcrl a day ago | parent [-]

That doesn't work reliably either. No existing code scrubs STDDATA_FD from their environment variables, and there's no way to know if anyone uses STDDATA_FD in the wild. Why not just use a command line parameter like everyone else? Different isn't better in a situation like this.

This is a larger concern I've started to see in a certain class of younger developer where existing conventions are just ignored without an attempt at understanding of why they exist. Things are only going to get worse as naive vibe coders start flinging more AI generated garbage out into the world. I pity the pole folks trying to maintain these systems a couple of decades from now.

▲

veltas a day ago | parent [-]

That's what I really meant by saying a parameter, it should be an option/flag that's given explicitly at invocation, or just a different program name.

▲

kps a day ago | parent [-]

Just go for `--json-output=filename` rather than playing games.

▲

8n4vidtmkvmk 18 hours ago | parent [-]

Why filename? It doesn't need to know how to write files. That's what Greater than is for. Do --output=json

▲

kps 10 hours ago | parent [-]

It seemed that the author wants to write JSON in addition to regular output.

	▲	8n4vidtmkvmk an hour ago \| parent [-]
		Oh.. ya ok I guess you need to specify where to direct each output then. Kind of a weird use case. If it's not slow to process, you can usually just call the program twice.