Re: nother bash question
On Monday 13 June 2016 05:21:23 tomas@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
--
"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>
Reply to: