Community

Posted: **Sat Oct 13, 2018 10:36 am**

(I find no place for reporting bugs on this forum or https://www.textpad.com/support/ so I'm reporting this here.)

I was hoping that the upgrade to 8.1.1 would fix the long-standing failure of XCOPY in a tool, but sadly not.

On Windows 7 64-bit.

Code:
REM Run on TP 8.1.1 (64-bit edition) as tool https://i.imgur.com/xXY5IQH.png
echo test > %TEMP%\src.bat
del /q %TEMP%\dest.bat
xcopy %TEMP%\src.bat %TEMP%\dest.bat
dir /b %TEMP%\dest.bat
REM Expected: 1 File(s)
REM Observed: File not found https://i.imgur.com/nxRDqXh.png

When run outside TP, succeeds as expected https://i.imgur.com/nUbeplw.png
With XCOPY replaced by COPY, succeeds as expected https://i.imgur.com/LGYFng5.png.

Posted: **Mon Oct 15, 2018 7:45 am**

But your example showing it working outside TP uses copy, not xcopy

When using XCOPY to copy a source to a destination it normally prompts asking if the destination specifies a file or directory, but that may be OS version specific. The simple answer is to use copy, as you have found.

Posted: **Mon Oct 15, 2018 7:48 am**

chrisjj wrote:When run outside TP, succeeds as expected

This can't be true and your screenshot shows COPY, not XCOPY - the latter would always query if the destination is a file or directory. Try again "outside" TextPad with XCOPY.

Posted: **Mon Oct 15, 2018 10:58 am**

/I option assumes that a given destination is a directory.

Posted: **Mon Oct 15, 2018 11:38 am**

miked wrote:But your example showing it working outside TP uses copy, not xcopy

Oops! Well spotted. Thanks. That was a erroneous screenshot, now corrected to show that XCOPY does succeed outside TP.

miked wrote:When using XCOPY to copy a source to a destination it normally prompts asking if the destination specifies a file or directory, but that may be OS version specific.

Outside TP it does here.

And inside TP, feeding-in an 'f' gives success https://i.imgur.com/HcRYlA4.png .

So it seems that, inside TP, XCOPY is somehow being terminated before its prompt.

And not due to the prompt, it seems. Adding an asterisk to the destination path to specify a file and inhibit the prompt (outside TP https://i.imgur.com/AYqZsoE.png ) makes no difference to the fail inside TP https://i.imgur.com/Oa25rgV.png .

EDIT: XCOPY /? shows the same!

Outside TP, OK: https://i.imgur.com/FACCYOs.png

Inside TP, fail:

miked wrote:The simple answer is to use copy, as you have found.

That works in this minimal test case, but unfortunately not in general. COPY is not in general a substitute for XCOPY.

Posted: **Mon Oct 15, 2018 3:46 pm**

chrisjj wrote:inside TP, XCOPY is somehow being terminated before its prompt

Programs can detect if STDIN is available or not, and most likely TextPad does not provide any - hence XCOPY seems to act differently to you (when in fact it just corresponds to the environment and quits if no STDIN is available - unbound to if it ever needs it).

A workaround to simulate STDIN for that one query would be to use

Code: Select all

echo f | xcopy %temp%\src.txt %temp%\dst.txt

Posted: **Mon Oct 15, 2018 10:15 pm**

AmigoJack wrote:hence XCOPY seems to act differently to you (when in fact it just corresponds to the environment and quits if no STDIN is available - unbound to if it ever needs it).

If it is quitting due to STDIN being absent (needlessly in the /? case) then there's no 'seems'. It is acting differently.

AmigoJack wrote:A workaround to simulate STDIN for that one query would be to use
Code: Select all
echo f | xcopy %temp%\src.txt %temp%\dst.txt

Thanks. That will fail in other locales, but this version won't:

And echo fixes XCOPY /? too!

Community

8.1.1 Failure of XCOPY in a tool

8.1.1 Failure of XCOPY in a tool

Re: 8.1.1 Failure of XCOPY in a tool