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!


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks