How to? Copy current directory to clipboard

[Avi Shmidman]

I often need to copy the current directory to the clipboard, for later use in composing TCC commands. I attempted to create an alias for this operation, but I have not yet found the right approach. I tried the following:
echo %_cwds > clip:
However, this has two problems:
1] It includes a CR/LF at the end, so if I paste it on the command line, the command line executes immediately, without giving me a chance to edit it as necessary.
2] Because I have "UnicodeOutput" enabled, the resulting clipboard data includes a BOM at the beginning (FF FE). This prevents TCC from properly pasting the data back into the command line - when I click "paste" on the command line, I get a question mark at the beginning of the path. (Is this WAD? I note that I can successfully paste the same clipboard data into Notepad, or MS Word, or into the unicode editor EditPadPro, and these programs all ignore the BOM and paste only the text; wouldn't it make sense for TCC to also ignore any BOM at the beginning of the clipboard when pasting text?)

In any case, my question remains: how can I copy the value of %_cwds directly to the clipboard, without the leading BOM, and without the CR/LF at the end?
Alternatively, is there any way from within TCC to slightly modify the clipboard after the "echo" command, in order to remove removing the inital two bytes and the final four bytes?

 

[Steve Fabian]

Try ECHOS - it will not insert the line terminator. You can use the n-th line of the clipboard, without line terminators (whether or not they are in the clipboard) using @clip[n] (0-based!!!). I presume that this would not include a BOM, either - I use ASCII output, so I cannot test. HTH.

 

[Avi Shmidman]

Thanks, Steve! That did the trick regarding the line terminator.
I still have the problem with the initial BOM, however. Rex - is it possible to have TCC ignore a BOM upon paste from the clipboard?
In truth, what I really would like is a way to avoid having that BOM on the clipboard in the first place, because I see now that it does cause problems in some other apps as well. For instance, if I echo the cwd to the clipboard, and then go to Windows-Start-Menu/Run and paste in the path, Explorer cannot process the directory path.
Ideally, I'd suggest, can TCC avoid writing a BOM when redirecting to the CLIP:? I realize this may be too convoluted (because it would require that the redirection operator have special processing depending on the nature of the output device), so instead I think the problem could also be neatly solved with the addition of a TCC option to turn off BOM creation for redirection. That way I can have my alias first turn off BOM creation, then do the redirection, and then reenable BOM creation. What do you think?
(Steve - you are correct that @clip[] takes the text without the BOM. However, as far as I understand, although that helps for batch processing, it won't help me when I want to paste text at will on the clipboard with Ctrl-V.)

Try ECHOS - it will not insert the line terminator. You can use the n-th line of the clipboard, without line terminators (whether or not they are in the clipboard) using @clip[n] (0-based!!!). I presume that this would not include a BOM, either - I use ASCII output, so I cannot test. HTH.

 

[Steve Fabian]

Pasting from the clipboard should never insert a BOM, because it is not necessarily pasted at the beginning of a file (the only place BOM belongs). AFAIK ctrl-V pastes FROM the clipboard (without changing its content). Placing data in the clipboard using the "cut" (ctrl-X) or "copy" (ctrl-C) edit keys is a different issue.

 

[vefatica]

After starting TCC with /U (Unicode output) and executing "ECHOS %_CWDS > clip:" I do not get a BOM (?) when I paste to the console using Ctrl-V. I do get the extra character if I paste with a right-click. It's similar inside TCMD ... paste with Ctrl-V, no BOM ... paste with the right-click menu, BOM. I doubt Rex has any control over the console's (QuickEdit's) right-click pasting; don't know about TCMD's right-click menu. Since it was introduced, I have always used Ctrl-V anyway; it's easier.

 

[Avi Shmidman]

Hi Vince,
This is mind-boggling! I'm not using the right click or Ctrl-V; rather I'm using Shift-Ins. I would have thought it a fair assumption that Ctrl-V and Shift-Ins would be mapped to the same routine - yet here we see a drastic difference between their behavior - one pastes with the BOM, and one pastes without!
I don't know which one reflects the default console processing, but it seems that one of the shortcut keys is undergoing some special processing in TCC, while the other is not.

After starting TCC with /U (Unicode output) and executing "ECHOS %_CWDS > clip:" I do not get a BOM (?) when I paste to the console using Ctrl-V. I do get the extra character if I paste with a right-click. It's similar inside TCMD ... paste with Ctrl-V, no BOM ... paste with the right-click menu, BOM. I doubt Rex has any control over the console's (QuickEdit's) right-click pasting; don't know about TCMD's right-click menu. Since it was introduced, I have always used Ctrl-V anyway; it's easier.

 

[Avi Shmidman]

OK, I see now that the problem recurs with any keyboard shortcut that is registered in Customize/Keyboard under Edit/Paste. For instance, I tried setting edit/paste to be ctrl-shift-F8, and indeed, ctrl-shift-f8 produces the question mark.
On the flip side, Ctrl-V is not listed there as a keyboard shortcut; it seems to be an internal keypress, rather than an externally configured keypress. And that makes all the difference here.
In any case, I think this qualifies as a bug - it doesn't make sense for the "paste" action to be different depending on whether the internal shortcut is used or whether a separate shortcut is set. And I believe the correct behavior is that of the Ctrl-V keypress (i.e., no BOM).

Hi Vince,
This is mind-boggling! I'm not using the right click or Ctrl-V; rather I'm using Shift-Ins. I would have thought it a fair assumption that Ctrl-V and Shift-Ins would be mapped to the same routine - yet here we see a drastic difference between their behavior - one pastes with the BOM, and one pastes without!
I don't know which one reflects the default console processing, but it seems that one of the shortcut keys is undergoing some special processing in TCC, while the other is not.

 

[rconn]

I still have the problem with the initial BOM, however. Rex - is it possible to have TCC ignore a BOM upon paste from the clipboard?

Fixed in 13.04.58 (already uploaded).

 

[rconn]

Hi Vince,
This is mind-boggling! I'm not using the right click or Ctrl-V; rather I'm using Shift-Ins. I would have thought it a fair assumption that Ctrl-V and Shift-Ins would be mapped to the same routine - yet here we see a drastic difference between their behavior - one pastes with the BOM, and one pastes without!

Shift-Ins is done in TCMD, Ctrl-V is done in TCC.

 

[Avi Shmidman]

Thanks, Rex. The fix works perfectly!

Shift-Ins is done in TCMD, Ctrl-V is done in TCC.