TCC11 newbie question re using '>>clip:'

[mikea]

I've used JP Software products for a very long time but am new to TCC starting with version 11. I was able to go on using 4NT for the longest time, but a requirement to change to Win 7 at work pretty well made that a thing of the past and I'm now a registered TC/TCC user.

The first batch file I transferred over from 4NT to TCC is failing. It's an oldie and a simple one -- purpose: copy paths to the clipboard. Like this:

>clip:
 ::  Ensure nothing's in the clipboard. Then:

do _thisfile in %*
    echo %@full[%_thisfile]>>clip:
 enddo

It works fine under 4NT. There is no screen display and the desired information is copied to/appended to the clipboard.

But the response from TCC is:

TCC: (Sys) C:\batch\clipit.btm [7] The operation completed successfully.
"C:\Users\marst\AppData\Local\Temp\COUT6ac.JPS"

Line 7 in the actual .btm file is the one reading "echo %@full[%_thisfile]>>clip:"

And afterward: there's nothing in the clipboard at all.

Ok, what's up here? Why is there an announcement that the operation completed successfully? (no such message appears under 4NT) And, why nothing in the clipboard?

If I type the following at the TCC prompt:

echo [EMAIL="%@full%5Bfilename.txt"]%@full[filename.txt[/EMAIL]] > clip:

It does exactly what I'm after.

In the failing .btm file, if in the line containing ">>clip:" above, I change it to ">clip:" (only one ">"), it does work. But then of course it copies only a single fully qualified path to the clipboard, which is NOT what I'm after.

What am I doing wrong here? (It sure seems right enough, per the old 4NT way of doing things. Is there some radically different way in which this should be done under TCC?)

 

[Steve Fabian]

| The first batch file I transferred over from 4NT to TCC is failing.
| It's an oldie and a simple one -- purpose: copy paths to the
| clipboard. Like this:
|
| Code:
| ---------
| >clip:
| :: Ensure nothing's in the clipboard. Then:
|
| do _thisfile in %*
| echo %@full[%_thisfile]>>clip:
| enddo
| ---------
|
| It works fine under 4NT. There is no screen display and the desired
| information is copied to/appended to the clipboard.
|
| But the response from TCC is:
| *TCC: (Sys) C:\batch\clipit.btm [7] The operation completed
successfully.
| "C:\Users\marst\AppData\Local\Temp\COUT6ac.JPS"
| ...
| And afterward: there's nothing in the clipboard at all.
| Ok, what's up here? Why is there an announcement that the operation
| completed successfully? (no such message appears under 4NT) And, why
| nothing in the clipboard?
|
| If I type the following at the TCC prompt:
|
| Code:
| ---------
| echo %@full[filename.txt (%@full%5Bfilename.txt)] > clip:
| ---------
| It does exactly what I'm after.

You did not mention which version of 4NT you use, but I tested the
issue with versions 6, 7 and 8, and they all work as you described.

Apparently there is a change in the clipboard implementation from 4NT
to TCC. This is relevant only if you use the NoClobber=yes option AND
empty the clipboard before appending to it. Your original batch file
works in TCC if you set NoClobber=NO.

Based on the clues from the various error messages, it seems that the
4NT command to empty the clipboard did not delete the special file
the command processor uses for clipboard communication, just set its
size to zero. The same command in TCC apparently deletes the special
file. When you attempt to append to it, the NoClobber feature is
preventing you - the file does not exist! The alternate explanation
is that 4NT ignored the NoClobber feature when the target was the
clipboard.

Rex, regardless of the correct explanation, IMHO backward
compatibility is needed in this case.
--
Steve

 

[rconn]

> The first batch file I transferred over from 4NT to TCC is failing.
> It's an oldie and a simple one -- purpose: copy paths to the clipboard.
> Like this:
>
> Code:
> ---------
> >clip:
> :: Ensure nothing's in the clipboard. Then:
>
> do _thisfile in %*
> echo %@full[%_thisfile]>>clip:
> enddo
> ---------

The problem (which goes back several versions) turns out to be the ">clip:"
line followed by the "...>>clip:" line. (It works without the ">clip:", or
if the next redirection is a write rather than an append.)

The curious thing is that the Windows API claims it failed, but it's
actually working. TCC gets the failure return, and prints the error code
(which doesn't exist) and returns without processing anything else. It also
seems to be timing dependent, which will make it considerably more
aggravating to track down.

Rex Conn
JP Software

 

[mikea]

(Steve and Rex: thanks for your replies. Steve: I stopped upgrading at 4NT v.5. There was no budget at work that would have enabled me to upgrade our multi-seat 4NT license, past that point. I was grateful to have been able to go on running it in compatibility mode.)

This will be an interesting challenge. I use ">CLIP:" a lot in the many .btm files I have. I suppose a simple kludge like type nul>clip: isn't going to fix this. (The "if 'x' didn't work, try alternative 'y' -- and for good measure, shake the feathers and chicken bones" solution.)

I was so eager to get started, I haven't even yet gone through the TC/C documentation. Probably answered there: does the file used to hold clipboard contents have a consistent name? Or does its name vary a la %@unique[]? (assigned to whatever name TCC decides on at a given moment?). Maybe I could explicitly create a zero-byte temp. clipboard file first, or something like that.

Or use some other temp. file entirely and at the end:

type filename > clip:

That's how I have to do it with the cmd.exe alternative on machines without 4NT (type filename | clip.exe).

BUT . . . is ">filename" itself generally going to be difficult under Win7? Whew. I use that a whole lot...

It's been so long since I had to make any major configuration changes, I am embarrassed to say I've forgotten just what NOCLOBBER does. I'll look it up. My vague recollection is that I did not want to set it as recommended earlier in this thread.

 

[mikea]

Following from

if the next redirection is a write rather than an append

I'm not at a machine with TCC at the moment, but it occurs to me that perhaps this might do it:

first: >CLIP: (or type nul>CLIP:)

and then in a loop in which I'm collecting the filenames

[FONT=Courier New][SIZE=2]iff "%@clip[0]" == "" then
  echo %@full[filename] >clip:
else
  echo %@full[filename] >>clip:
endiff[/SIZE][/FONT][SIZE=2]
[/SIZE]

We'll see . . .

 

[Jim Cook]

Rex _just_ posted a new build announcement, so maybe that'll fix it faster :)

On Wed, Dec 9, 2009 at 1:00 PM, mikea <> wrote:

> Following from
>
>
> ---Quote---
> if the next redirection is a write rather than an append
> ---End Quote---
> I'm not at a machine with TCC at the moment, but it occurs to me that perhaps this might do it:
>
> first: **>CLIP:* * (or *type nul>CLIP:*)
>
> and then in a loop in which I'm collecting the filenames
>
>
> Code:
> ---------
> iff "%@clip[0]" == "" then
> *echo %@full[filename] >clip:
> else
> *echo %@full[filename] >>clip:
> endiff
> ---------
> We'll see . . .
>
>
>
>
>
>
>

--
Jim Cook
2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Sunday.

 

[rconn]

> This will be an interesting challenge. I use ">CLIP:" a *lot* in the
> many .btm files I have. I suppose a simple kludge like *type nul>clip:*
> isn't going to fix this. (The "if 'x' didn't work, try alternative 'y'
> -- and for good measure, shake the feathers and chicken bones"
> solution.)

It's fixed in build 35 (already uploaded).

Rex Conn
JP Software

 

[Steve Fabian]

Mike,
as usual Rex has already solved the problem - just download Build 35! All
your old files ought to work (at least as far as this specific issue is
considered).

Thanks, Rex, for your usual quick solution!
--
Steve

 

[mikea]

Wow. Cool. (I swear, in all the years I've used software, I have never seen a product whose authors' responsiveness is as impressive as JPSoft's. This company's agility is the Gold Standard...)

And, I'm totally embarrassed to admit that it has been SO long since I have been involved in getting updates -- I have forgotten how to do it! Just find the distribution archive here on the site (presumably an installer application), run it, and point it to the current TC/TCC directory? (The registration does not need to be re-done, I would assume.)

Off-topic: just had a conversation with someone who had seen a message I posted (elsehwere) in which you have to do quite a lot of fancy footwork to get cmd.exe to enumerate individual directories in the %path%. You'd think it would be a simple case of "for /f":

for /f "delims=;" %%A in ("%PATH%") do echo %%A

Wrong. Nice try, but no cee-gar. There's apparently some bug that makes this (so far) impossible, no matter what variation on the "for" theme you use.

The guy was sure that "for /f" ought to do the trick. I am showing him it can't. This is either a bug or a feature, I don't know which. :-)

Then I showed him:

echo %@replace[;,%=n,%path]

He's been quiet ever since. :-)

Mike,
as usual Rex has already solved the problem - just download Build 35! All
your old files ought to work (at least as far as this specific issue is
considered).

Thanks, Rex, for your usual quick solution!
--
Steve

 

[vefatica]

Off-topic: just had a conversation with someone who had seen a message I posted (elsehwere) in which you have to do quite a lot of fancy footwork to get cmd.exe to enumerate individual directories in the %path%. You'd think it would be a simple case of "for /f":

Nice try, but no cee-gar. There's apparently some bug that makes this (so far) impossible, no matter what variation on the "for" theme you use.

It's not so hard with FOR in TCC:

v:\> for /t";" %x in ( %path ) echo %x
D:\watcom1.3\binnt
D:\watcom1.3\binw
D:\Perl\site\bin
D:\Perl\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Common Files\Roxio Shared\DLLShared\
C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\
d:\uty
d:\ttk
G:\VS2008\VC\bin
D:\DK7\
D:\MSTools
d:\windump
D:\NetMon3\

 

[mikea]

It's not so hard with FOR in TCC:

v:\> for /t";" %x in ( %path ) echo %x

That's an impressively expanded 'for' command, I must say (I'm still only just barely scratching the surface of the TCC docs). I suspect that when I run that one by the other fellow, he's still going to remain silent. :-)

The interesting challenge with TCC and all those old 4NT batch files will be: it was a seamless transition from 4DOS to 4NT, and I retained the original 4DOS-style command separators, rather than have to edit all those .btm files. Well, it makes no sense to keep on using ancient 4DOS-style separators and param characters, so I have some major batch-file alterations to do now. There's a substantial project...

 

[rconn]

> And, I'm totally embarrassed to admit that it has been *SO* long since
> I have been involved in getting updates -- I have forgotten how to do
> it! Just find the distribution archive here on the site (presumably an
> installer application), run it, and point it to the current TC/TCC
> directory? (The registration does not need to be re-done, I would
> assume.)

If you're already running Take Command v11, just click on Help / Check for
Updates. That will show the latest update, and you can click on that to
install it.

If you're running an older version, go to the web site and click on
Downloads.

Rex Conn
JP Software