This blog post is about our current EV3 robot we're planning to use in the 2023/2024 FLL competition. Some features: 2 large motors for steering. 2 medium motors for attachments. 2 colour sensors for picking up the white and black lines, also used for line squaring. 1 gyro sensor. To enable attachments to be changed as quickly as possible we're using gravity to keep the gears connected, i.e. you don't need to fasten anything to the robot. Every attachment has 2x 12 tooth double bevel gear (part 32270) which comes in contact with the 2x 20 tooth double bevel gears (part 32269) on the robot. The medium motors are horizontally aligned on the robots, but we use 12 tooth double bevel gears to convert that to vertical alignments. These in turn are connected to 20 tooth double bevel gears, and the attachments in turn connect to these 20 tooth double bevel gears with their 12 tooth double bevel gears. The complete robot is modelled in Bricklink Studio 2 . You can download the rob
It is possible to send emails directly from a bash script instead of using a third party email program.
My first attempt was to use netcat to send data to the SMTP server. Netcat does almost the same as telnet, but telnet doesn't support input redirection (i.e. you can't send commands from a text file to the client - you have to manually type it).
The problem with netcat is that it sends everything in a block - instead of waiting for a response from the server before sending the next command. In most cases it will work, but I did get instances where the email was not sent.
Bash has a feature where you can open a TCP/IP connection directly from a script. It allows you to read & write to it, giving you all you need to interface with a SMTP server.
See the code below for the send_mail procedure I'm using:
#!/bin/bash
send_mail () {
# $1 smtp server
# $2 smtp port
# $3 address from
# $4 address to
# $5 subject
# $6 body
if [ $# -ne 6 ]; then
echo "send_mail needs 6 parameters"
return $false
fi
exec 3<>/dev/tcp/$1/$2
read -u 3 response
echo $response
echo -en "HELO $1\r\n">&3
read -u 3 response
echo $response
echo -en "MAIL FROM: $3\r\n" >&3
read -u 3 response
echo $response
echo -en "RCPT TO: $4\r\n" >&3
read -u 3 reponse
echo $response
echo -en "DATA\r\n" >&3
read -u 3 response
echo $response
echo -en "From: $3\r\nTo: $4\r\nSubject: $5\r\n\r\n$6\r\n.\r\n" >&3
read -u 3 response
echo $response
echo -en "QUIT\r\n" >&3
read -u 3 response
echo $response
exec 3>&-
return $true
}
send_mail "smtp.anywhere.com" 25 "from@anywhere.com" "to@anywhere.com" "Subject" "Body"
My first attempt was to use netcat to send data to the SMTP server. Netcat does almost the same as telnet, but telnet doesn't support input redirection (i.e. you can't send commands from a text file to the client - you have to manually type it).
The problem with netcat is that it sends everything in a block - instead of waiting for a response from the server before sending the next command. In most cases it will work, but I did get instances where the email was not sent.
Bash has a feature where you can open a TCP/IP connection directly from a script. It allows you to read & write to it, giving you all you need to interface with a SMTP server.
See the code below for the send_mail procedure I'm using:
#!/bin/bash
send_mail () {
# $1 smtp server
# $2 smtp port
# $3 address from
# $4 address to
# $5 subject
# $6 body
if [ $# -ne 6 ]; then
echo "send_mail needs 6 parameters"
return $false
fi
exec 3<>/dev/tcp/$1/$2
read -u 3 response
echo $response
echo -en "HELO $1\r\n">&3
read -u 3 response
echo $response
echo -en "MAIL FROM: $3\r\n" >&3
read -u 3 response
echo $response
echo -en "RCPT TO: $4\r\n" >&3
read -u 3 reponse
echo $response
echo -en "DATA\r\n" >&3
read -u 3 response
echo $response
echo -en "From: $3\r\nTo: $4\r\nSubject: $5\r\n\r\n$6\r\n.\r\n" >&3
read -u 3 response
echo $response
echo -en "QUIT\r\n" >&3
read -u 3 response
echo $response
exec 3>&-
return $true
}
send_mail "smtp.anywhere.com" 25 "from@anywhere.com" "to@anywhere.com" "Subject" "Body"
So first it opens a TCP/IP connection to file descriptor 3 with the exec command. Why file descriptor 3? Because unix has the following standard file descriptors:
0: standard input (stdin)
1: standard output (stdout)
2: standard error (stderr)
File descriptor 3 is the first number we can use for our own purpose - but you can safely change that to any other number if you wish.
After opening the connection you can read & write to this file descriptor.
To read we use the read command with -u to read from the specific file descriptor. This will wait for a complete response back from the server (reads a whole line).
To write we do with a normal echo command redirected to file descriptor 3. We use -en to enable interpretation of backslash escapes and to disable the output of a trailing new line. This is because the official SMTP requirements state you need a carriage return (\r) and linefeed (\n) after each command - so we send both (\r\n) after each command.
So after opening the connection, we first read a line from the SMTP server to get the official greeting.
Then we send a HELO command (with username equal to the server address - this usually works, but you'll have to modify if your server needs a username & password). After that we wait for a response back from the server, usually it will send a welcome message. Note that we do NOT check for any errors the server might return - we just assume everything will be OK. For debugging purposes we echo all the server reponse back to the screen, but if you run this as a background process you won't see these messages.
To initiate a new message we send the MAIL FROM command with a valid from email address. Make sure you're using a valid address, if not the server will reject this command.
For recipients we only support one address at this stage with the RCPT TO command. To send it to more recipients you'll need multiple RCPT TO commands.
The actual email contents is sent after a DATA command. This section should contain the SMTP headers (i.e. To, From, Subject lines, but can contain a lot more), an empty line, then the body of the email, terminated by a dot on a seperate line.
The server should then send the email and come back with a response. After that we close the session by issuing a QUIT command, then we close the TCP/IP connection with the exec command.
Known limitations - but these can be addressed:
- No error checking
- Only supports one recipient
- No support for attachments
Comments