[RndTbl] Ksh scripting, named pipes

[Trevor Cordes]

Yes. The paradigm is usually one reader. You can have many writers, and I do that all the time in my scripts, but only one reader. The proper paradigm is to change your scripts around so you have one reader that can then control or start your two previous readers.

You could also have an intermediate reader that then makes the decision which of two further fifos to write two, one for each of your other two previous readers. The best answer depends on what you're really trying to achieve with all this. 

-------- Original message --------
From: Kevin McGregor <kevin.a.mcgregor at gmail.com> 
Date:2014/03/01  16:48  (GMT-06:00) 
To: Continuation of Round Table discussion <roundtable at muug.mb.ca> 
Subject: Re: [RndTbl] Ksh scripting, named pipes 

Aw. I was afraid of that. In my 'production' script there would be a long time between most reads, so it's unlikely there would be a problem, but I still don't want rare random failures. I'll find a work-around.


On Sat, Mar 1, 2014 at 2:12 PM, Adam Thompson <athompso at athompso.net> wrote:
Oh, it's obvious when I think about it - the behavior of a pipe with multiple readers is well-defined as being OS and clib-dependent.
Each byte is only available to one reader, ever - if the reading is interleaved, each reader will get garbage.
You can use tee(1) to write to multiple FIFOs at once, or just adapt the writing script to do so manually.
-Adam

On Mar 1, 2014 1:35 PM, Kevin McGregor <kevin.a.mcgregor at gmail.com> wrote:
>
> The writer is:
> #/bin/ksh
> PIPE=/tmp/backup.pipe
> [[ ! -a $PIPE ]] && mkfifo $PIPE
> # Start gzip processes
> /opt/cronjobs/zip1 &
> /opt/cronjobs/zip2 &
>
> # Process files needing compression
> let 'fc=0'
> ls /zonebackup/*tar | while read F; do
>         echo $F >$PIPE
>         let 'fc=fc+1'
> done
>
> echo "end of list" >$PIPE
> echo "end of list" >$PIPE
> exit 0
>
> The readers are:
> #/bin/ksh
> PIPE=/tmp/backup.pipe
> NAME=zip1
> if [[ ! -a $PIPE ]]; then
>         logger -p local0.warning "$NAME can't find $PIPE -- exiting"
>         exit 1
> fi
>
> while (( 1 )); do
>         read F <$PIPE
>         if [[ "$F" = "end of list" ]]; then
>                 break
>         else
>                 echo "$NAME: $F"
>         fi
> done
>
>
>
> On Sat, Mar 1, 2014 at 1:29 PM, Kevin McGregor <kevin.a.mcgregor at gmail.com> wrote:
>>
>> I tried fiddling with IFS to no avail. I just changed it like this:
>> IFS='
>> '
>> And now the readers show all kinds of gibberish! All lines have no whitespace, save for the newline at the end. I'm assuming it's at the end. 
>>
>>
>> On Sat, Mar 1, 2014 at 12:47 PM, Robert Keizer <robert at keizer.ca> wrote:
>>>
>>> Have you tried setting IFS ( field sep )? Also you could enable raw mode with -r.
>>>
>>> Can you share the script?
>>>
>>> Are the same lines failing repeatedly?
>>>
>>> Rob
>>>
>>> On 2014-03-01 11:55 AM, "Kevin McGregor" <kevin.a.mcgregor at gmail.com> wrote:
>>>>
>>>> I have a main script which writes to a named pipe. Before it starts writing, it starts two other scripts which read from this pipe. The reading and writing is a list of file names, one per line. How do I ensure that each script reads one complete line from the pipe at a time (no more, no less)?
>>>>
>>>> I have a test set up, and it usually works, but sometimes a reader will get a blank line or just a "/" (but not any other part of a line)!
>>>>
>>>> Kevin
>>>>
>>>> _______________________________________________
>>>> Roundtable mailing list
>>>> Roundtable at muug.mb.ca
>>>> http://www.muug.mb.ca/mailman/listinfo/roundtable
>>>>
>>>
>>> _______________________________________________
>>> Roundtable mailing list
>>> Roundtable at muug.mb.ca
>>> http://www.muug.mb.ca/mailman/listinfo/roundtable
>>>
>>
>

_______________________________________________
Roundtable mailing list
Roundtable at muug.mb.ca
http://www.muug.mb.ca/mailman/listinfo/roundtable

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20140301/d4a22de7/attachment-0003.html>