Without having to extend (hack, violate, corrupt, make incompatible, "embrace and extend") the tpdd protocol, you could probably use inotify to make a static file whose size reamains constant, exists before, during and after the tpdd server (any tpdd server not just laddie) tries to access it, yet gets it's time updated updated automatically when accessed, without having to have a cron job that overwrites it every seconf forever.
The way inotify works is, you specify some filesystem actions to watch for on a given file or directory. Like open-for-reading, and, do something in response to that. You can use "incron" to set a watch that runs starting at boot, or you can use the inotify feature within any program you write, or there is an inotifywait util that you can use in shell scripts. So for this, the outline of the process goes like this: * install and activate incrond * invent a special file name for the time/date/anything-els-you-want file * write a script that updates or overwrites this file * touch the filename in the tpdd server file sharing directory to create the initial empty but real file * create an incrontab that watches the special filename, and runs the script Lastly, it might not be possible to update the file contents in between the the tpdd server accessing the file and reading it out to the client. It depends on just exactly what kinds of filesystem operations you can watch for, and just exactly how the tpdd server behaves as it goes about reading a file. Not necessarily a problem! Lastly, you just have the M100 read the file. And possibly, you might have to have the code on the M100 read the file twice and ignore the first time. You could also have the incron job watch the directory istead of the file, and update the file whenever the directory was statted. Then the M100 code could get a directory listing and then read the file. But reading the file twice would work even for teeny which has no list command. I think you could also set up the inotify watch in the form of a co-process launched by a wrapper script which launches both the intofiy watcher and the tpdd server. Then you don't have to install incron or write a system incrontab entry in /etc which runs from boot. And, you don't have to modify the tpdd server, and it could be used with any tpdd server. I use incron for lots of odd things like this at work. I could knock up a real example in no time if this isn't a good enough description to work from. The only reason I'm not sure if you might have to do a little hack like read the file twice, is I'm usually using incron to watch from files that get depositied by ftp or by local unpriviledged processes, so I'm always watching for "moved-to or closed-from-write". I'm never trying to catch something on *open*. I know you can watch for that, but I don't know if you could actually get in there and re-write the file just before or just after it's opened, and have the process see the *new* contents on *first* access. But just reading it twice isn't so terrible, and the 2nd access will show the time less than a second off. You could even get fancy and measure how long it takes the M100 to conduct the transaction and adjust the time by the measured offset if one second isn't close enough time! -- bkw On Jan 9, 2017 7:48 PM, "Russell Davis" <rkda...@burninghorse.com> wrote: > ah ok. i'd been fiddling with pipes, sockets and fifos aloy recently and > in workaround mode so misread your post > > > bst rgrds > > Russell > > On 1/9/2017 6:53 PM, Willard Goosey wrote: > > > Huh? No the behavior of the pipe itself is perfect! Date blocked on the > pipe *before getting the time* so it could sit there for days and still > report current time when the pipe is finally read. > > It's just that something on the mono/laddiealpha/tsdos train doesn't like > the file it's reading changing size while its being read. Which was not an > issue the pdd protocol ever imagined. > > Willard > Sent from Samsung tablet > > > > -------- Original message -------- > From Russell Davis <rkda...@burninghorse.com> <rkda...@burninghorse.com> > Date: 01/09/2017 2:25 PM (GMT-07:00) > To Model 100 Discussion <m100@lists.bitchin100.com> > <m100@lists.bitchin100.com> > Subject Re: [M100] THAT didn't work... ;-) > > > if you want to be able to write to a named pipe before your reader is > created you have to open the named pipe as read/write using an extra step > e.g. > --- > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ mkfifo foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ exec > 3<>./foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ date > > ./foo & > [1] 2561 > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ date > Mon 9 Jan 21:21:53 UTC 2017 > [1]+ Done date > ./foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ cat ./foo > Mon 9 Jan 21:21:49 UTC 2017 > ^C > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ rm foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ mkfifo foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ date > > ./foo & > [1] 2567 > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ date > Mon 9 Jan 21:22:34 UTC 2017 > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ cat ./foo > Mon 9 Jan 21:22:43 UTC 2017 > [1]+ Done date > ./foo > pi@glooston:~/GnuCOBOL/open-cobol-code/branches/gnu-cobol-2.0 $ > > ---- > although that brings up another problem in that ^C needed to kill the > reader unless you background the reader. > > bst rgrds > Russell > On 1/9/2017 4:04 PM, Willard Goosey wrote: > > So I tried a clever trick and it didn't work. > > (This is NOT a bug report about any of the named programs, as it's a > weird edge case.) > > So UNIX (and therefore Linux) has these things called "named > pipes". They're like files, except that they're strictly buffers -- > you write something to one and it's only there until it's read. > > galvatron:~$ mkfifo foo > galvatron:~$ date > foo & > [1] 395 > galvatron:~$ date > Mon Jan 9 13:52:21 MST 2017 > galvatron:~$ cat foo > Mon Jan 9 13:52:23 MST 2017 > [1]+ Done date >foo > galvatron:~$ > > So, interestingly, note that the date written to the named pipe "foo" > wasn't written until it was read! > > Just as an experiment, I created ~/root/DATE.DO as a named pipe and > redirected date(1) into it... Then tried to read it from tsdos via the > laddiealpha PDD server. > > The result: M100 visits Cold Start City. > > Not really surprising, something probably got confused by the fact > that the named pipe is reported as a 0-length file. > > Would be an easy way to sync the M100's time to a laddiealpha server, > but it's not to be. > > Willard > > > >
