ot: mail flag for attachment in unix

[Fairlight]

Confusious (Dennis Malen) say:
> Here's the last conundrum. What I now wanted to do was to send a script that 
> attaches a file to the email and also writes a message in the body of the 
> email.
> 
> I attempted to use:
> 
> uuencode /tmp/emccx.xls emcc.xls | mail -s "test3" dmalen at malen.com <tryftp
> 
> If I use the right side of the pipe separately it places the contents of 
> "tryftp" in the body. If I use the full line without the "<tryfile" it 
> attaches "emcc.xls" to the email.
> 
> When I try the entire line above, the right side of the pipe wins and just 
> places the contents of "tryftp" in the body of the email without any 
> attachment.
> 
> Am I precluded from combining the two sides in UNIX this script or anything 
> like it?

Yes.

You don't understand something fundamental about STDIN (standard input).
I'll illustrate:

A pipe sends the results of a command to the STDIN file descriptor
of the command following the pipe.

An inward redirect sends the contents of the file that follows the redirect
to the STDIN file descriptor of the command to which it redirects.

If you use the pipe -and- the redirect, you're effectively overloading
STDIN.  So which wins?

I cobbled up the following:

#!/usr/bin/perl
print(<>);
exit;

All that tiny script does is print the STDIN stream to the screen.  Now
here are my tests:

[shell1] [~] [10:08pm]: echo "test" |teststdin
test

[shell1] [~] [10:08pm]: teststdin <blip
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
print "Content-type:text/html\n\n";
print "hello world";

[shell1] [~] [10:09pm]: echo "test" |teststdin < blip
Ambiguous input redirect.

As you can see, it works properly when you do one or the other.  Now, if
you have a -sane- shell like tcsh (hush, you anti-csh-ites!), it should
keep you from doing what you're doing and trap it as a boneheaded move.
Obviously your shell is not sane enough to reject the ambiguous conflicting
uses of a pipe and an inward redirect.  It's not alone.  For what it's
worth, I'm using tcsh.  I tried this under straight Bourne shell, and also
ksh and bash on Solaris, and in all three cases the redirect wins.  I tried
it under zsh, and that printed first the pipe results, then the redirect
results, one after one another--the only one to honour both streams.

The method of handling this attempt appears to be highly shell-dependant
(as one would expect, as you're dealing with shell metacharacters), and you
have to test your shell to see what it does.

However...

What you're trying to do is essentially jam two equally sized round pegs
into one round hole of the size of one of the pegs.  "No can do," in most
cases.  Even if it works in some fashion, it's certainly not something one
would put into the "best practises" category.  

The reason tcsh (properly so, IMNSHO) rejects it as ambiguous, instead
of erroneously giving priority to one or the other, is because it -is-
ambiguous.  You have a redirect at the end of a pipeline.  That pipeline
encompasses multiple commands.  Which command is the redirect actually
meant for?  It could be argued that the redirect should belong to the last
command in the pipeline, the first command, or that multiple redirects
should be allowable, one set (in and out) in any one segment of the
commandline (I would never want to see such a command pipeline...ugh!).
Since the whole concept of overloading STDIN that way is a bad idea, I
think calling it ambiguous is the best move.  But that'd turn into a
religions shell war. :)

Short version:  Don't Do That.

mark->