3

I have a script that used to work, which relies on sending commands (file names to be processed in fact) to a process listening on a port, using TCP. So I can fire it up and tell it to listen on, say port 9999.

As a quick hack, I would then set up a stream redirect to port 9999 using a command like:

exec 3<> /dev/tcp/127.0.0.1/9999

and then I could run a find command in the directory I wanted to batch process all of my files, like

find . -name "*.xml" -exec printf "$PWD/{} $PWD/{}\r\n" >&3 \;

I hadn't tried this since I upgraded to Lion, but it doesn't work now, giving me a "Bad File Descriptor" response. Anybody have any ideas?

hcayless
  • 133
  • 1
  • 4

1 Answers1

8

Redirection to /dev/tcp and /dev/udp pseudo-files is an optional compile-time feature of Bash which many OS vendors are electing to leave turned off. It would appear Apple has joined the club. You have a few options:

  1. Use Bash's process substitution feature like so: exec 3> >(nc localhost 9999)

    If you're doing this interactively, you will probably want to do this once you no longer want to redirect to a TCP socket: exec 3> /dev/null

    That should cause the nc process spawned to exit.

  2. Compile your own bash with the /dev/tcp and /dev/udp pseudo-file support turned on and use that.

  3. Modify your script to pipe output directly to the nc command instead. This could be a problem if your script redirects output to filehandle 3 multiple times and the listening process doesn't properly handle multiple connection attempts. However, it's also more portable should you find yourself needing to use your script on a system which doesn't provide the Bash shell.

Jeramey
  • 166
  • 1
  • Curious if it's still the case in 2019... Seen posts from 2015/2016 using "/dev/tcp/..." as a way to create backdoors, so maybe they added it back? – JPvRiel Feb 28 '19 at 16:29