On Monday 13 June 2016 06:34:00 Gene Heskett wrote:
> On Monday 13 June 2016 05:21:23 to...@tuxteam.de wrote:
> > On Mon, Jun 13, 2016 at 10:19:46AM +0200, Thomas Schmitt wrote:
> > > Hi,
> > >
> > > Gene Heskett wrote:
> > > > if test ${InMail} = "gene"
> > > > bin/mailwatcher: line 66: test: =: unary operator expected
> > >
> > > The syntax problem is most probably about missing "-quotes around
> > > the variable ecaluation ${InMail} which would have to be empty to
> > > cause the message:
> >
> > Agreed.
> >
> > If I may add something -- one of the most difficult things for shell
> > novices to wrap their head around is the interaction of command line
> > expansion and the commands themselves. This is one of the things
> > which make the shell very powerful [1], but you gotta get used to
> > it.
> >
> > Let's walk through your problem case (note that I'm restating
> > what Thomas said. It's just I know it's difficult and bears some
> > repeating :)
> >
> > You wrote:
> >
> > test ${InMail} = "gene"
> >
> > Now the shell gets a first chance at it. Suppose ${InMail} is empty.
> > After variable expansion, you got:
> >
> > test = "gene"
> >
> > (${InMail} was empty, so it gets replaced by nothing). Now that's
> > what the "if" gets fed with. It responds with "Eek! You told me
> > to compare *two* things and there's just one!
> >
> > One could argue "unary operator expected" is a strange way to
> > restate this. I didn't check, but I guess we're seeing too
> > deep into the bowels of if's parser.
> >
> > The solution is, as Thomas said, to put ${InMail} in double quotes.
> > It almost always is. The better solution is, of course: always
> > try to mentally follow what happens: first, expansion; then command.
> >
> > regards
> >
> > [1] "expressive" might be the more correct term.
> >
> > -- tomás
>
> In any event a pair of "" around the left argument silenced the
> warning, and it still works. However it may be that inotifywait is
> premature, as I see that InMail occasionall contains a hash name of
> the order of: + test _KQG,TdoXXB.coyote = gene
> + test _KQG,TdoXXB.coyote = gene-from_linda
> + test _KQG,TdoXXB.coyote = amanda
>
> which of course fails all 3 tests, and if I look a couple seconds
> later, there is no such file in that directory. So I'm assuming the
> mailfile is being appended under a hashed up name & the real named
> file is nuked, and the merged result is then renamed to its correct
> name. But thats just a swag, and we all know what a swag is. ;-)
>
> In any event, an incoming may be undetected until the magic of time
> actually returns the correct name, perhaps on the next message. It
> seems to be, as I observe it, a pattern of every 3rd access to that
> directory. There is of course no such pattern in the incoming mail.
>
> Perhaps this needs a more exacting look. But with what tool?
>
> Cheers, Gene Heskett
The script I just posted now has its trace thru one incoming email that
looks like this
===================
++ /usr/bin/inotifywait -q -e close_write --format %f /var/spool/mail/
+ InMail=gene
+ test gene = gene
+ /opt/trinity/bin/dcop kmail KMailIface checkMail
+ sleep 2
+ date -R
+ echo gene
++ pidof -s kmail
+ '[' 5179 ']'
++ /usr/bin/inotifywait -q -e close_write --format %f /var/spool/mail/
==================
Which is just what I was trying to write. ;-)
I believe I can nuke the set -x in line 2 now.
Many Thanks to all who replied.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
