Re: [PLUG] incron issue

[Denis Heidtmann]

I think I got my testing script working.  It is a one-liner which reports
clocktime, file time, and file name.  It turns out that if I use
IN_ALL_EVENTS  without using IN_NO_LOOP, the maximum time between events is
2.5 seconds.  If I include IN_NO_LOOP the maximum time goes to 4.6
seconds.  I see no reason why these times would be shorter when I use
IN_CLOSE_WRITE, as intended.

This is for one application with what I judge to be a large print file.  I
need to explore other applications and files to see if this is worst case.
Your time of 3 x 2 seconds should easily cover it if I do not find a worse
application/file.

-Denis

On Tue, Nov 21, 2017 at 8:38 PM, Tomas Kuchta 
wrote:

> My sample code works like this in principle:
>
> 1. You said 4-ish invocations per print file. That means that there would
> be 4-ish instances of your script running, if I would not use that lock
> file in /tmp to detect that another script instance is already dealing with
> the print file. So, the script starts, looks for another script's lock
> file, if it doesn't find one , it creates own one, waits a bit, checks
> again, and if there is no collision (imagine multiple scripts checking and
> creating locks at the same time) it waits for the print file to become
> stable.
> 2. The print file is considered stable if it is not changed for the
> duration of 3 (I believe) 1 second wait loops. If the file changes, the
> loop counter resets and another 3 set of loops goes by. This way, you do
> not have to wait for the max possible print time, every time. I imagine
> that long or complex document might take long time to print - if we know
> that the printing application updates the file at least every few seconds -
> we reset the timer at every change, re-starting the count down.
> 3. File gets sent to a printer when it is considered stable, and then moved
> to a backup dir under new name consisting of a time stamp + the original
> name. If something goes wrong you can re-print manually. Backed up files
> should sort by its date stamp.
> 4. On exit, the script removes the lock file.
>
> That's about allif I remember correctly.
>
> I guess, you could call that lock file a semafor if that sounds better.
> Alternatively, you could also look for another process instead of keeping
> the lock/semafor file, but that would not allow for multiple files printing
> correctly at the same file.
>
> I hope that it is little clearer.
>
> -T
>
>
> On Nov 21, 2017 7:12 PM, "Denis Heidtmann" 
> wrote:
>
> > Me looking at kernel software would be no more educational than me
> reading
> > about it in Greek.  And  I did not think I wanted to debug the spooler,
> > whatever that is.
> >
> > So to get down to the essentials, using only IN_CLOSE_WRITE, I get four
> > events (with this particular application printing).  For a big print job
> > the timespan from the first event to the last is 10 seconds.  I can
> explore
> > my two other applications and come up with a maximum (probable) time.
> Add
> > a buffer to that and use that time as a delay prior to printing the file.
> > That was my intended approach.
> >
> > As I understand your approach it is to check the time stamp for the file
> in
> > question, delay 2 seconds, then assume if no change has occurred, the
> file
> > is ready to print.  Is this understanding correct?  If so, this assumes
> > that the driver/application changes the file more frequently than every 2
> > seconds.  To explore that, I was trying to send the time to the log every
> > time I got an icron invocation with the IN_ALL_EVENTS mask.  Hence my use
> > of that mask and trying to capture the time to the log.  This, I hope,
> > explains why I wanted to see the result of  > $1)" >> /home/denis/incronlog.log>, and the question of why no time
> appears
> > in the log.  Notice that there are many cases in the log where $1
> appears
> > to be a filename.
> >
> > -Denis
> >
> > On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com>
> > wrote:
> >
> > > Of course that you see some/many invocations without any file names
> when
> > > you trigger on all directory events. All sorts of of processes go by
> all
> > > sorts of directories all the time on modern desktop. Not all of them
> look
> > > at files.
> > >
> > > What your aim is, I believe/hope, to respond to print file write and
> > close
> > > - and send that file to a printer. Ideally deleting or backing that
> file
> > > away from the print dir. You want to do that reliably and without
> > multiple
> > > processes acting on any given file.
> > >
> > > If you want to debug print job spooler, I would suggest to do just
> that.
> > Do
> > > exactly what you need to do, keep it simple, and expand from there.
> > >
> > > If you are curious about kernel interworks, I would suggest to start
> > > looking at kernel documentation and source code - it is more systematic
> > way
> > > of learning. 

Re: [PLUG] incron issue

[Denis Heidtmann]

Thanks for that explanation.  It really helps.  It is basically as I
surmised, but I appreciate the details.

On my attempts to understand the actions of the driver/application, I found
that I had some errors in the paths I used in my test script.  ($1 needed
to be augmented with its full path.)  Now I get the time stamps regularly.

-Denis

On Tue, Nov 21, 2017 at 8:38 PM, Tomas Kuchta 
wrote:

> My sample code works like this in principle:
>
> 1. You said 4-ish invocations per print file. That means that there would
> be 4-ish instances of your script running, if I would not use that lock
> file in /tmp to detect that another script instance is already dealing with
> the print file. So, the script starts, looks for another script's lock
> file, if it doesn't find one , it creates own one, waits a bit, checks
> again, and if there is no collision (imagine multiple scripts checking and
> creating locks at the same time) it waits for the print file to become
> stable.
> 2. The print file is considered stable if it is not changed for the
> duration of 3 (I believe) 1 second wait loops. If the file changes, the
> loop counter resets and another 3 set of loops goes by. This way, you do
> not have to wait for the max possible print time, every time. I imagine
> that long or complex document might take long time to print - if we know
> that the printing application updates the file at least every few seconds -
> we reset the timer at every change, re-starting the count down.
> 3. File gets sent to a printer when it is considered stable, and then moved
> to a backup dir under new name consisting of a time stamp + the original
> name. If something goes wrong you can re-print manually. Backed up files
> should sort by its date stamp.
> 4. On exit, the script removes the lock file.
>
> That's about allif I remember correctly.
>
> I guess, you could call that lock file a semafor if that sounds better.
> Alternatively, you could also look for another process instead of keeping
> the lock/semafor file, but that would not allow for multiple files printing
> correctly at the same file.
>
> I hope that it is little clearer.
>
> -T
>
>
> On Nov 21, 2017 7:12 PM, "Denis Heidtmann" 
> wrote:
>
> > Me looking at kernel software would be no more educational than me
> reading
> > about it in Greek.  And  I did not think I wanted to debug the spooler,
> > whatever that is.
> >
> > So to get down to the essentials, using only IN_CLOSE_WRITE, I get four
> > events (with this particular application printing).  For a big print job
> > the timespan from the first event to the last is 10 seconds.  I can
> explore
> > my two other applications and come up with a maximum (probable) time.
> Add
> > a buffer to that and use that time as a delay prior to printing the file.
> > That was my intended approach.
> >
> > As I understand your approach it is to check the time stamp for the file
> in
> > question, delay 2 seconds, then assume if no change has occurred, the
> file
> > is ready to print.  Is this understanding correct?  If so, this assumes
> > that the driver/application changes the file more frequently than every 2
> > seconds.  To explore that, I was trying to send the time to the log every
> > time I got an icron invocation with the IN_ALL_EVENTS mask.  Hence my use
> > of that mask and trying to capture the time to the log.  This, I hope,
> > explains why I wanted to see the result of  > $1)" >> /home/denis/incronlog.log>, and the question of why no time
> appears
> > in the log.  Notice that there are many cases in the log where $1
> appears
> > to be a filename.
> >
> > -Denis
> >
> > On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com>
> > wrote:
> >
> > > Of course that you see some/many invocations without any file names
> when
> > > you trigger on all directory events. All sorts of of processes go by
> all
> > > sorts of directories all the time on modern desktop. Not all of them
> look
> > > at files.
> > >
> > > What your aim is, I believe/hope, to respond to print file write and
> > close
> > > - and send that file to a printer. Ideally deleting or backing that
> file
> > > away from the print dir. You want to do that reliably and without
> > multiple
> > > processes acting on any given file.
> > >
> > > If you want to debug print job spooler, I would suggest to do just
> that.
> > Do
> > > exactly what you need to do, keep it simple, and expand from there.
> > >
> > > If you are curious about kernel interworks, I would suggest to start
> > > looking at kernel documentation and source code - it is more systematic
> > way
> > > of learning. Unfortunately, I am not the right person to have
> meaningful
> > > conversation about kernel and VFS events/triggers. My knowledge is too
> > > shallow for that.
> > >
> > > Good luck,
> > > Tomas
> > >
> > > On Nov 21, 2017 9:44 AM, "Denis Heidtmann" 
> > > wrote:
> > 

Re: [PLUG] incron issue

[Tomas Kuchta]

My sample code works like this in principle:

1. You said 4-ish invocations per print file. That means that there would
be 4-ish instances of your script running, if I would not use that lock
file in /tmp to detect that another script instance is already dealing with
the print file. So, the script starts, looks for another script's lock
file, if it doesn't find one , it creates own one, waits a bit, checks
again, and if there is no collision (imagine multiple scripts checking and
creating locks at the same time) it waits for the print file to become
stable.
2. The print file is considered stable if it is not changed for the
duration of 3 (I believe) 1 second wait loops. If the file changes, the
loop counter resets and another 3 set of loops goes by. This way, you do
not have to wait for the max possible print time, every time. I imagine
that long or complex document might take long time to print - if we know
that the printing application updates the file at least every few seconds -
we reset the timer at every change, re-starting the count down.
3. File gets sent to a printer when it is considered stable, and then moved
to a backup dir under new name consisting of a time stamp + the original
name. If something goes wrong you can re-print manually. Backed up files
should sort by its date stamp.
4. On exit, the script removes the lock file.

That's about allif I remember correctly.

I guess, you could call that lock file a semafor if that sounds better.
Alternatively, you could also look for another process instead of keeping
the lock/semafor file, but that would not allow for multiple files printing
correctly at the same file.

I hope that it is little clearer.

-T


On Nov 21, 2017 7:12 PM, "Denis Heidtmann" 
wrote:

> Me looking at kernel software would be no more educational than me reading
> about it in Greek.  And  I did not think I wanted to debug the spooler,
> whatever that is.
>
> So to get down to the essentials, using only IN_CLOSE_WRITE, I get four
> events (with this particular application printing).  For a big print job
> the timespan from the first event to the last is 10 seconds.  I can explore
> my two other applications and come up with a maximum (probable) time.  Add
> a buffer to that and use that time as a delay prior to printing the file.
> That was my intended approach.
>
> As I understand your approach it is to check the time stamp for the file in
> question, delay 2 seconds, then assume if no change has occurred, the file
> is ready to print.  Is this understanding correct?  If so, this assumes
> that the driver/application changes the file more frequently than every 2
> seconds.  To explore that, I was trying to send the time to the log every
> time I got an icron invocation with the IN_ALL_EVENTS mask.  Hence my use
> of that mask and trying to capture the time to the log.  This, I hope,
> explains why I wanted to see the result of  $1)" >> /home/denis/incronlog.log>, and the question of why no time appears
> in the log.  Notice that there are many cases in the log where $1  appears
> to be a filename.
>
> -Denis
>
> On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com>
> wrote:
>
> > Of course that you see some/many invocations without any file names when
> > you trigger on all directory events. All sorts of of processes go by all
> > sorts of directories all the time on modern desktop. Not all of them look
> > at files.
> >
> > What your aim is, I believe/hope, to respond to print file write and
> close
> > - and send that file to a printer. Ideally deleting or backing that file
> > away from the print dir. You want to do that reliably and without
> multiple
> > processes acting on any given file.
> >
> > If you want to debug print job spooler, I would suggest to do just that.
> Do
> > exactly what you need to do, keep it simple, and expand from there.
> >
> > If you are curious about kernel interworks, I would suggest to start
> > looking at kernel documentation and source code - it is more systematic
> way
> > of learning. Unfortunately, I am not the right person to have meaningful
> > conversation about kernel and VFS events/triggers. My knowledge is too
> > shallow for that.
> >
> > Good luck,
> > Tomas
> >
> > On Nov 21, 2017 9:44 AM, "Denis Heidtmann" 
> > wrote:
> >
> > > It is fully my intention to use only IN_CLOSE_WRITE in the final
> version.
> > > I currently am using IN_ALL_EVENTS just to see what the print
> > > driver/application is doing.  In fact, when I first started working on
> > this
> > > I used just IN_CLOSE_WRITE  and saw 4 invocations.  That is what sent
> me
> > > exploring.
> > >
> > > Regarding what is in $1, I see what seems to me to indicate a file name
> > in
> > > $1 *sometimes*.  Why only sometimes?  Here is the test script:
> > > #! /bin/bash
> > > # test of incron
> > > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > > echo "test:  $1 $2" >> 

Re: [PLUG] incron issue

[Denis Heidtmann]

Me looking at kernel software would be no more educational than me reading
about it in Greek.  And  I did not think I wanted to debug the spooler,
whatever that is.

So to get down to the essentials, using only IN_CLOSE_WRITE, I get four
events (with this particular application printing).  For a big print job
the timespan from the first event to the last is 10 seconds.  I can explore
my two other applications and come up with a maximum (probable) time.  Add
a buffer to that and use that time as a delay prior to printing the file.
That was my intended approach.

As I understand your approach it is to check the time stamp for the file in
question, delay 2 seconds, then assume if no change has occurred, the file
is ready to print.  Is this understanding correct?  If so, this assumes
that the driver/application changes the file more frequently than every 2
seconds.  To explore that, I was trying to send the time to the log every
time I got an icron invocation with the IN_ALL_EVENTS mask.  Hence my use
of that mask and trying to capture the time to the log.  This, I hope,
explains why I wanted to see the result of > /home/denis/incronlog.log>, and the question of why no time appears
in the log.  Notice that there are many cases in the log where $1  appears
to be a filename.

-Denis

On Tue, Nov 21, 2017 at 1:37 PM, Tomas Kuchta 
wrote:

> Of course that you see some/many invocations without any file names when
> you trigger on all directory events. All sorts of of processes go by all
> sorts of directories all the time on modern desktop. Not all of them look
> at files.
>
> What your aim is, I believe/hope, to respond to print file write and close
> - and send that file to a printer. Ideally deleting or backing that file
> away from the print dir. You want to do that reliably and without multiple
> processes acting on any given file.
>
> If you want to debug print job spooler, I would suggest to do just that. Do
> exactly what you need to do, keep it simple, and expand from there.
>
> If you are curious about kernel interworks, I would suggest to start
> looking at kernel documentation and source code - it is more systematic way
> of learning. Unfortunately, I am not the right person to have meaningful
> conversation about kernel and VFS events/triggers. My knowledge is too
> shallow for that.
>
> Good luck,
> Tomas
>
> On Nov 21, 2017 9:44 AM, "Denis Heidtmann" 
> wrote:
>
> > It is fully my intention to use only IN_CLOSE_WRITE in the final version.
> > I currently am using IN_ALL_EVENTS just to see what the print
> > driver/application is doing.  In fact, when I first started working on
> this
> > I used just IN_CLOSE_WRITE  and saw 4 invocations.  That is what sent me
> > exploring.
> >
> > Regarding what is in $1, I see what seems to me to indicate a file name
> in
> > $1 *sometimes*.  Why only sometimes?  Here is the test script:
> > #! /bin/bash
> > # test of incron
> > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > echo "test:  $1 $2" >> /home/denis/incronlog.log
> >
> > I get perhaps 270 invocations with IN_ALL_EVENTS.  A sampling shows some
> > responses with the file name, but no times:
> >
> > test:   IN_ACCESS,IN_ISDIR
> > time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> > time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> > time: test:  tst1.PLT IN_OPEN
> > time: time: test:  tst1.PLT IN_OPEN
> > test:  tst1.PLT IN_OPEN
> > time: test:  tst1.PLT IN_CLOSE_NOWRITE
> > time: test:  tst1.PLT IN_ACCESS
> > time: test:  tst1.PLT IN_CLOSE_NOWRITE
> > time: time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> > test:   IN_ACCESS,IN_ISDIR
> > time: test:  tst1.PLT IN_CLOSE_NOWRITE
> >
> > There are a number of questions raised by this, but I expect that most
> can
> > be explained by the rapid multiple invocations.  Does that also explain
> the
> > missing times?
> >
> > -Denis
> >
> >
> > On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com
> > > wrote:
> >
> > > $(some command) will simply execute the command and give return value.
> > >
> > > You do not see any time stamp because you are not giving stat a file.
> $1,
> > > in
> > > your case, doesn't contain file name.
> > >
> > > I have asked or suggested before to only use IN_CLOSE_WRITE event. That
> > is
> > > what you want - run the script after the file/dir was written to and is
> > > closed. Not the other times when you look at it or read the file with
> > your
> > > script. Taking those other events off should solve the multiple
> > invocation
> > > problem.
> > >
> > > I hope it helps,
> > > Tomas
> > >
> > >
> > > On Nov 20, 2017 5:54 PM, "Denis Heidtmann" 
> > > wrote:
> > >
> > > Working my way through the script, trying to understand the behavior.
> > Here
> > > is a simple test:
> > >
> > > #! /bin/bash
> > > # test of incron
> > > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > > echo "test:  $1 $2" >> 

Re: [PLUG] incron issue

[Tomas Kuchta]

Of course that you see some/many invocations without any file names when
you trigger on all directory events. All sorts of of processes go by all
sorts of directories all the time on modern desktop. Not all of them look
at files.

What your aim is, I believe/hope, to respond to print file write and close
- and send that file to a printer. Ideally deleting or backing that file
away from the print dir. You want to do that reliably and without multiple
processes acting on any given file.

If you want to debug print job spooler, I would suggest to do just that. Do
exactly what you need to do, keep it simple, and expand from there.

If you are curious about kernel interworks, I would suggest to start
looking at kernel documentation and source code - it is more systematic way
of learning. Unfortunately, I am not the right person to have meaningful
conversation about kernel and VFS events/triggers. My knowledge is too
shallow for that.

Good luck,
Tomas

On Nov 21, 2017 9:44 AM, "Denis Heidtmann" 
wrote:

> It is fully my intention to use only IN_CLOSE_WRITE in the final version.
> I currently am using IN_ALL_EVENTS just to see what the print
> driver/application is doing.  In fact, when I first started working on this
> I used just IN_CLOSE_WRITE  and saw 4 invocations.  That is what sent me
> exploring.
>
> Regarding what is in $1, I see what seems to me to indicate a file name in
> $1 *sometimes*.  Why only sometimes?  Here is the test script:
> #! /bin/bash
> # test of incron
> echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> echo "test:  $1 $2" >> /home/denis/incronlog.log
>
> I get perhaps 270 invocations with IN_ALL_EVENTS.  A sampling shows some
> responses with the file name, but no times:
>
> test:   IN_ACCESS,IN_ISDIR
> time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> time: test:  tst1.PLT IN_OPEN
> time: time: test:  tst1.PLT IN_OPEN
> test:  tst1.PLT IN_OPEN
> time: test:  tst1.PLT IN_CLOSE_NOWRITE
> time: test:  tst1.PLT IN_ACCESS
> time: test:  tst1.PLT IN_CLOSE_NOWRITE
> time: time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
> test:   IN_ACCESS,IN_ISDIR
> time: test:  tst1.PLT IN_CLOSE_NOWRITE
>
> There are a number of questions raised by this, but I expect that most can
> be explained by the rapid multiple invocations.  Does that also explain the
> missing times?
>
> -Denis
>
>
> On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com
> > wrote:
>
> > $(some command) will simply execute the command and give return value.
> >
> > You do not see any time stamp because you are not giving stat a file. $1,
> > in
> > your case, doesn't contain file name.
> >
> > I have asked or suggested before to only use IN_CLOSE_WRITE event. That
> is
> > what you want - run the script after the file/dir was written to and is
> > closed. Not the other times when you look at it or read the file with
> your
> > script. Taking those other events off should solve the multiple
> invocation
> > problem.
> >
> > I hope it helps,
> > Tomas
> >
> >
> > On Nov 20, 2017 5:54 PM, "Denis Heidtmann" 
> > wrote:
> >
> > Working my way through the script, trying to understand the behavior.
> Here
> > is a simple test:
> >
> > #! /bin/bash
> > # test of incron
> > echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> > echo "test:  $1 $2" >> /home/denis/incronlog.log
> > # sleep 10
> >
> > It generates what I would expect when executed from the command line:
> > ~/scripts/intest.sh examples.desktop:
> > time: 1464568514test:  examples.desktop
> >
> > But when invoked by incron the line including the time is empty except
> for
> > the word "time:"  The time value is absent.
> > time: time: test:   IN_ACCESS,IN_ISDIR
> > test:   IN_CLOSE_NOWRITE,IN_ISDIR
> > time: test:   IN_ACCESS,IN_ISDIR
> > time: test:   IN_OPEN,IN_ISDIR
> > time: test:   IN_OPEN,IN_ISDIR
> > etc.
> >
> > My knowledge of the use of $, (, ", ',  and  {  is lacking, so I expect
> > that is where the trouble lies.
> >
> > Is the problem obvious?
> >
> > Thanks,
> > -Denis
> >
> > On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta <
> > tomas.kuchta.li...@gmail.com
> > > wrote:
> >
> > > The script I posted does its own locking, so that other copies would
> know
> > > that it is already running and what file it is serving.
> > >
> > > See the lock file being created, checked and removed.
> > >
> > > Tomas
> > >
> > > On Nov 19, 2017 9:10 PM, "Denis Heidtmann" 
> > > wrote:
> > >
> > > > 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 

Re: [PLUG] incron issue

[Denis Heidtmann]

It is fully my intention to use only IN_CLOSE_WRITE in the final version.
I currently am using IN_ALL_EVENTS just to see what the print
driver/application is doing.  In fact, when I first started working on this
I used just IN_CLOSE_WRITE  and saw 4 invocations.  That is what sent me
exploring.

Regarding what is in $1, I see what seems to me to indicate a file name in
$1 *sometimes*.  Why only sometimes?  Here is the test script:
#! /bin/bash
# test of incron
echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
echo "test:  $1 $2" >> /home/denis/incronlog.log

I get perhaps 270 invocations with IN_ALL_EVENTS.  A sampling shows some
responses with the file name, but no times:

test:   IN_ACCESS,IN_ISDIR
time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
time: test:  tst1.PLT IN_OPEN
time: time: test:  tst1.PLT IN_OPEN
test:  tst1.PLT IN_OPEN
time: test:  tst1.PLT IN_CLOSE_NOWRITE
time: test:  tst1.PLT IN_ACCESS
time: test:  tst1.PLT IN_CLOSE_NOWRITE
time: time: test:   IN_CLOSE_NOWRITE,IN_ISDIR
test:   IN_ACCESS,IN_ISDIR
time: test:  tst1.PLT IN_CLOSE_NOWRITE

There are a number of questions raised by this, but I expect that most can
be explained by the rapid multiple invocations.  Does that also explain the
missing times?

-Denis


On Tue, Nov 21, 2017 at 12:23 AM, Tomas Kuchta  wrote:

> $(some command) will simply execute the command and give return value.
>
> You do not see any time stamp because you are not giving stat a file. $1,
> in
> your case, doesn't contain file name.
>
> I have asked or suggested before to only use IN_CLOSE_WRITE event. That is
> what you want - run the script after the file/dir was written to and is
> closed. Not the other times when you look at it or read the file with your
> script. Taking those other events off should solve the multiple invocation
> problem.
>
> I hope it helps,
> Tomas
>
>
> On Nov 20, 2017 5:54 PM, "Denis Heidtmann" 
> wrote:
>
> Working my way through the script, trying to understand the behavior.  Here
> is a simple test:
>
> #! /bin/bash
> # test of incron
> echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
> echo "test:  $1 $2" >> /home/denis/incronlog.log
> # sleep 10
>
> It generates what I would expect when executed from the command line:
> ~/scripts/intest.sh examples.desktop:
> time: 1464568514test:  examples.desktop
>
> But when invoked by incron the line including the time is empty except for
> the word "time:"  The time value is absent.
> time: time: test:   IN_ACCESS,IN_ISDIR
> test:   IN_CLOSE_NOWRITE,IN_ISDIR
> time: test:   IN_ACCESS,IN_ISDIR
> time: test:   IN_OPEN,IN_ISDIR
> time: test:   IN_OPEN,IN_ISDIR
> etc.
>
> My knowledge of the use of $, (, ", ',  and  {  is lacking, so I expect
> that is where the trouble lies.
>
> Is the problem obvious?
>
> Thanks,
> -Denis
>
> On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta <
> tomas.kuchta.li...@gmail.com
> > wrote:
>
> > The script I posted does its own locking, so that other copies would know
> > that it is already running and what file it is serving.
> >
> > See the lock file being created, checked and removed.
> >
> > Tomas
> >
> > On Nov 19, 2017 9:10 PM, "Denis Heidtmann" 
> > wrote:
> >
> > > 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 
> > 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
> > > > 

Re: [PLUG] incron issue

[Tomas Kuchta]

$(some command) will simply execute the command and give return value.

You do not see any time stamp because you are not giving stat a file. $1, in
your case, doesn't contain file name.

I have asked or suggested before to only use IN_CLOSE_WRITE event. That is
what you want - run the script after the file/dir was written to and is
closed. Not the other times when you look at it or read the file with your
script. Taking those other events off should solve the multiple invocation
problem.

I hope it helps,
Tomas


On Nov 20, 2017 5:54 PM, "Denis Heidtmann" 
wrote:

Working my way through the script, trying to understand the behavior.  Here
is a simple test:

#! /bin/bash
# test of incron
echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
echo "test:  $1 $2" >> /home/denis/incronlog.log
# sleep 10

It generates what I would expect when executed from the command line:
~/scripts/intest.sh examples.desktop:
time: 1464568514test:  examples.desktop

But when invoked by incron the line including the time is empty except for
the word "time:"  The time value is absent.
time: time: test:   IN_ACCESS,IN_ISDIR
test:   IN_CLOSE_NOWRITE,IN_ISDIR
time: test:   IN_ACCESS,IN_ISDIR
time: test:   IN_OPEN,IN_ISDIR
time: test:   IN_OPEN,IN_ISDIR
etc.

My knowledge of the use of $, (, ", ',  and  {  is lacking, so I expect
that is where the trouble lies.

Is the problem obvious?

Thanks,
-Denis

On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta  wrote:

> The script I posted does its own locking, so that other copies would know
> that it is already running and what file it is serving.
>
> See the lock file being created, checked and removed.
>
> Tomas
>
> On Nov 19, 2017 9:10 PM, "Denis Heidtmann" 
> wrote:
>
> > 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 
> 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 

Re: [PLUG] incron issue

[Denis Heidtmann]

Working my way through the script, trying to understand the behavior.  Here
is a simple test:

#! /bin/bash
# test of incron
echo -n "time: $(stat -c '%Y' $1)" >> /home/denis/incronlog.log
echo "test:  $1 $2" >> /home/denis/incronlog.log
# sleep 10

It generates what I would expect when executed from the command line:
~/scripts/intest.sh examples.desktop:
time: 1464568514test:  examples.desktop

But when invoked by incron the line including the time is empty except for
the word "time:"  The time value is absent.
time: time: test:   IN_ACCESS,IN_ISDIR
test:   IN_CLOSE_NOWRITE,IN_ISDIR
time: test:   IN_ACCESS,IN_ISDIR
time: test:   IN_OPEN,IN_ISDIR
time: test:   IN_OPEN,IN_ISDIR
etc.

My knowledge of the use of $, (, ", ',  and  {  is lacking, so I expect
that is where the trouble lies.

Is the problem obvious?

Thanks,
-Denis

On Sun, Nov 19, 2017 at 10:42 PM, Tomas Kuchta  wrote:

> The script I posted does its own locking, so that other copies would know
> that it is already running and what file it is serving.
>
> See the lock file being created, checked and removed.
>
> Tomas
>
> On Nov 19, 2017 9:10 PM, "Denis Heidtmann" 
> wrote:
>
> > 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 
> 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 

Re: [PLUG] incron issue

[Tomas Kuchta]

The script I posted does its own locking, so that other copies would know
that it is already running and what file it is serving.

See the lock file being created, checked and removed.

Tomas

On Nov 19, 2017 9:10 PM, "Denis Heidtmann" 
wrote:

> 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  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 
> > > 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 

Re: [PLUG] incron issue

[Denis Heidtmann]

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  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 
> > 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  

Re: [PLUG] incron issue

[Denis Heidtmann]

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  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  > 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"  > > 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

Re: [PLUG] incron issue

[Tom]

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  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"  > 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

Re: [PLUG] incron issue

[Denis Heidtmann]

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 
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" 
> 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

Re: [PLUG] incron issue

[Tomas Kuchta]

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" 
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] incron issue

[Denis Heidtmann]

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