How to? Have hammer - every problem is a nail???

Mar 17, 2013
11
0
#1
How is TCC & TCC/LE for text file processing? I am just relearning this from 4dos days.

We all tend to have our favorite tools and when you like hammers every thing gets nailed down. I wonder if this new and shiny TCC is appropriate for this kind of work. I have a text file that will be coming automatically from a TCC directory listing, that needs some other text added to each line as follows:
Code:
From:
 
S:\Pix2012\2012-01 Jan\[2012-01-27] Shaw, Danielle
S:\Pix2012\2012-01 Jan\[2012-01-28] Bruno, Giovanni
to
 
"S:\Pix2012\2012-01 Jan\[2012-01-27] Shaw, Danielle", Tami, 20120316
"S:\Pix2012\2012-01 Jan\[2012-01-28] Bruno, Giovanni", Tami, 20120316
and then the listing will be imported into a sqlite database. Can TCC be used for this? What about TCC/LE since I will need to run this on numerous workstations??

Is now a good time to better learn TCC??
 
Mar 17, 2013
11
0
#2
Code:
for /f "tokens=*" %a in (filelistB.txt) echo "%a", Tami, 20120318
Seems to work. Like greek, it comes back slowly.... (too many years without 4dos :-)
 
#4
Unfortunately I'm with nickles here, everything will work fine until you hit a random "Jack & Jill" when you only ever expected "Jack and Jill". You can use SETDOS and hobble yourself to the point of TCC being useless, or use safechars plugin to mitigate some (but not quite all) of the risk.

Sadly a lot of problems that look very easy in TCC simply aren't, whereas they turn out to be trivial in languages that don't interpret variable content as part of the command being interpreted.
 
#5
Sadly a lot of problems that look very easy in TCC simply aren't, whereas they turn out to be trivial in languages that don't interpret variable content as part of the command being interpreted.
Yes, the need to retain compatibility with CMD.EXE requires that, and is the root cause of the need for SETDOS/X, the variety of quoting requirements, and a great deal of otherwise unnecessary complexity in the the parser.

Quite a while back for many years I had suggested a separate class of data variables, which are not environment variables, as is done in some of the Unix shells, IIRC both Korn-shell and C-shell, using "a=b" vs. "set a=b" for assignment, to be used in the manner of compiled HLLs - strongly typed with fixed rules for internal representation, for methods of conversion between internal and external representation, for assignment, deferred v. instant evaluation (during command execution v. parsing). The closest we have is the binary buffer, which requires the user to write all the functions for mapping variables to buffers, assignment, conversion, etc. - virtually rewrite BASIC in TCC.
 
#6
Another question: Why not leave the trails of CMD and move on to another - better - command shell with the best features of all "worlds", a [better] working command line completion (I'd love to use grep w/o any SETDOS tricks), a connection to cmdlets (w/o the stupid syntax of PowerShell), etc.

I have stopped using CMD a long while ago (except for the cases/environments where it is absolutely mandatory), and wouldn't have any problems with a new "language" to learn. I personally don't need CMD compatibility, I need a good shell (which TCC mostly is)...
 
#8
Code:
for /f "tokens=*" %a in (filelistB.txt) echo "%a", Tami, 20120318
Actually, I'd rather use the DO with the "@file" syntax:
do line in @filelistB.txt (echo "%line", Tami, 20120318)


This can even be redirected so that the target file is opened and closed only once:
( do line in @filelistB.txt (echo "%line", Tami, 20120318) ) > target.file

However, this is still subject to characters in the data line being interpreted as syntactically significant. Charles Dye's SafeChars.DLL can help:
( do line in @filelistB.txt (echo "%@safeenv[line]", Tami, 20120318) ) > target.file

Watch the peculiar syntax of the @SAFE... functions: to circumvent the TCC parser's overzealousness, the parameter is NOT preceded by the percent sign "%"!