Your script has things in it that stretch my knowledge of Bash, so
understanding what it does is difficult for me.

I have no experience with file locking.  Is this a standard protocol?
Since the print file is created by a Windows print driver, I wonder if the
locking which is described in the ubuntu docs is reliably applicable.

This is likely a discussion that stretches what is reasonable to attempt
via a forum, since I need considerable education.

I appreciate your efforts.  I will play with it in an attempt to learn what
you are proposing, but do not be surprised if it takes me some time.

-Denis



On Sat, Nov 18, 2017 at 9:17 PM, Tom <[email protected]> wrote:

> 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 <[email protected]>
> > 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
> > > > > [email protected]
> > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > > _______________________________________________
> > > > > PLUG mailing list
> > > > > [email protected]
> > > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > > >
> > > > _______________________________________________
> > > > PLUG mailing list
> > > > [email protected]
> > > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > > _______________________________________________
> > > PLUG mailing list
> > > [email protected]
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > >
> > _______________________________________________
> > PLUG mailing list
> > [email protected]
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> _______________________________________________
> PLUG mailing list
> [email protected]
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug

Reply via email to