tcl 8.6.7 - arguments on Windows (10) are not handled correctly

[MartinLemburg@Siemens-PLM]

Hi,

I just observed accidentally the follwing behavior starting a tcl script with a typo:

> C:\Users\lemburg\Favorites\Links\git\14.1>c:\tcl\changeShortcuts.tclsh "%CD%" "*" "Master\" "" all
tclsh.exe 8.6.7
wrong # args: should be "changeShortcuts.tclsh path shortcutGlobPatterns pathREPattern replacement ?recursive? ?all? ?nocase?

identified arguments:
1. path = 'C:\Users\lemburg\Favorites\Links\git\14.1'
2. shortcutGlobPatterns = '*'
3. pathREPattern = 'Master" " all'

Then I used a BATch file to display the arguments the BATch file receives:

> C:\Users\lemburg\Favorites\Links\git\14.1>test.bat "%CD%" "*" "Master\" "" all
%* = "C:\Users\lemburg\Favorites\Links\git\14.1" "*" "Master\" "" all
1. "C:\Users\lemburg\Favorites\Links\git\14.1"
2. "*"
3. "Master\"
4. ""
5. all

So - the tcl shell has a problem in parsing the arguments?
Why?
Are all arguments first concatenated and then splitted? But not according to the eventually platform dependent rules?

Should I file a bug?

Best reagrds

Martin

[Brad Lanam]

It's not a bug.

In Windows, the application processes the command line arguments,
whereas in Linux, the shell processes the command line arguments
and passes them to the application.
So you cannot compare how cmd.exe/batch and tclsh.exe process arguments.

[MartinLemburg@Siemens-PLM]

Hi Brad,

Hhm.

So, if I build commandline tools for Windows user, but those do not behave like other Windows commandline tools and I do not have the ability to adopt the "normal" Windows behavior, than it is a bug … for the user and my problem.

No - to be serious. I just build a Win32 console executable with VS2015 just to see the arguments coming in and I'm surprised, that those characters, that have no special meaning in the command prompt like "\" has its escaping meaning in the arguments.

This means, that paths enclosed in double quotes can not end with a backslash, which is a path separator.
Example:

> test.exe c:\temp abc
1. c:\temp
2. abc
> test.exe c:\temp\ abc
1. c:\temp\
2. abc
> test.exe "c:\temp\" abc
1. "c:\temp" abc

This behavior is counter intuitive.

But that's the way life goes.

Best regards,

Martin

[Robert Heller]

At Thu, 29 Mar 2018 05:04:19 -0700 (PDT) "MartinLemburg@Siemens-PLM" <martinlemb...@gmail.com> wrote:

>
> Am Donnerstag, 29. M=C3=A4rz 2018 13:26:59 UTC+2 schrieb Brad Lanam:
> > On Thursday, March 29, 2018 at 4:07:32 AM UTC-7, MartinLemburg@Siemens-PL=
> M wrote:
> > > I just observed accidentally the follwing behavior starting a tcl scrip=
> t with a typo:
> > >=20
> > > > C:\Users\lemburg\Favorites\Links\git\14.1>c:\tcl\changeShortcuts.=

> tclsh "%CD%" "*" "Master\" "" all
> > > tclsh.exe 8.6.7

> > > wrong # args: should be "changeShortcuts.tclsh path shortcutGlobPat=

> terns pathREPattern replacement ?recursive? ?all? ?nocase?

> > >=20
> > > identified arguments:
> > > 1. path =3D 'C:\Users\lemburg\Favorites\Links\git\14.1'
> > > 2. shortcutGlobPatterns =3D '*'
> > > 3. pathREPattern =3D 'Master" " all'
> > >=20
> > > Then I used a BATch file to display the arguments the BATch file receiv=
> es:
> > >=20
> > > > C:\Users\lemburg\Favorites\Links\git\14.1>test.bat "%CD%" "*" "Ma=
> ster\" "" all
> > > %* =3D "C:\Users\lemburg\Favorites\Links\git\14.1" "*" "Master\" ""=

> all
> > > 1. "C:\Users\lemburg\Favorites\Links\git\14.1"
> > > 2. "*"
> > > 3. "Master\"
> > > 4. ""
> > > 5. all

> > >=20

> > > So - the tcl shell has a problem in parsing the arguments?
> > > Why?

> > > Are all arguments first concatenated and then splitted? But not accordi=

> ng to the eventually platform dependent rules?

> > >=20

> > > Should I file a bug?

> >=20
> >=20

> > It's not a bug.

> >=20

> > In Windows, the application processes the command line arguments,

> > whereas in Linux, the shell processes the command line arguments=20

> > and passes them to the application.
> > So you cannot compare how cmd.exe/batch and tclsh.exe process arguments.
>
> Hi Brad,
>
> Hhm.
>

> So, if I build commandline tools for Windows user, but those do not behave =
> like other Windows commandline tools and I do not have the ability to adopt=
> the "normal" Windows behavior, than it is a bug =E2=80=A6 for the user and=
> my problem.
>
> No - to be serious. I just build a Win32 console executable with VS2015 jus=
> t to see the arguments coming in and I'm surprised, that those characters, =
> that have no special meaning in the command prompt like "\" has its escapin=

> g meaning in the arguments.
>

> This means, that paths enclosed in double quotes can not end with a backsla=

> sh, which is a path separator.
> Example:
>
> > test.exe c:\temp abc
> 1. c:\temp
> 2. abc
> > test.exe c:\temp\ abc
> 1. c:\temp\
> 2. abc
> > test.exe "c:\temp\" abc
> 1. "c:\temp" abc
>
> This behavior is counter intuitive.

That pretty much sums up what passes for the command line under MS-Windows.

>
> But that's the way life goes.
>
> Best regards,
>
> Martin
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Ashok]

You might see if get_command_line and get_command_line_args from the
TWAPI extension work more to your liking. The latter is supposed to
follow Windows convention (insofar as there is one!).

/Ashok

[Harald Oehlmann]

Ashok,

those are complete new books itself ! Thank you for the great work !

Thanks,
Harald