Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Done Add an option to control command line parsing

Recently I find a problem on command line parsing involving "=".
For example, if we have the following script called "test.btm":
================================
echo %1;%2;%3;%4
================================

then running "test a=1 b=2" will display "a;1;b;2".

However, in earlier version of 4NT, the above script will display "a=1;b=2;;".

So the tests above show that current TCC/LE will regard "=" as one special char to seperate parameters. This behavior is not expected in most cases. Hence, I suggest JPSoft to add one option to SETDOS command so as to control whether to use "=" to parameter delimiter.

I am expecting next release of TCC/LE with new functions! :-)
 
who_are_you wrote:

> Recently I find a problem on command line parsing involving "=".
> For example, if we have the following script called "test.btm":
> ===============================> echo %1;%2;%3;%4
> ===============================>
> then running "test a=1 b=2" will display "a;1;b;2".
>
> However, in earlier version of 4NT, the above script will display "a=1;b=2;;".
>
> So the tests above show that current TCC/LE will regard "=" as one special
> char to seperate parameters. This behavior is not expected in most
> cases.

This is WAD, for compatibility with CMD.EXE. I think it would be a bad
idea to make this configurable, as it would result in more more
incompatibilities with existing batch files written for CMD.

Rex Conn
JP Software
 
who_are_you wrote:


> char to seperate parameters. This behavior is not expected in most
> cases.

This is WAD, for compatibility with CMD.EXE. I think it would be a bad
idea to make this configurable, as it would result in more more
incompatibilities with existing batch files written for CMD.

Rex Conn
JP Software

Is it very very important to make TCC compatible with CMD.exe? The reasons that I like to use 4NT and TCC/LE never include the compatibility with stupid CMD.exe. The problem here is that TCC and TCC/LE is not compatible with previous 4NT. I think many users may have the same feature request:-)

By the way, I always set my TCC/LE to use settings compatible with 4DOS. In this way, most of my very early 4DOS scripts can even run with TCC/LE. So I think many users will be happy to see compatibility with previous 4NT or 4DOS:-)
 
>Is it very very important to make TCC compatible with CMD.exe? The
reasons

>that I like to use 4NT and TCC/LE never include the compatibility with
>stupid CMD.exe. The problem here is that TCC and TCC/LE is not
compatible

>with previous 4NT. I think many users may have the same feature
request:-)

>
>By the way, I always set my TCC/LE to use settings compatible with
4DOS. In

>this way, most of my very early 4DOS scripts can even run with TCC/LE.
So I

>think many users will be happy to see compatibility with previous 4NT
or


Yes, it is very very important to make TCC compatible with CMD.exe.
First, there is the consideration of TCC/LE, which Rex provides for
free. It has to be 100% compatible (or at least as much as feasible)
with CMD.exe. It's intended to be a teaser to get the user into the TCC
world and make them want to upgrade (for a cost) to full TC.

More importantly, though, there are a lot of users who write their
scripts in TC, but also need them to work for other users who don't have
TC and run them in CMD. This is especially true of the installed base.
Eliminating the compatibility requirement breaks all of them. Rex would
lose a lot of customers if he didn't maintain compatibility wherever
possible.
 
Personally, I find that it's the scripts written for public consumption
that come packaged with certain tools for example that require the CMD
compatibility. I always create my TCC scripts with a BTM extension so
that I *know* they won't run in CMD.

-Scott

"JP Software Forums" <[email protected]> wrote on 01/07/2009 11:45:52 AM:


> Yes, it is very very important to make TCC compatible with CMD.exe.
> First, there is the consideration of TCC/LE, which Rex provides for
> free. It has to be 100% compatible (or at least as much as feasible)
> with CMD.exe. It's intended to be a teaser to get the user into the TCC
> world and make them want to upgrade (for a cost) to full TC.
>
> More importantly, though, there are a lot of users who write their
> scripts in TC, but also need them to work for other users who don't have
> TC and run them in CMD. This is especially true of the installed base.
> Eliminating the compatibility requirement breaks all of them. Rex would
> lose a lot of customers if he didn't maintain compatibility wherever
> possible.
>
>
>
>
 
samintz wrote:
| Personally, I find that it's the scripts written for public
| consumption
| that come packaged with certain tools for example that require the CMD
| compatibility. I always create my TCC scripts with a BTM extension so
| that I *know* they won't run in CMD.

IMHO the default for batch files with .CMD extension ought to be to emulate
the latest version of CMD as perfectly as possible, and for .BTM extension
to be backward compatible to earlier versions of JPsoft command processors,
with a method to switch between the modes for .BTM extension. Losing
backward compatibility alienates long-time JPsoft customers, and results in
many support requests, when "upgrading" kills long working batch programs,
esp. since there is no easy path to go back to the earlier versions after
using the MS installers.
--
Steve
 
who_are_you wrote:


> Is it very very important to make TCC compatible with
> CMD.exe?

Yes, it is very very important -- just witness the screams of outrage on
the support forum if I change something in TCC that introduces an
incompatibility with CMD.

The whole purpose of TCC is to be a superset of CMD. An incompatible
superset doesn't have much appeal!

Rex Conn
JP Software
 
On Wed, 07 Jan 2009 10:46:22 -0600, "JP Software Forums"
<[email protected]>,MickeyF <> wrote Re RE:
[Suggestions-t-734] Re: Add an option to control command line parsing:


>Yes, it is very very important to make TCC compatible with CMD.exe.

I agree.
--
At first they laugh at you, then they ignore you, then they fight you, then you win.
 

Similar threads

Back
Top