Hi Denis,

Try something like the script below.
It uses a lock to detect its own invocation as well as multiple
invocations of self. If it prints it backs up the printed file, so you
should not lose anything, should things go south.

Note: I did not properly test it. So, give it good pass over and test
it before calling it a day. As I said, it should not loose any print
files and you should know if it prints.

Please insert your own print command instead of the echo "" and
redirect the output to a log file or /dev/null so it does not end up
with incron.

Beware of broken script lines by the email.

I hope that it works as intended or as an example,
Tomas

#!/bin/bash
##########################################
# This command submits a file to print
# It is triggered by incron and tries to
# gracefully deal with multiple incron invocations
# and waits for file to be closed by the
# print application.
# Example incron line:
# printDirToMonitor IN_CLOSE_WRITE submitPrinterJob.bash $#
##########################################
lockDir=/tmp/
lockFileBaseName=/tmp/submitPrinterJob
thisPid=$$
fileToPrint=$1
printedFilesDir=/home/$USER/printedFilesDir
mkdir -p $printedFilesDir

searchLockPattern="${lockFileBaseName}_${fileToPrint}_*.lock"
myLockFileName="${lockFileBaseName}_${fileToPrint}_${thisPid}.lock"

# check if the file to print is still there
if [ -e $fileToPrint ]; then
  # Check if another script is running and serving this file
  # Issue lock if not
  c=0
  while (( $c < 2 )); do
    if [ ! -e $searchLockPattern ]; then
      # Cannot see any other process'lock
      touch $myLockFileName
    else
      # there is a lock
      if [ ! -e $myLockFileName ]; then
        # the lock is not mine --> exit without printing,
        # make sure not to leave own lock, in case it take time to
        # show up
        rm -f $myLockFileName
        exit 0
      fi
    fi
    # There should be a lock and mine --> do nothing , just wait
    c=$(( $c + 1 ))
    sleep 2
  done      
  # if I got here I got a lock --> send the file to printer
  if [ ! -e $fileToPrint ]; then
    echo "WARNING: File $fileToPrint disapeared"
  else
    echo "Printing file $fileToPrint"
    # backing up and removing printed file
    mv $fileToPrint $printedFilesDir
    sleep 1
    # removing lock file
    rm -f $myLockFileName
  fi
fi
exit 0
##########################################

On Sat, 2017-11-18 at 15:01 -0800, Denis Heidtmann wrote:
> It turns out that the multiple file closings is at least partially
> attributable to the application, since another application had two
> closings
> rather than four.  Using the application with the four closings I
> tried
> again with a much more complicated drawing.  This slowed down the
> writing
> of the print file to 10 seconds.  Those 10 seconds were taken up
> mostly
> between the first and second closing (4 sec.) and the third and
> fourth (6
> sec.)  I may need to put a delay at the start of my printing script
> so it
> does not try to print an incomplete file.
> 
> An aside:  The "masks" in the incrontab are separated by comas but no
> spaces are allowed.
> 
> Nothing turns out as simple as it appears initially.
> 
> -Denis
> 
> On Fri, Nov 17, 2017 at 11:38 PM, Tom <tomas.kuchta.li...@gmail.com>
> wrote:
> 
> > 
> > I am glad you worked it out. Well done.
> > 
> > Darn fast computers!!
> > 
> > -T
> > 
> > On Fri, 2017-11-17 at 18:04 -0800, Denis Heidtmann wrote:
> > > 
> > > On the "Create":  this convinces me that I should take up
> > > drinking
> > > coffee,
> > > so some stronger brain stimulant. Dumb.
> > > 
> > > On the multiple entries, I think the issue is that my test script
> > > is
> > > very
> > > short and fast.  I added a sleep 10 and I get only one entry--the
> > > first
> > > one.  Apparently the print driver (or the program calling it)
> > > closes
> > > the
> > > file multiple times.  I added $% to the incrontab file and %2 to
> > > the
> > > script
> > > (but w/o the sleep in my script) I got:
> > > 
> > > test1 create  test23 IN_CLOSE_WRITE
> > > test1 create  test23.PLT IN_CLOSE_WRITE
> > > test1 create  test23.PLT IN_CLOSE_WRITE
> > > test1 create  test23.PLT IN_CLOSE_WRITE
> > > 
> > > This behavior of the driver/application seems not the best, but
> > > there
> > > is
> > > nothing to be done about it.  I assume that my printing script
> > > will
> > > take
> > > sufficient time it will not matter.
> > > 
> > > I recorded the times associated with the four log entries.  It
> > > was
> > > 347 msec
> > > overall, with the last step taking most of this time at about 300
> > > msec.  So
> > > my anticipation that the multiple writes/closing will not matter
> > > seems
> > > reasonable.  Let's hope so.
> > > 
> > > Thanks again for the suggestion.
> > > 
> > > -Denis
> > > 
> > > On Fri, Nov 17, 2017 at 2:02 PM, Tomas Kuchta <tomas.kuchta.lists
> > > @gma
> > > il.com>
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > If I recall incron details correctly, you get multiple entries
> > > > in
> > > > your log
> > > > because you run your script multiple times at different events:
> > > > IN_CLOSE_WRITE,IN_NO_LOOP
> > > > 
> > > > Your other question: You see "create" in your log because that
> > > > is
> > > > what your
> > > > echo command puts there in your script.
> > > > 
> > > > -Tomas
> > > > 
> > > > On Nov 17, 2017 11:47 AM, "Denis Heidtmann" <denis.heidtmann@gm
> > > > ail.
> > > > com>
> > > > wrote:
> > > > 
> > > > I have pursued Tomas' advice to use incron to automatically
> > > > send
> > > > files
> > > > written by the win2k print driver to the printer.  I have
> > > > everything down
> > > > to one issue.  To test, I have a simple script (intest.sh) that
> > > > just sends
> > > > the event responded to to a log file:
> > > > 
> > > > #! /bin/bash
> > > > # test of incron
> > > > echo "tes1 create " $1 >> /home/denis/incronlog.log
> > > > 
> > > > The incron table is:
> > > > 
> > > > /home/denis/win2kfiles/Print_files IN_CLOSE_WRITE,IN_NO_LOOP
> > > > /home/denis/scripts/intest.sh $#
> > > > 
> > > > The resulting log is:
> > > > 
> > > > tes1 create  test12
> > > > tes1 create  test12.PLT
> > > > tes1 create  test12.PLT
> > > > tes1 create  test12.PLT
> > > > 
> > > > It generates multiple entries for one file added (i.e., one
> > > > print
> > > > command).  I added  IN_ONESHOT to the incrontab:
> > > > 
> > > > /home/denis/win2kfiles/Print_files
> > > > IN_CLOSE_WRITE,IN_ONESHOT,IN_NO_LOOP
> > > > /home/denis/scripts/intest.sh $#
> > > > 
> > > > I still got multiple entries in the log.
> > > > 
> > > > 
> > > > Questions:
> > > > Why does the log not say "close" instead of "create"?
> > > > Why four entries?
> > > > What might the result be when the script intest.sh is replaced
> > > > by
> > > > one that
> > > > prints and deletes the files?  Will it be called 4 times in
> > > > rapid
> > > > succession?
> > > > 
> > > > Any suggestions for testing further?
> > > > 
> > > > Thanks,
> > > > -Denis
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > PLUG@pdxlinux.org
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > PLUG@pdxlinux.org
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > 
> > > _______________________________________________
> > > PLUG mailing list
> > > PLUG@pdxlinux.org
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > _______________________________________________
> > PLUG mailing list
> > PLUG@pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> > 
> _______________________________________________
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
_______________________________________________
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Reply via email to