Re: nother bash question

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> ++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/

>From the man page i learn that you let it watch the whole directory.
This way you get notifications about any file in there.

The empty variable content possibly stems from this feature:
  "-format <fmt>
   ...
   %f
   When an event occurs within a directory, this will be replaced with
   the name of the File which caused the event to occur. Otherwise,
   this will be replaced with an empty string."
But i have difficulties to imagine which "close" event could happen
outside the directory and would still be noticed.

It looks like you can avoid this condition by formatter %w and by
watching only those mailbox files which you are interested in.
I'd try this

  /usr/bin/inotifywait -q -e close --format %w \
                       /var/spool/mail/gene \
                       /var/spool/mail/gene-from_linda \
                       /var/spool/mail/amanda

If InMail then contains full paths, like

  /var/spool/mail/amanda

i'd process them by command "basename":

  InMail=$(basename "$InMail")


But it seems you have blind time periods in your loop, during which
inotifywait is not on guard and thus would not catch events.
Not very reliable.

Maybe you should additionally check the mtime stamps of the mailbox
files and record them in little data files:

  stamp=$(stat --format=%Y /var/spool/mail/gene)
  if test "$stamp" -gt "$(cat "$HOME"/timestamp_gene)"
  then
     ... something changed in /var/spool/mail/gene ...
  fi

I have no proposal yet how to avoid processing the mailbox files
while the fetcher programs are still operating on them.
(This race condition arises already with your reaction on a reply
 from inotifywait.)


In a newer mail from Gene:
> fetchmail fires off a session of mailfilter, which can nuke undesirables
> on the server so fetchmail never sees them, then fetchmail does the 
> pulling, hands it off to procmail for some deaths and diversions, and 
> puts what survives into one of 4 named files in /var/spool/mail/

And you cannot talk any of the participants into performing the
actions of $Cmd when it knows that the data are ready and no other
participant is manipulating them ?

------------------------------------------------------------------------

Some shell nitpicking:

> # I've found that stderr needs dumped to /dev/null, so
> InMail=`/usr/bin/inotifywait -q -e close_write --format %f ${WatchDir}` 2>&1 >/dev/null

This line consumes stdout of inotifywait, redirects stderr of the empty
command after the variable assignment to stdout, and redirects original
stdout to /dev/null. (So if there was stderr output outside the ``-quotes
it would be shown on stdout.)
stderr of inotifywait is not redirected by this line.
See this example which puts "a" on stdout and "b" on stderr:

  $ x=`echo a ; echo b >&2` 2>&1 >/dev/null
  b
  $ echo "$x"
  a

Your comment suggests you want something like

  InMail=`/usr/bin/inotifywait -q -e close_write --format %f ${WatchDir} 2>/dev/null`

which redirects stderr of inotifywait to /dev/null.
Since there is no command after the variable assignment, there is no
need to redirect its output.

------------------------------------------------------------------------

Have a nice day :)

Thomas