Pretty much every system out there drags a significant baggage of shell-scripts along. Yet there's been barely any improvement on the arcanest of all syntaxes. We keep on painstakingly reinventing ever the same control structures (half-broken lockfile mechanisms, retry loops, miserable support for pid/pgroups, awkward subprocess/fd handling etc. etc.) because for some reason nobody bothers to finally bake them into the shell.

It's become so bad that most teams seem to resort to using a different scripting language for complex tasks nowadays. But that comes with its own hairball of problems and imho the de-facto shell-scripting language simply should not fall behind its own problem domain so far that the preferred approach becomes to not use it.

As an example, this works in bash 3.2 but not 4.0:

    diff <(awk '{print $1, $3}' file{1,2})

    diff <(awk '{print $1, $3}' file1) <(awk '{print $1, $3}' file2)

    diff <(awk '{print $1, $3}' file1 file2)

Well, the same way that everyone else does it: by versioning.

The simplest approach would be to have /bin/bash2, /bin/bash3 etc., with /bin/bash defaulting to the last (current) unversioned bash release.

Then when you write a script that depends on a new feature you'd reference #!/bin/bash3 or whatever. More complex schemes are possible but probably not needed here. It's not rocket science.

And as your example illustrates: This kind of versioning is actually needed even in the current (almost stale) development-mode of bash. Its absence is the reason why many people still target sh as the lowest common denominator...

read line <&456

To see what you got:

echo $line

EDIT: Ah, this is truly a Bash feature, some sort of internal hackery. It doesn't depend on the actual existence of tcp or udp devices.