Question: The code is:

```
at -k $wval <<ENDMARKER

while [[ -s Usr_List ]]; do
    for i in $(cat Usr_List); do
        if finger -m | grep $i; then
            echo "$i is online" | elm $mval
            sed "/$i/d" <Usr_List >tmplist
            mv tmplist Usr_List
        fi
     done
done

ENDMARKER

```

Looking at the actual at job, it is

```
while [[ -s Usr_List ]]; do
    for i in jim
joe 
tim; do
        if finger -m |grep ; then
            echo " is online" | elm jack
            sed "//d" <Usr_List >tmplist
            mv tmplist Usr_List
        fi
     done
done

```

jim joe and tim are the names on the list Usr\_List

It seems like the cat Usr\_List and the $i are the problem but I am not sure how to fix this.

Thanks

EDIT:
The at job sends an email saying that jim was unexpected.

Answer: 
Let's suppose data written to the socket would be guaranteed to arrive. This would mean that the TCP stack would have to wait *after every packet* for confirmation.

Clearly, this is not how it works.

TCP does not guarantee arrival except when you have successfully closed the connection. Only then you know everything was received.

You probably need to establish a resume protocol in the application layer. Ask the other side how far you got in the first connection.

A lot of discussion in the comments leads me to the following clarification: If the connection gets interrupted, the sender can not reliably know how many bytes were received by the other side. He will reliably know *that* not everything was received but not *what* was received.
There are a few options. One way would probably be to manually flush the data down the pipe on your `NetworkStream` after each batch of data written.

Whilst this may be seen as a performance sticking point, depending on your type of application, it will be the most fault-tolerant way to do it. By manually calling `.Flush()`, you're going to know whether the data was successfully sent down the pipe or not.

If you're doing this in batches from your `MemoryStream` into the `NetworkStream`, you can store the 'last written bytes', and be able to put them back into your `MemoryStream`, ready to be re-attempted when the connection is re-established.

Another option would be to implement your own protocol, upon connection, immediately send to the client how many bytes the server has received to date (ie. since the last connection). When you have this information, you can clear out the first X bytes of your `MemoryStream` (the ones that have already been sent), and continue pushing down the rest of the data.

One final thing you could do, which may be the best way, is a combination of the two. Basically implement a send/acknowledge protocol. This means, you will send a chunk of data, and wait for the server to send back an ACK/OK. When it does, you can be sure that the server has received this data, but if it doesn't, you can keep retrying until you get that ACK.