Comment 6 for bug 215034

Another request to fix this. It is a really simple fix, it only needs to remove the "--disable-net-redirections" configure option added by Debian and bring bash closer to what it was intended to be by its developers.

The Debian maintainer gave this justification in /usr/share/doc/bash/README.Debian.gz :

    9. Why is bash configured with --disable-net-redirections?
        It can produce completely unexpected results. This kind of
        feature should not be part of a shell but a special tool. And
        that tool has existed for years already, it's called netcat.

In my opinion, this is completely unreasonable.

The first argument, that "It can produce completely unexpected results" is just plain wrong. It is precisely documented, the names were chosen in order to not conflict with real files (no known unix system have "/dev/tcp" or "/dev/udp" hierarchies), and is part of the expected features of bash.

The second argument, that "This kind of feature should not be part of a shell but a special tool." is also invalid. Anyone who used both netcat and bash net redirection knows that this bash feature is much more flexible than netcat. Using netcat you can't access both input and output channels easily due to limitations on how shell pipelining works. You can easily redirect the input from a file, process or subshell, and you can easily redirect the output to another file, process or subshell. But it is insane to get both input and output of a process in the parent process using only common shell redirections. This severely limits what can be done with netcat, and is the very reason why bash implemented this feature.

Bash net redirection allows that, very easily:

    exec 99<>/dev/tcp/server/port
    echo >&99 "Message 1"
    read -u 99 response1; echo $response1
    echo >&99 "Message 2"
    read -u 99 response2; echo $response2
    echo 99>&-

The origin of this bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65172 , has a really ridiculous discussion, IMO. The report was about an unrelated issue, they freaked out that bash was too bloated, then with what happens if the user has something under /dev/tcp (ignoring that it doesn't make any sense to have anything there, it was chosen for this reason, and that the user is not supposed to make such kinds of modifications to the system), and then it was decided that disabling the feature would solve the bug.

If the user gets himself to a bash shell, he is probably smart enough to deal with bash features, and would probably make very good use of them. There were very strong reasons for this feature to be added to bash, and a very dumb arguments for it to be originally disabled in Debian.