Tee
Tom Del Rosso
handle numbers, so output goes both to a file and to the console?
--
Reply in group, but if emailing add another
zero, and remove the last word.
Ted Davis
<td...@att.net.invalid> wrote:
>Is there a way to emulate the unix tee command by playing tricks with stream
>handle numbers, so output goes both to a file and to the console?
No, but you can use tee from the GNU 'coreutils' package:
<http://gnuwin32.sourceforge.net/packages/coreutils.htm>.
--
T.E.D. (tda...@gearbox.maem.umr.edu)
Tom Del Rosso
in news://qj3ua2pqv8163tlsg...@4ax.com,
>
> No, but you can use tee from the GNU 'coreutils' package:
> <http://gnuwin32.sourceforge.net/packages/coreutils.htm>.
Thanks. I have that one, but I hoped to avoid requiring yet another utility
on every target system. I'll settle for repeating the command.
foxidrive
> Ted Davis <tda...@gearbox.maem.umr.edu> typed
> in news://qj3ua2pqv8163tlsg...@4ax.com,
>
>>
>> No, but you can use tee from the GNU 'coreutils' package:
>> <http://gnuwin32.sourceforge.net/packages/coreutils.htm>.
>
> Thanks. I have that one, but I hoped to avoid requiring yet another utility
> on every target system. I'll settle for repeating the command.
If it's an option of repeating the command you might consider redirecting
the output to a temp file and then 'type'ing the temp file.
command >temp.file 2>&1
type temp.file
Tom Del Rosso
in news://1u04uouh3mhdq.a...@40tude.net,
> If it's an option of repeating the command you might consider
> redirecting the output to a temp file and then 'type'ing the temp
> file.
>
> command >temp.file 2>&1
> type temp.file
Thanks for suggesting it, but then I also have to append the temp file to
the target file, and that's 3 lines. Repeating the command is 2, and it
looks neater.
Michael Bednarek
alt.msdos.batch.nt:
>Ted Davis typed
>in news://qj3ua2pqv8163tlsg...@4ax.com,
>
>> No, but you can use tee from the GNU 'coreutils' package:
>> <http://gnuwin32.sourceforge.net/packages/coreutils.htm>.
>
>Thanks. I have that one, but I hoped to avoid requiring yet another utility
>on every target system. I'll settle for repeating the command.
Surely, most commands can't be repeated. And echoing the command merely
shows the command, it doesn't capture its output.
--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
Herbert Kleebauer
>
> Thanks. I have that one, but I hoped to avoid requiring yet another utility
> on every target system.
@echo off
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>dup.com
echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
dir | dup >dirlist
del dup.com
:: The source code:
::
::; 1.7.02 copy stdin to stdout and stderr
::
:: @=$178
:: move.w #buf,r1
:: move.w #1,r2
::_10: move.b #$3f,m0
:: eor.w r3,r3
:: trap #$21
:: bcs.b _100
:: cmp.w r0,r2
:: bne.b _100
:: move.b #$40,m0
:: inc.w r3
:: trap #$21
:: move.b #$40,m0
:: inc.w r3
:: trap #$21
:: br.b _10
::_100: rts.w
::buf:
Larry__Weiss
> Is there a way to emulate the unix tee command by playing tricks with stream
> handle numbers, so output goes both to a file and to the console?
>
>
Assuming gawk is available, you could code tee-like functionality as
gawk "{print;print>\"outputfile.txt\"}"
For example,
ver | gawk "{print;print>\"outputfile.txt\"}"
I try hard to make gawk the only third-party utility that I have to add
to a system to enable use of my toolbox of batch programs.
- Larry
John Dill
Tom Del Rosso wrote:
> Ted Davis <tda...@gearbox.maem.umr.edu> typed
> in news://qj3ua2pqv8163tlsg...@4ax.com,
>
> >
> > No, but you can use tee from the GNU 'coreutils' package:
> > <http://gnuwin32.sourceforge.net/packages/coreutils.htm>.
>
> Thanks. I have that one, but I hoped to avoid requiring yet another utility
> on every target system. I'll settle for repeating the command.
If efficiency is not a concern, consider the tee.cmd from the blip
project at http://sourceforge.net/projects/blip. It won't be as
efficient as repeating the command, but it will look a lot cleaner in
your scripts.
Here is the usage from 'tee /?':
--
Read from the standard input and write to standard output and files.
tee [/A] [/S] <file>
/A Append the standard input to the file instead of
overwrite them.
/S Silently write the standard input to the file.
file The file to write the standard input to.
The 'tee' script allows you to send text to the console and a file
at the same time. It also provides a silent flag that allows easier
configurability on sending text information to the console, to a
file, or both.
The 'tee' script may finish before the contents of the file are
fully updated. If the contents do not appear correct, it may be
due to the time needed to flush the contents of the standard output
buffer to file.
--
To use this script, just do something like the following:
find "PATH" *.cmd | tee output.txt
Hope this helps,
John
Timo Salmi
> so output goes both to a file and to the console?
94) Can I send the script's output both to the screen and a log file?
167495 Jun 18 2006 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
tscmd.zip Useful NT/2000/XP script tricks and tips, T.Salmi
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Larry__Weiss
> Tom Del Rosso wrote:
>> so output goes both to a file and to the console?
>
> 94) Can I send the script's output both to the screen and a log file?
> 167495 Jun 18 2006 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
> tscmd.zip Useful NT/2000/XP script tricks and tips, T.Salmi
>
> All the best, Timo
>
Specifically in file 1CMDFAQ.TXT in that compressed folder.
- Larry
Harlan Grove
...
>@echo off
>echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
>echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>dup.com
>echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
>
>dir | dup >dirlist
>del dup.com
>
>:: The source code:
Yes, but the source code for what? An ASCII Assembler?
Most of use who respond tend to provide fish to OPs rather than teach
them how to fish for themselves, but at least most solutions allow OPs
to play with and extend the solutions. Assembler binaries don't. For
the OP to extend such solutions, they'd need to find and install an
ASCII Assembler and learn op code mnemonics.
If you're going to oblige OPs to learn another language in addition to
batch, why not another high level language? Like VBScript, which almost
always is already installed on most Windows PCs (only Windows 95, 98
[First Edition] and Windows NT4 and prior that are running IE 4 or
prior wouldn't have WSH)?
A WSH/VBScript alternative.
@REM name this batch file tee.bat
@echo off
echo Dim s > %0.vbs
echo Do While Not WScript.StdIn.AtEndOfStream >> %0.vbs
echo s = WScript.StdIn.ReadLine >> %0.vbs
echo WScript.StdOut.WriteLine s >> %0.vbs
echo WScript.StdErr.WriteLine s >> %0.vbs
echo Loop >> %0.vbs
cscript //nologo %0.vbs
del %0.vbs
Then use this batch file in commands like
dir *.xyz | tee > outputfile
This also takes advantage of the fact that batch files running under
CMD can use different, specific standard I/O streams for individual
commands within the batch file in addition to the standard I/O streams
for the batch file itself. The dup.com command above could be used
similarly.
Further, typos that could occur in VBScript code would likely lead to
syntax errors and only potentially overwrite the
Harlan Grove
...
>@echo off
>echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
>echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>dup.com
>echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
>
>dir | dup >dirlist
>del dup.com
>
>:: The source code:
A WSH/VBScript alternative.
dir *.xyz | tee > outputfile
syntax errors and only potentially overwrite the output file, while
typos in ASCII Assembler could have arbitrarily destructive effects.
ASCII Assembler should be viewed as a last resort.
foxidrive
> Herbert Kleebauer wrote...
> ...
>>@echo off
>>echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
>>echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>dup.com
>>echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
>>
>>dir | dup >dirlist
>>del dup.com
>>
>>:: The source code:
> ...
>
> Most of use who respond tend to provide fish to OPs rather than teach
> them how to fish for themselves, but at least most solutions allow OPs
> to play with and extend the solutions.
I've got news for you, Harlan - those OPs come back for more help when the
solution doesn't work - usually because they have provided insufficient
information. Most have little desire to learn and just want a task
completed.
> Assembler binaries don't. For
> the OP to extend such solutions, they'd need to find and install an
> ASCII Assembler and learn op code mnemonics.
We would have killed for such binaries in the MSDos days in Fidonets
Batpower forum. If you want to provide a WSH solution then go ahead, but
ascii binaries have a place of pride too.
As for incorrectly typed binaries, cut and paste is one of the first things
a Windows user would learn - surely you don't think the OPs mentioned above
type in the code that is provided here?
Herbert Kleebauer
> Herbert Kleebauer wrote...
> ...
> >@echo off
> >echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
> >echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>dup.com
> >echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
> >:: The source code:
> ...
>
> Yes, but the source code for what? An ASCII Assembler?
What is an "ASCII Assembler"? An assembler converts a symbolic
representation of CPU instructions into the binary opcode.
And this opcode is defined by the CPU designer an no "ascii
assembler" (what ever this should be) is able to replace
the binary code by ASCII characters. The given source is a
very simple, normal com program which reads a character from
stdin (int 21 / AH=3f) and writes it to stdout and stderr
(int 21 / AH=40). And as you can see, the generated opcodes
are not restricted to printable ASCII characters.
@=$178
0178: ba 0197 move.w #buf,r1
017b: b9 0001 move.w #1,r2
017e: b4 3f _10: move.b #$3f,m0
0180: 31 db eor.w r3,r3
0182: cd 21 trap #$21
0184: 72 10 bcs.b _100
0186: 39 c1 cmp.w r0,r2
0188: 75 0c bne.b _100
018a: b4 40 move.b #$40,m0
018c: 43 inc.w r3
018d: cd 21 trap #$21
018f: b4 40 move.b #$40,m0
0191: 43 inc.w r3
0192: cd 21 trap #$21
0194: eb e8 br.b _10
0196: c3 _100: rts.w
This normal com program is then converted to a self extracting
ASCII program. This conversion is done by a simple batch file
(which itself contains a self extracting ASCII program):
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
rem - save the lines below as CONVERT.BAT
rem - write a COM program and assemble it with ORG=0x178 (PROG.COM)
rem (you must not use the standard ORG=0x100 for this com programs!!!!)
rem - enter: CONVERT PROG.COM PROG.BAT
rem - the BATCH file PROG.BAT contains an encoded form of PROG.COM
@echo off
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>bat.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>bat.com
echo ??wQ@tyM?WxI?@zA=`Lbw?y_y~?_xA[bz?B_L??oAN`_H?e?as?Fx?pkz?>>bat.com
echo B_}A[aIA]b@MCs?A_rVAgr?\gBGpangV_~r?TO?wGJLy?hKxAG@z?G`L?K>>bat.com
echo K?wQO`LRaRPdwA_by??cxA_bL?@O=Et`x?y_z?P_L?@oXZ`SdBW\ngbTiA>>bat.com
echo _Syi?To_gD_lWPOOnSOOOTg`ODgDCDgLCDgNCDggCDgrKDgtKDgWKDYdKT>>bat.com
echo \QQTDDDTQXTTCqWP}=w@s`aTnbmSILl@gbdTo_n@EwCTokO@mwWDOosPW=>>bat.com
echo kOrFsTnsAP~c?@xHOTV_TPoWvDTvFTV_XPnzuPWAuTuFqSwDoStHFTusgD>>bat.com
echo a}}Oms`DlnbTdILOngbT}o_?`a}SbmsPLlnD??I??~?OBA@TEDCTHGFTKJ>>bat.com
echo ITNMLTQPOTTSRTWVUTZYXTp\[D`_1TcbaTfedTihgTlkjTonmTrqpTutsT>>bat.com
echo xwvT=zyD?}=D????}}??s`aTnbmSILl@gbdTg_nP0x>>bat.com
bat.com <%1 >%2
del bat.com
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> Most of use who respond tend to provide fish to OPs rather than teach
> them how to fish for themselves, but at least most solutions allow OPs
> to play with and extend the solutions. Assembler binaries don't. For
There is no solution which is more flexible than inserting CPU
instructions into the batch code. You normally don't use already
existing ASCII programs but write exactly the sequence of CPU
instructions which is needed to solve a special problem. And you
can use any assembler you like and then convert it to a self extracting
ASCII program. And if you don't like the ORG 0x178, then you can use
Laura Fairhead's converter (http://lf.1accesshost.com) which
converts any standard com program.
> the OP to extend such solutions, they'd need to find and install an
> ASCII Assembler and learn op code mnemonics.
He can use any assembler he like. And this assembler is only
needed to write the code, for executing the code no external
program is needed at all, anything is included within the batch
file.
> If you're going to oblige OPs to learn another language in addition to
> batch, why not another high level language? Like VBScript, which almost
> always is already installed on most Windows PCs (only Windows 95, 98
> [First Edition] and Windows NT4 and prior that are running IE 4 or
> prior wouldn't have WSH)?
It is a VERY bad idea to make the execution of batch dependent
on the existence of an external program (even if it is most
likely installed on most systems). And there is no language
which is more flexible than assembler. And anybody who is
involved in programming (even if it is only batch programming)
should know assembly programming anyhow.
> A WSH/VBScript alternative.
An alternative which requires the existence of WSH/VBScript
on the target system isn't really an alternative to a solution
which requires no external program at all.
> Further, typos that could occur in VBScript code would likely lead to
> syntax errors and only potentially overwrite the output file, while
> typos in ASCII Assembler could have arbitrarily destructive effects.
Sorry, but is much more likely that a typo in a source code
does a damage than a wrongly modified byte in an executable.
And if you really worry about this, it is no problem to modify
the conversion program so it appends a checksum which is
checked when the code is extracted.
> ASCII Assembler should be viewed as a last resort.
Only somebody who doesn't understand the principles of batch
included CPU instructions can write such a sentence. It is
the most powerful and flexible way to overcome the limitations
of batch programming and doesn't rely on the existence of
any external program in order to execute the batch program.
Harlan Grove
...
>I've got news for you, Harlan - those OPs come back for more help when the
>solution doesn't work - usually because they have provided insufficient
>information. Most have little desire to learn and just want a task
>completed.
I agree about OP follow-ups due to inadequate initial details. I don't
agree that OPs never try to extend ng solutions. Maybe that's usually
the case in this ng, but the OP seems to have some knowledge of using
the command line and is just seeking alternatives.
>We would have killed for such binaries in the MSDos days in Fidonets
>Batpower forum. If you want to provide a WSH solution then go ahead, but
>ascii binaries have a place of pride too.
You had 'em via DEBUG scripts, didn't you? At least from MS/PC-DOS 2.0
on (when redirection was introduced). There may still be a use for such
binaries for low-level operations, but file I/O isn't low-level.
>As for incorrectly typed binaries, cut and paste is one of the first things
>a Windows user would learn - surely you don't think the OPs mentioned above
>type in the code that is provided here?
Experience shows that as time goes on an files are copied from disk to
disk, the probability of anomalies occurring in those files increases.
Also stray keystrokes happen, and they're a lot easier to see in HLL
source code than pseudobinary dumps.
Tom Del Rosso
in news://44AF7D8F...@unibwm.de,
> Tom Del Rosso wrote:
>>
>> Thanks. I have that one, but I hoped to avoid requiring yet another
>> utility on every target system.
>
> @echo off
> echo
> Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
> echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY
> Wv;ovBX2Gv0ExGIuht6>>dup.com echo
> @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
>
> dir | dup >dirlist
> del dup.com
Thanks a lot. It's an ingenious little program, but I don't like the idea
of scripting assembly language. At the minimum I would have to
reverse-engineer it before allowing it to run on a server, and Debug doesn't
recognise some of the opcodes. Does it use 32 bit instructions? Debug's
Trace command can trace 32 bit code, but even what it understands is a
little mysterious, like why push ax six times?
The source code is interesting. It seems to be a subset of assembly that
can be encoded in ASCII, but the only reason I can think of for not using
standard mnemonics is because some of those mnemonics need to produce
self-modifying machine code to become the final product. I didn't do enough
reverse-engineering to see if it does that, but it's not something I can
rely on. If my predecessor had done something like that and I had to
maintain his system, I'd have to tear it out and start over.
It is ingenious though. :)
Tom Del Rosso
in news://1152391556.0...@m79g2000cwm.googlegroups.com,
> Most of use who respond tend to provide fish to OPs rather than teach
> them how to fish for themselves, but at least most solutions allow OPs
> to play with and extend the solutions. Assembler binaries don't. For
> the OP to extend such solutions, they'd need to find and install an
> ASCII Assembler and learn op code mnemonics.
I do know opcode mnemonics -- just not those. :)
(I even know a few machine codes. Did you ever notice that F6 is both
integer divide and the ASCII divide symbol? Makes it easy to spot the
divide instructions in hex dumps, if that ever becomes useful.)
> @REM name this batch file tee.bat
> @echo off
> echo Dim s > %0.vbs
> echo Do While Not WScript.StdIn.AtEndOfStream >> %0.vbs
> echo s = WScript.StdIn.ReadLine >> %0.vbs
> echo WScript.StdOut.WriteLine s >> %0.vbs
> echo WScript.StdErr.WriteLine s >> %0.vbs
> echo Loop >> %0.vbs
> cscript //nologo %0.vbs
> del %0.vbs
>
> Then use this batch file in commands like
>
> dir *.xyz | tee > outputfile
Thank you. That's very elegant. In the immediate case all I have to
capture and display is the output of echo and other internal commands, so
it's easier to just repeat the command.
If I had to capture from commands that do more than output text then I might
use this. Even then I have to consider that other people might need to read
and follow my code, and the temporary file method is easiest to understand.
> This also takes advantage of the fact that batch files running under
> CMD can use different, specific standard I/O streams for individual
> commands within the batch file in addition to the standard I/O streams
> for the batch file itself. The dup.com command above could be used
> similarly.
Interesting. Thanks for that insight.
> Further, typos that could occur in VBScript code would likely lead to
> syntax errors and only potentially overwrite the output file, while
> typos in ASCII Assembler could have arbitrarily destructive effects.
> ASCII Assembler should be viewed as a last resort.
I agree with that. Corrupted machine code is unlikely to do damage, but it
sure doesn't exit gracefully. It's also hard to add remarks to scripted
machine code, and I do have to document things.
Harlan Grove
...
>>ASCII Assembler should be viewed as a last resort.
>
>Only somebody who doesn't understand the principles of batch
>included CPU instructions can write such a sentence. It is
>the most powerful and flexible way to overcome the limitations
>of batch programming and doesn't rely on the existence of
>any external program in order to execute the batch program.
A loaded gun is the most powerful and flexible tool for acquiring any
type of automobile one may want, but most people would consider it a
bad idea to use one to get a Porsche.
OK, I admit my bias. I learned scripting on Unix systems, and the key
feature of Unix scripting is the presence of what's become the
POSIX-mandated tool set. The notion that all one needs is a command
interpreter and ad hoc binaries generated by echo commands may be true,
but that's not the same as saying that's a sensible way to do anything.
Few Windows PCs lack WSH. Would you claim that echoed binaries are
preferable to VBScript or JScript scripts for operations like this? And
systems without WSH would have DEBUG.COM as long as no one had removed
it. Would you also argue that one mustn't assume the presence of
standard Windows utilities? If one may assume DEBUG, then another
alternative would be
@REM name this batch file foo.bat
@echo off
(
echo/a100
echo/MOV CX,0080
echo/MOV DX,0080
echo/MOV AH,3F
echo/MOV BX,0000
echo/INT 21
echo/JB 012C
echo/CMP AX,0000
echo/JZ 012C
echo/PUSH CX
echo/MOV CX,AX
echo/MOV AH,40
echo/MOV BX,0001
echo/INT 21
echo/JB 012C
echo/MOV AH,40
echo/MOV BX,0002
echo/INT 21
echo/JB 012C
echo/JMP 0106
echo/NOP
echo/MOV AX,4C00
echo/JNB 0132
echo/INC AX
echo/INT 21
echo/
echo/r cx
echo/134
echo/n $$tee$$.com
echo/w
echo/q
) | debug 1> nul 2>&1
$$tee$$
del $$tee$$.com
I'll grant that a knowledge of 16-bit MS-DOS Assembler mnemonics well
into the 32-bit Windows era is at best arcane, but DEBUG still seems
serviceable. And I'd also claim that it's more understandable that your
echoed binary.
While most OPs may only be seeking a quick, workable answer, no one
should ever run anything from ng responses unless they have some
understanding what it does. How understandable is
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY
Wv;ovBX2Gv0ExGIuht6>>dup.com
echo @VyI?@xAp~sA`LZNxOq@Kt@FB?sUs`LbLB?tgj`{gjB~0x>>dup.com
?
foxidrive
> no one
> should ever run anything from ng responses unless they have some
> understanding what it does.
Not meaning to turn this sideways into an argument, because we all have our
own points that are valid, but the above is a specious argument, Harlan.
Many OPs do not understand the code that is presented to them, whether it
be plain batch, WSH, GAWK or SED code.
While it is true that these are more often understood by many users, it
doesn't follow that a user has to learn gawks idosyncratic syntax before
they use a gawk based solution, for example. That's akin to providing a
solution but asking them to learn what you know about the tool before using
it.
I grant that the advantage of the textual scripts is that they might more
readily learn something of the task, but only if they choose to study it.
Timo Salmi
>> 94) Can I send the script's output both to the screen and a log file?
>> 167495 Jun 18 2006 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
>> tscmd.zip Useful NT/2000/XP script tricks and tips, T.Salmi
> Specifically in file 1CMDFAQ.TXT in that compressed folder.
Yes, Larry, thanks. I added your gawk solution to the item.
Timo Salmi
> Herbert Kleebauer wrote... ...
>
>>> ASCII Assembler should be viewed as a last resort.
>>
>> Only somebody who doesn't understand the principles of batch
>> included CPU instructions can write such a sentence. It is
> A loaded gun is the most powerful and flexible tool for acquiring
> any
Indeed. It is not irrational to want to understand the solutions one
uses. ASCII assembler is obviously powerful, but outside a layman's
(such as yours) understanding. But, more solution options is better
than less. The final choice is the user's.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Herbert Kleebauer
> Herbert Kleebauer wrote...
> I'll grant that a knowledge of 16-bit MS-DOS Assembler mnemonics well
> into the 32-bit Windows era is at best arcane, but DEBUG still seems
> serviceable. And I'd also claim that it's more understandable that your
> echoed binary.
Don't worry, as far as I have understood, Vista doesn't support
16 bit programs anymore, so the use of debug scripts or ASCII
code will very fast come to an end.
> While most OPs may only be seeking a quick, workable answer, no one
> should ever run anything from ng responses unless they have some
> understanding what it does. How understandable is
>
> echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>dup.com
That doesn't make any sense. How understandable is the binary of
sed or gawk? If you want to understand the code, you have to look
at the source code and not at the binary (and I have posted the
source). And if you don't believe that the source belongs to the
posted binary, ignore the binary and a assemble the source
yourself. But you can't compare the posted binary with the command
which invokes sed. You have to compare the binary of sed with the
posted ASCII program and the invocation of sed with invocation of the
ASCII program. And I'm sure, the source of the posted ASCII program
is much easier to understand than the source of sed and I also don't
see any problem in understanding the invocation of the ASCII program:
dir | dup >dirlist
Clay Calvert
wrote:
>Don't worry, as far as I have understood, Vista doesn't support
>16 bit programs anymore, so the use of debug scripts or ASCII
>code will very fast come to an end.
The 32-bit versions of Vista should support 16-bit programs, but the
64-bit versions will not, at least not directly.
Read the 9th and 13th post in this thread.
http://groups.google.com/group/alt.msdos.batch/browse_frm/thread/73fa256edf7cedbf/614084030d11fa89
Note also that when running VMware in 64-bit XP that DOS, Win3.x and
Win9x run fine. I'm sure the same will be true for VirtualPC and
VirtualServer so the capability to run 16-bit code is going to be
around for a long while.
Now for my 2 cents. A few dozen bytes in size .com file from someone
who has been a regular in this group for years doesn't scare me nearly
as much as multi-megabyte 32 bit files found on the 'net.
I downloaded a 12MB file the other day to get a codec, and I ended up
scanning it three different ways, and installed it in a sacrificial
virtual machine first.
Clay Calvert
CCal...@Zanguru.com
Replace "Z" with "L"
Ted Davis
wrote:
A more general solution that doesn't hard code the target file, and
can therefore be made into a standard utility is
@%* | awk "{print;print > \"/dev/stderr\"}"
which, if named AWKTEE.CMD would be used like this
awktee ver 2> outputfile.txt
--
T.E.D. (tda...@gearbox.maem.umr.edu)
Harlan Grove
...
>That doesn't make any sense. How understandable is the binary of
>sed or gawk? If you want to understand the code, you have to look
>at the source code and not at the binary (and I have posted the
>source). And if you don't believe that the source belongs to the
>posted binary, ignore the binary and a assemble the source
>yourself. But you can't compare the posted binary with the command
>which invokes sed. You have to compare the binary of sed with the
>posted ASCII program and the invocation of sed with invocation of the
>ASCII program. And I'm sure, the source of the posted ASCII program
There's a difference between sed and gawk on the one hand and your code
on the other: the number of people who have read it and do use it. I'd
figure as many people have gone through sed's and gawk's source code as
have used any ASCII binaries whether the latter group understood the
source code or not. Further, if there were problems in any ASCII
binaries in the alt.msdos.batch* ngs, news of that would appear in
those ngs and where else? On the other hand, when there are problems in
sed or gawk, there would be bug reports in sourceforge, ngs specific to
each application, possibly also in these ngs, and other Unix-on-Windows
forums.
Next, if one really wanted to, one could also build sed or gawk from
their respective source code files. But that gets to a chicken-and-egg
problem: you then have to trust the assembler or compiler used to
convert source code into binary. Taking this to the logical extreme,
each of us would need to create our own bootstrap assembler to begin
the process of creating fully capable assemblers and compilers.
Point: unless we want to recreate ALL programming tools from scratch,
we have to trust someone's pre-built software. The advantage of GNU
software over that from single individuals (no matter how capable, no
matter how experienced) is that GNU source code has been read and
maintained by hundreds if not thousands of individuals over decades,
and existing pre-built binaries used now by millions. Problems are much
more likely to be found, diagnosed and fixed more quickly.