To make this work, I need to use the Bash network extensions. Built into Bash is a virtual file system for creating network sockets: /dev/tcp/host/port. Just open the file with the appropriate protocol/host/port, and you're good to go. Be aware that while this was added in Bash 2.04, it's a compile-time option, and the version of Bash included with some distributions might not support this.
So obviously, I was able to get this to work, or I wouldn't be writing this. Here's the script:
#!/bin/bash # # A Bash-only telnet client # # Options: # $1 host name # $2 port (default 23) # read_write_one_char() { IFS=$'\n' # tell read to treat all non-newline characters the same while true; do read -r -n 1 -t 0.01 C STATUS=$? if [ ${STATUS} != 0 ]; then if [ ${STATUS} -gt 128 ]; then # Read returns 142 on timeout return 0 # Normal exit fi return 1 # EOF or other problem fi if [ -z "${C}" ]; then echo "" else echo -n "${C}" fi done } do_io() { while true; do read_write_one_char 0<&3 || break read_write_one_char 1>&3 || break done } PORT="$2" if [ -z "$PORT" ]; then PORT=23 fi exec 3<>/dev/tcp/$1/${PORT} do_io exec 3>&-
exec 3<&-
So how does this work?
The last four lines have three uses of 'exec'. The syntax of the 'exec' command is rather counterintuitive--it's essentially overloading the command with something that doesn't exec a new binary. It's opening a socket for read and write to file descriptor 3, and then closing it when the work is done. Note that while you open the socket for read and write with a single call, you have to close read and write separately.
The real work is in the function read_write_one_char(). This function uses the Bash built-in command 'read' to read one byte from stdin and copy it to stdout. Here we run into some significant limitations in Bash for handling I/O. I would like to be able to do a binary read into a string, the write it out, which is essentially what I'm doing. Unfortunately, Bash tries really hard to be working with words separated by whitespace, not binary data. The internal variable 'IFS' defines what it considers to be whitespace, so I have to override that to be just newline (using a Bash syntax for specifying non-ASCII constants).
The read command returns a non-zero status if it times out that is greater than 128 (142 in my testing, but I wouldn't rely on that). If it returns any other non-zero status, the script assumes it's an end-of-file indication.
When echoing the character that was read out, we are again bitten by the shell's insistence on working with words and whitespace, so the script has to undo that by treating an empty read as having read whitespace (which is only a newline, having overridden IFS as mentioned above).
The read has a timeout of a hundredth of a second so that the same thread can switch between reading the console and the network. It's within a loop, however, so that if a burst of characters comes in, it will read until it times out before switching to the other input.
That's it.
The script works rather nicely for simple tasks. It could easily be extended to handle some things like \r\n sequences and things like that. Extending it to read more than one character at a time would improve performance. More importantly, it could easily save text read from the network for matching against patterns just like 'expect' does.
One thing that is particularly cool about this script is that it's all pure Bash. Every command that it uses is built-in. There is not a single subprocess being forked. Just echo, read, test ([), and true.
The last four lines have three uses of 'exec'. The syntax of the 'exec' command is rather counterintuitive--it's essentially overloading the command with something that doesn't exec a new binary. It's opening a socket for read and write to file descriptor 3, and then closing it when the work is done. Note that while you open the socket for read and write with a single call, you have to close read and write separately.
The real work is in the function read_write_one_char(). This function uses the Bash built-in command 'read' to read one byte from stdin and copy it to stdout. Here we run into some significant limitations in Bash for handling I/O. I would like to be able to do a binary read into a string, the write it out, which is essentially what I'm doing. Unfortunately, Bash tries really hard to be working with words separated by whitespace, not binary data. The internal variable 'IFS' defines what it considers to be whitespace, so I have to override that to be just newline (using a Bash syntax for specifying non-ASCII constants).
The read command returns a non-zero status if it times out that is greater than 128 (142 in my testing, but I wouldn't rely on that). If it returns any other non-zero status, the script assumes it's an end-of-file indication.
When echoing the character that was read out, we are again bitten by the shell's insistence on working with words and whitespace, so the script has to undo that by treating an empty read as having read whitespace (which is only a newline, having overridden IFS as mentioned above).
The read has a timeout of a hundredth of a second so that the same thread can switch between reading the console and the network. It's within a loop, however, so that if a burst of characters comes in, it will read until it times out before switching to the other input.
That's it.
The script works rather nicely for simple tasks. It could easily be extended to handle some things like \r\n sequences and things like that. Extending it to read more than one character at a time would improve performance. More importantly, it could easily save text read from the network for matching against patterns just like 'expect' does.
One thing that is particularly cool about this script is that it's all pure Bash. Every command that it uses is built-in. There is not a single subprocess being forked. Just echo, read, test ([), and true.
