Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

A "SafeChars" plugin request...

May
855
0
I've been using "SafeChars" for quite a while now, and have been quite happy with it (thank you, Charles! Particularly for the "/E:" parameter) until now. But in the application I am now trying write it is doing something totally unexpected (meaning I didn't expect it to do it and don't have a clue as to why it is doing it; and I just downloaded and installed the latest version of it which is still doing it) that is totally unacceptable in the application that I am attempting to use it for, so much so that I will almost certainly have to write a C++ program (I'm seriously trying to get away from writing C++ programs for relatively simple tasks) to "work around" the issue. So what is the issue? Simple, it really appears that both "@SafeRead" and "@SafeLine" strip leading blanks off of the lines that they read and that literally destroys the data I am trying to process in terms of my intended use for it. (The "@FileRead" and "@Line" functions do not do this.) The reason I really need to use SafeChars (or something similar if it existed) in the first place is because the data I am attempting to process has embedded commas (I am using "UnSafe /E:," to make the embedded commas "safe"; and of course data that is returned by plain old "@FileRead" is literally unusable in many contexts in TCC batch files if it contains embedded commas) , and since that data comes from an external source (specifically the web, of course) I have absolutely no control whatsoever over whether or not it contains those embedded commas. And the task I am trying to perform is to "reformat" that data, which I really need to do to use it for its intended purpose, but, again, the leading blanks are significant. So, Charles, can you please fix this in some way (it's not a character "translation" issue, of course, so the /E: parameter isn't in any way going to do it) in the not-too-distant future? I will almost certainly have to write a C++ program to do this task now, of course, because what I am trying to do needs to be accomplished today. Thank you!

P. S. If you are wondering why I just don't use something like Perl or similar languages (I can't think of the names of any of them at the moment - you will understand why in just a moment) the reason is because of my often-mentioned very-severe memory problems. Learning and therefore remembering "new" stuff is almost impossible for me, but I (mostly) still remember stuff I learned before my my memory issues became serious; and C++ "strongly" falls into that category. (And good documentation, such as Take Command/TCC have, is absolutely essential for me.) And if you are also wondering why I don't just use C++ all of the time in the first place, it is because I am probably at least an order of magnitude slower writing programs than I was in my "prime", and since there is almost always a lot of "infrastructure" code in a C++ program, as well as a general lack of built-in functions to do many of the things that TCC does naturally, so to speak (I have been slowly writing a lot of them over the years but remembering what I have already written at any given point in time is also a minor problem) this means that there are typically many more lines of code to accomplish a given task in a C++ program than there are in a TCC batch file; and since my "slowness" is strongly related to the number of lines of code I actually have to write, that generally means that it takes a lot more time to write a C++ program than it takes to write a TCC batch file (assuming that TCC can do it at all, of course, which it mostly can) that accomplishes the same task, and that gives me a strong bias against C++ programs and for TCC batch files.
 
Simple, it really appears that both "@SafeRead" and "@SafeLine" strip leading blanks off of the lines that they read and that literally destroys the data I am trying to process in terms of my intended use for it. (The "@FileRead" and "@Line" functions do not do this.)

If it's doing that, it's certainly not by design. I'll take a look at it tomorrow.
 
So what is the issue? Simple, it really appears that both "@SafeRead" and "@SafeLine" strip leading blanks off of the lines that they read and that literally destroys the data I am trying to process in terms of my intended use for it. (The "@FileRead" and "@Line" functions do not do this.)

Dave: (it is Dave, isn't it? -- my memory isn't so great either!)

I'm not seeing the behavior you describe; I always get leading and trailing blanks back, as expected.

Code:
C:\BIN\JPSDK\safechars>ver /r

TCC  13.00.23   Windows XP [Version 5.1.2600]
TCC Build 23   Windows XP Build 2600  Service Pack 3
Registered to Charles Dye - 5 System License

C:\BIN\JPSDK\safechars>plugin /i safechars
Module:      C:\BIN\JPSDK\safechars\release\safechars.dll
Name:        SafeChars
Author:      Charles Dye
Email:       [email protected]
Web:         http://www.unm.edu/~cdye/plugins/safechars.html
Description: Read and write text containing special characters
Implements:  @safeclip,@safeclipw,@safeenv,@safeexp,@safeline,@saferead,@safewrite,@uquotes,_amp,_bq
,_caret,_closebrk,_closepat,_gt,_lt,_openbrk,_openpat,_pct,_quote,_vbar,safecharshelp,safeecho,safee
chos,unsafe
Version:     1.5  Build 3

C:\BIN\JPSDK\safechars>type spaces.txt
Zero
 One
  Two
   Three
    Four
     Five

C:\BIN\JPSDK\safechars>for /l %i in ( 0, 1, 5 ) echo %i "%@safeline[spaces.txt,%i]"
0 "Zero"
1 " One "
2 "  Two  "
3 "   Three   "
4 "    Four    "
5 "     Five     "

C:\BIN\JPSDK\safechars>set handle=%@fileopen[spaces.txt,r]

C:\BIN\JPSDK\safechars>for /l %i in ( 0, 1, 5 ) echo %i "%@saferead[%handle]"
0 "Zero"
1 " One "
2 "  Two  "
3 "   Three   "
4 "    Four    "
5 "     Five     "

C:\BIN\JPSDK\safechars>set rv=%@fileclose[%handle] & set handle=

C:\BIN\JPSDK\safechars>

Can you give me a minimal test case which reproduces this behavior? Thanks!
 

Similar threads

Back
Top