Unwanted line feed added when writing to pipe

  • Kevin Toppenberg

    I am having trouble communicating with a gtm subprocess opened via pipe functionality.

    I want to be able to send the subprocess **one character at a time**, but every time I do a plain "WRITE x", it appears that a "WRITE x,!" is sent instead.

    Here is a screen scrape demonstrating this.  This  is
    a screen log of me sending a simply "w" (i.e. the first character of
    'write "hello world",!' if I were to send it character by character),
    which  immediately causing the subprocess to issue an error.
    NOTE: If was normally at a GTM prompt, and I pressed the letter 'w',
    it would wait for me to press ENTER to process the line.
    So the fact that sending a 'w' to the subprocess immediately creates
    an error tells me that in fact a  has been sent.

    Note: the 'runAV' script seen in the COMMAND below is just the standard
    script that I always use to setup the environment and launch gtm.  I have
    entered gtm this way for years.

    For clarity, I have added a line '==========' to separate the output
    from the subprocess.

    Can anyone help?


    Kevin T

    ASTRON>set p="subgtm"

    ASTRON>open p:(COMMAND="sh runAV":STREAM:NOWRAP)::"pipe"

    ASTRON>for  use p read x:1 use $P w x,! quit:($T=0)

    GT.M VistA Startup Script
    Starting Setup_env script
    Entering GT.M system now…
       (using GT.M v5)


    ASTRON>use p write "w" for  use p read x:1 use $P w x,! quit:($T=0)

    %GTM-E-SPOREOL, Either a space or an end-of-line was expected but not


    ASTRON>use $p

    ASTRON>close p


  • Bob Isch

    Bob Isch - 2010-08-17

    I am not sure exactly what your "runAV" script is doing but you might try something like this.  Given a the two files foo4.sh and foo4.m you should get something like what is shown at the end.


    # foo4.sh - Test single character I/O with GT.M pipes
    mumps -run sub^foo4


    foo4  ; foo4.m - test single character I/O on pipes
       w 0/0
    main  ;
       set p="subgtm"
       open p:(COMMAND="sh foo4.sh":STREAM:NOWRAP)::"pipe"
       for i=0:1 use p quit:$zeof  d
       .  read x#1:1
       .  set t=$test,eof=$zeof
       .  use $P
       .  write "i:"_i_" $test:"_t_" $zeof:"_eof_" $length:"_$length(x)_" x:"_x,!
       use $p
       close p
       quit  ; >>> main
    sub   ;
       hang 2
       write "he",!
       hang 2
       write "l"
       hang 2
       write "lo"
       hang 2
       quit  ; >>> sub

    Running foo4.m with mumps -run main^foo4 you should get something like:

    $ mumps -run main^foo4
    i:0 $test:0 $zeof:0 $length:0 x:
    i:1 $test:0 $zeof:0 $length:0 x:
    i:2 $test:1 $zeof:0 $length:1 x:h
    i:3 $test:1 $zeof:0 $length:1 x:e
    i:4 $test:1 $zeof:0 $length:0 x:
    i:5 $test:0 $zeof:0 $length:0 x:
    i:6 $test:1 $zeof:0 $length:1 x:l
    i:7 $test:0 $zeof:0 $length:0 x:
    i:8 $test:1 $zeof:0 $length:1 x:l
    i:9 $test:1 $zeof:0 $length:1 x:o
    i:10 $test:0 $zeof:0 $length:0 x:
    i:11 $test:1 $zeof:0 $length:0 x:
    i:12 $test:1 $zeof:1 $length:0 x:

    I just put the hangs in to simulate delays.  You might also play with READ *x for single character reads.

    Hope that helps,

  • Michael Crone

    Michael Crone - 2010-08-18

    The pipe device was implemented based on the behavior of the disk and fifo devices.  When a write is done to the device in streaming mode without a terminator and it is followed by a read,  a newline is written to the device.  This flushing is not really necessary for a pipe, however, since read and write are 2 separate file descriptors.  The newline will no longer be issued for the pipe device in the next release.
    Thanks, Mike

  • Kevin Toppenberg

    Thank you Bob and Mike for your replies.

    Bob, I think you misunderstood my problem.  You demonstrated that I could READ from the subprocess one character at a time.  but my problem is WRITING to it with just one character.  My runAV script just gets me to a GTM prompt.  In your setup, it would probably be comprised of just "gtm".

    Mike, thanks for looking at this, and I am happy to hear that this issue will be cleared up in the next release of GTM.

    Keep up the great work!


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks