Weird, unexpected behavior of $TEXT() on GT.M

[Kevin Toppenberg]

$TEXT seems to be reading the TAB character (#9) as a SPACE (#32).

Here is the file DI.m, as displayed in the JOE editor.  I contains leading TABS.

DI      ;SFISC/GFT-DIRECT ENTRY TO VA FILEMAN ;2OCT2012

V       ;;22.2V1;VA FILEMAN;;Jan 31, 2013

        ;Per VHA Directive 2004-038, this routine should not be modified.

        ;

        G QQ:$G(^DI(.84,0))']""

C       G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ) G ^DII

D       G QQ:$G(^DI(.84,0))']"" G ^DII

P       G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ)

Q       G QQ:$G(^DI(.84,0))']"" S DUZ(0)="@" G ^DII

VERSION ;

        S VERSION=$P($T(V),";",3),X=$P($T(V),";",4)_" "_VERSION Q

        ;

QQ      ;

        W $C(7),!!,"You must run ^DINIT first."

        Q

When I copy the display from the console into this Email, it converts the TAB to spaces, but it is actually a TAB char.  I highlighted the first several of them.  

Here is screen shot of a hex editor with many (but not all) of the tab characters highlighted.

Here is a simple mumps routine that explores this routine

TESTTEXT

  WRITE !!

  NEW TEST SET TEST="AB "_$CHAR(9)_"CDE"

  DO ASCIILINE(TEST)

  WRITE "--------------",!

  NEW TMGI

  FOR TMGI=1:1:10 DO

  . NEW LINE SET LINE=$TEXT(+TMGI^DI)

  . WRITE LINE,!

  . DO ASCIILINE(LINE)

  QUIT

ASCIILINE(S) ;DUMP OUT FIRST FEW CHARACTERS OF INPUT AS ACII-CODE AND CHARACTER

  NEW TMGJ 

  FOR TMGJ=1:1:10 DO

  . NEW CH SET CH=$EXTRACT(S,TMGJ)

  . WRITE "[",$ASCII(CH),"]",CH

  WRITE !

  QUIT

And here is it's output

ASTRON>do TESTTEXT^TMGFIX

[65]A[66]B[32] [9]      [67]C[68]D[69]E[-1][-1][-1]

--------------

DI ;SFISC/GFT-DIRECT ENTRY TO VA FILEMAN ;2OCT2012

[68]D[73]I[32] [59];[83]S[70]F[73]I[83]S[67]C[47]/

V ;;22.2V1;VA FILEMAN;;Jan 31, 2013

[86]V[32] [59];[59];[50]2[50]2[46].[50]2[86]V[49]1

 ;Per VHA Directive 2004-038, this routine should not be modified.

[32] [59];[80]P[101]e[114]r[32] [86]V[72]H[65]A[32] 

 ;

[32] [59];[-1][-1][-1][-1][-1][-1][-1][-1]

 G QQ:$G(^DI(.84,0))']""

[32] [71]G[32] [81]Q[81]Q[58]:[36]$[71]G[40]([94]^

C G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ) G ^DII

[67]C[32] [71]G[32] [81]Q[81]Q[58]:[36]$[71]G[40](

D G QQ:$G(^DI(.84,0))']"" G ^DII

[68]D[32] [71]G[32] [81]Q[81]Q[58]:[36]$[71]G[40](

P G QQ:$G(^DI(.84,0))']"" K (DTIME,DUZ)

[80]P[32] [71]G[32] [81]Q[81]Q[58]:[36]$[71]G[40](

Q G QQ:$G(^DI(.84,0))']"" S DUZ(0)="@" G ^DII

[81]Q[32] [71]G[32] [81]Q[81]Q[58]:[36]$[71]G[40](

VERSION ;

[86]V[69]E[82]R[83]S[73]I[79]O[78]N[32] [59];[-1]

ASTRON>

Notice that my ASCIILINE() function works just fine when I manually create a string that contains a tab (#9), but that the line that is retrieved from $TEXT() does NOT contain a TAB!


Just in case anyone needs a reference of ASCII control characters, here is a table showing that #9 is a horizontal TAB

I looked up in the GT.m manual, here

http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/

And it doesn't given any hint of this behavior.

And my favorite "Mumps By Example" site, here
http://71.174.62.16/Demo/AnnoStd?Frame=Main&Edition=examples&Page=a107109#Def_0001

doesn't give any hint of it either.

SO WHAT'S GOING ON???

Why is $TEXT() pulling in #9's and turning them to #32's ???

Thanks

Kevin 

[David Whitten]

Kevin asked:

>> Why is $TEXT() pulling in #9's and turning them to #32's ???

GT.M is following the MUMPS standard which specifies exactly the behaviour

you are talking about. You are confusing the internal storage (which on GT.M

stores routines as host operating system text files, and which for example,

DSM stored as global blocks in a weird global named after the "space" character.

Implementors of MUMPS can use any kind of internal storage they want to,

but the $TEXT function is required to return the data in a predictable way.

Dave Whitten

713-870-3834

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Toppenberg]

Dave,

Wow.  I sure didn't know that.   I guess I have learned my new thing for the day, and I can be done.

Thanks

Kevin

[OldMster]

Kevin,

Woo Hoo, you can start your weekend now! :-)

Mark

[Kevin Toppenberg]

OK, while we are on the topic, is it JUST tabs that get converted to spaces?  Any other conversions that $TEXT performs?

Kevin

[Chris Richardson]

Kevin;  That is pretty much it.  TAB and space are interchangeable as the first space on a line, but $TEXT does the conversion for you.  Any number of spaces can be between command sets, and only a single space is allowed between the command assembly and its argument and there needs to be at least one space between command sets (command and argument).

[Kevin Toppenberg]

Thanks

Kevin

[Kevin Toppenberg]

OK, to code around this, I have written a replacement for $TEXT() that works off the source file on the HFS.  I will only need to use in the limited circumstances where I want the tab characters.  

Thanks for the help.

Kevin

On Friday, June 26, 2015 at 4:49:38 PM UTC-4, David Whitten wrote:

[Steven McPhelan]

If I am not mistaken the ANSI states that only the first tab character ( <tab>M commands   or  tag<tab>M commands) is converted to a space.  So whether any remaining TABs on a line are converted is ????.  I do know that Cache does not convert TABs following the comment indicator.

Steve

A decent provision for the poor is the true test of civilization. - Samuel Johnson

[Kevin Toppenberg]

cursiouser and cursiouser....

Thanks

Kevin

[Sam Habiel]

I checked the M standard, and $TEXT has no provision for converting
anything that has to do with tab. I have earlier established that a
tab character at the beginning of the line, while ubiquitous, is not
allowed by the 95 M standard either.

> --
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Hardhats" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hardhats+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Sam Habiel, Pharm.D.
VISTA Expertise Network

[Steven McPhelan]

What does the 95 standard say about converting the 'line start' character?  Does the 95 standard explicitly state what the line start character is?  I believe you will find this behavior is completely within the bounds of the 95 standard (from memory).

Steve

We have no government armed with the power capable of contending with human passions, unbridled by morality and true religion. Our constitution was made only for a moral and religious people. It is wholly inadequate to the government of any other. - John Adams

[Kevin Toppenberg]

Same, I don't understand what you are saying.  Does $TEXT "convert" anything?  I thought it just reported what was there.

Kevin

[Steven McPhelan]

Except for the line start character.

[Steven McPhelan]

"...Specifically, the entire line, with ls replaced by one SP and eol deleted, is returned".  The standard is 20 years old.  The work to derive the standard is more than 20 years old.  Think about how computing was done over 20 years ago.  Also $T(+intexpr) is valid where intexpr is an element of  [0,n] of integers where n is the largest number allowed by standard.