Unix/Linux-style paths

smf

Aug 3, 2015
10
0
#1
I posted about this a few months ago, but didn't get a reply. I've reproduced the issue with a script this time, although it affects binaries as well.

By default CMD supports Unix paths, but TCCLE needs UnixPaths=Yes in TCMD.INI. However while TCCLE gets %0 correct, %1 starts from the / in the script name.

Incorrect results from TCCLE, followed by correct results from CMD.

TCC LE 14.00.8 x64 Windows 10 [Version 6.3.10586]
Copyright 2016 JP Software Inc. All Rights Reserved

[C:\Program Files\JPSoft\TCCLE14x64]type \temp\x.cmd
@echo "%0"
@echo "%1"

[C:\Program Files\JPSoft\TCCLE14x64]c:\temp\x.cmd
"c:\temp\x.cmd"
""

[C:\Program Files\JPSoft\TCCLE14x64]c:\temp/x.cmd
"c:\temp/x.cmd"
"/x.cmd"

[C:\Program Files\JPSoft\TCCLE14x64]cmd
Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Program Files\JPSoft\TCCLE14x64>c:\temp\x.cmd
"c:\temp\x.cmd"
""

C:\Program Files\JPSoft\TCCLE14x64>c:\temp/x.cmd
"c:\temp/x.cmd"
""

C:\Program Files\JPSoft\TCCLE14x64>
 

smf

Aug 3, 2015
10
0
#3
JP Software does not provide technical support for TCC/LE.

Your example works in Take Command / TCC v19.0.
I followed other examples of people posting bugs in the TCC/LE support forum and you fixing them and releasing new versions.
I have seen you state that TCC/LE is not based on TCC.

I am therefore confused by your reply.

Do you not accept that it is a bug in TCC/LE or
are you saying that you are only prepared to fix certain bugs in TCC/LE or
do you not want anyone to report bugs?
 

rconn

Administrator
Staff member
May 14, 2008
10,551
97
#4
I followed other examples of people posting bugs in the TCC/LE support forum and you fixing them and releasing new versions.
Your original post stated that you hadn't received any response to a previous bug report. JP Software provides no support for TCC/LE; this forum is strictly for peer-to-peer support of TCC/LE. Any posts in this forum from anyone at JP Software is unofficial and implies no promise of future support.

I have seen you state that TCC/LE is not based on TCC.
That is not entirely accurate -- TCC/LE is based on 4NT v6 (the precursor to TCC). It is not upgraded when new TCC versions are released, so the code base has been diverging for 10+ years.

Do you not accept that it is a bug in TCC/LE or
are you saying that you are only prepared to fix certain bugs in TCC/LE or
do you not want anyone to report bugs?
I do not think this is a TCC/LE bug; I would consider it more of a CMD curiosity when you pass a bad argument.

You are welcome to report bugs, but JP Software does not promise to respond or to fix any TCC/LE bugs. The TCC/LE code base is frozen and we do not intend to add any new features (ever). We may or may not provide new builds when Microsoft breaks something in new Windows versions.

That said, I tried your batch file in TCC/LE 14.00.09 (the current build) and it worked identically in CMD and TCC/LE.
 

smf

Aug 3, 2015
10
0
#5
I do not think this is a TCC/LE bug; I would consider it more of a CMD curiosity when you pass a bad argument.
I think there is some misunderstanding. I wasn't passing any arguments, by using a Linux path TCC/LE was thinking that part of the Linux path was an argument. It also affected situations where you did actually pass arguments as it thought there was an extra one.

But thank you for continuing looking at this, I do appreciate it. I've been an avid user of your command shells since the NDOS days & I realise that TCC/LE isn't revenue generating.

I'll download build 9 now.

Thanks
 

rconn

Administrator
Staff member
May 14, 2008
10,551
97
#6
I think there is some misunderstanding. I wasn't passing any arguments, by using a Linux path TCC/LE was thinking that part of the Linux path was an argument. It also affected situations where you did actually pass arguments as it thought there was an extra one.
You *are* passing an argument - %0 is a batch file argument.