I'm using magicsplat in windows which provide a tcl shell as an executable program tclsh.exe.

when using it I accidentally typed h in the shell and get what seems to be a command history list.

Being corious tried to see what command or proc it actually is:

% info procs h
% info commands h

there's no h command or proc, but there's a history command and it seems to produce the same results:

% h
1 h
% history
1 h
2 history
% h
1 h
2 history
3 h

so I suspect h is a kind of alias to history and tried to check it:

% interp aliases

get nothing, so h seems to be an alias to history but I cannot confirm it.

Maybe I don't have the needed knowledge for this but I have several questions about it:

1- how can I find the h thing in a list of tcl elements (procs, commands, aliases, classes, objects...) ?
2- shouldn't be a kind of symbols subcommand for info in a way you can get all symbols in tcl calling [info symbols] indendently the symbol being a proc a command a var or whatever?
3- shouldn't be tcl introspection more orthogonal? I mean: why info proc but interp aliases or package names rather than info procs and info aliases and info packages?

info symbols would be very interesting and appreciated because not having it you impose the user to know what is looking for, the use has to split the space of names about a name he doesn't know anything about (that's the reason for using introspection)

I know tcl have different name spaces for different objects, so you can have a proc named N and also a var named N and they are two different objects, but it would be useful something like this:

% foreach s [info symbols] { puts "$s - [info type $s]" }
N var
N proc
lsort proc
...

and that way you can search for existence with:

% info [info type $s] $s

my point with this email is not only suggesting possible improvements in handling introspection (or showing my lack of knowledge) but pointing out is should be easier for a user to find about defined symbols in tcl

regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 02.04.2022 um 17:59 schrieb pd:

I'm using magicsplat in windows which provide a tcl shell as an executable program tclsh.exe.

when using it I accidentally typed h in the shell and get what seems to be a command history list.

Being corious tried to see what command or proc it actually is:

% info procs h
% info commands h

there's no h command or proc, but there's a history command and it seems to produce the same results:

% h
1 h
% history
1 h
2 history

Yes, bug or feature. If it is unique, you can shortcut any command. If
you define a second command starting with h, it will not work any more.

% h
1 h
% proc help {} {puts help}
% h
ambiguous command name "h": help history

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El sábado, 2 de abril de 2022 a las 18:45:49 UTC+2, Harald Oehlmann escribió:

there's no h command or proc, but there's a history command and it seems to produce the same results:

Yes, bug or feature. If it is unique, you can shortcut any command. If
you define a second command starting with h, it will not work any more.

thanks for clarifying , I clearly would put it into the bug bag ;-)

anyway I find more interesting discussing about the apparent lack of orthogonality in tcl , what do you think about it?

regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 02.04.22 um 18:45 schrieb Harald Oehlmann:

Am 02.04.2022 um 17:59 schrieb pd:

I'm using magicsplat in windows which provide a tcl shell as an
executable program  tclsh.exe.

when using it I accidentally typed h in the shell and get what seems
to be a command history  list.

Being corious tried to see what command or proc  it actually is:

% info procs h
% info commands h

there's no h command or proc, but there's a history command and it
seems to produce the same results:

% h
      1  h
% history
      1  h
      2  history

Yes, bug or feature. If it is unique, you can shortcut any command. If
you define a second command starting with h, it will not work any more.

 % h
     1  h
% proc help {} {puts help}
% h
ambiguous command name "h": help history

...and that is only valid for interactive shells (with tcl_interactive
set to 1).

(chris) 59 % set tcl_interactive 1
1
(chris) 60 % pu
wrong # args: should be "puts ?-nonewline? ?channelId? string"
(chris) 61 % set tcl_interactive 0
0
(chris) 62 % pu
invalid command name "pu"


Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/2/22 5:48 PM, saitology9@gmail.com wrote:

However, it may turn into a real bug as well if you code mostly in an interactive environment and save the final code to a file.  When you run
it later as a stand-alone, you may get errors complaining about unknown commands if you have relied on shortened command names.  And if you try
to debug it in an interactive shell by loading the same file, the error
may mysteriously vanish. All because of the interactive command
completion feature.  It could be quite frustrating the first time you
come across it.

Here is a quick demo:

This works and will print out the history:

% puts [h]


This fails:

% proc buggy {} {
puts [h]
}

% buggy

invalid command name "h"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/2/22 12:49 PM, pd wrote:

El sábado, 2 de abril de 2022 a las 18:45:49 UTC+2, Harald Oehlmann escribió:

there's no h command or proc, but there's a history command and it seems to produce the same results:

Yes, bug or feature. If it is unique, you can shortcut any command. If
you define a second command starting with h, it will not work any more.

thanks for clarifying , I clearly would put it into the bug bag ;-)

Hello,

As stated already in this thread, this is not a bug but a feature of interactive shells meant to give the user the power of command
completion (in the same vein as bash). It used to be available only in
wish shells if I am not mistaken but apparently current tclsh shells do
it too.

However, it may turn into a real bug as well if you code mostly in an interactive environment and save the final code to a file. When you run
it later as a stand-alone, you may get errors complaining about unknown commands if you have relied on shortened command names. And if you try
to debug it in an interactive shell by loading the same file, the error
may mysteriously vanish. All because of the interactive command
completion feature. It could be quite frustrating the first time you
come across it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03.04.22 um 07:46 schrieb Rich:

pd <eukelade@gmail.com> wrote:

I'm using magicsplat in windows which provide a tcl shell as an
executable program tclsh.exe.

when using it I accidentally typed h in the shell and get what seems
to be a command history list.

Being corious tried to see what command or proc it actually is:

What do you get if you type "h" in the windows command shell (i.e., not inside the tclsh)?

Tcl's 'shell' includes a wee bit of extra 'magic code' that, when a tcl command named X is not found, the shell attempts to exec a command from
the OS of the same name, and only if that exec fails, does the shell
report 'command not found'.

I suspect you'll find that "h" in the windows command shell gives you
the same output you saw in the tclsh shell.

This would also explain why you could not introspect the 'h' command
from tcl. It was not a tcl command/alias/proc/etc.

No, that idea is wrong. As explained in the rest of the thread, "h"
invokes the Tcl command "history" as it allows any unique abbreviation
if you set interactive mode on.

I think this is implemented in the default "unknown" command, upon quick inspection I could not find it, however.

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

pd <eukelade@gmail.com> wrote:

I'm using magicsplat in windows which provide a tcl shell as an
executable program tclsh.exe.

when using it I accidentally typed h in the shell and get what seems
to be a command history list.

Being corious tried to see what command or proc it actually is:

What do you get if you type "h" in the windows command shell (i.e., not
inside the tclsh)?

Tcl's 'shell' includes a wee bit of extra 'magic code' that, when a tcl
command named X is not found, the shell attempts to exec a command from
the OS of the same name, and only if that exec fails, does the shell
report 'command not found'.

I suspect you'll find that "h" in the windows command shell gives you
the same output you saw in the tclsh shell.

This would also explain why you could not introspect the 'h' command
from tcl. It was not a tcl command/alias/proc/etc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El sábado, 2 de abril de 2022 a las 23:48:25 UTC+2, saito escribió:

Yes, bug or feature. If it is unique, you can shortcut any command. If
you define a second command starting with h, it will not work any more. >>

thanks for clarifying , I clearly would put it into the bug bag ;-)

As stated already in this thread, this is not a bug but a feature of interactive shells meant to give the user the power of command
completion (in the same vein as bash). It used to be available only in
wish shells if I am not mistaken but apparently current tclsh shells do
it too.

this behaviour is not at all the same as bash , bash does autocompletion based in autoexpand (with tab key) to the exact name. It would be nice tclsh doing the same with a key (tab or other) or automatically assuming the command when using a unique
prefix, but once determining the command it should be done a complete expansion substituting the prefix command for the full command name. Do it always or never. What is a bug is sometimes you accept a comand prefix ("exapanded") and sometimes you don'
t (as you proved in your next email).

If a command prefix works on toplevel it should work inside a proc, and if it works in a repl it should work in a script or an eval command.

I prefer not implenting command expansion at all, I'm comfortable having to write the full command name and getting an error if I don't write the exact name.

But if it's wanted to have command expansion maybe would be better to do command expansion as another rule in dodecalogue or modify the command substitution rule

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/3/22 8:51 AM, pd wrote:

El sábado, 2 de abril de 2022 a las 23:48:25 UTC+2, saito escribió:

this behaviour is not at all the same as bash , bash does autocompletion based in autoexpand (with tab key) to the exact name. It would be nice tclsh doing the same with a key (tab or other) or automatically assuming the command when using a unique

prefix, but once determining the command it should be done a complete expansion substituting the prefix command for the full command name. Do it always or never. What is a bug is sometimes you accept a comand prefix ("exapanded") and sometimes you don'
t (as you proved in your next email).



Hello,

It works the same way in both bash and wish: if you don't use a tab,
"chm" will give you an error in bash. If you hit the tab key, it will
expand it to "chmod". In wish, if you hit the tab key, it will expand
"h" to "history". Both environments will print a list of options
matching the command prefix you have typed so far.

The only difference I see is that bash will error out if a command
prefix is not expanded; but wish will run it if there is only one
matching target. Otherwise, you get the exact same behavior.

As to why command prefixing/completion does not work when embedded in a
deeper level, there is no interactivity there for the user to provide
feedback and select an option.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El domingo, 3 de abril de 2022 a las 20:00:42 UTC+2, saito...@gmail.com escribió:

It works the same way in both bash and wish: if you don't use a tab,
"chm" will give you an error in bash. If you hit the tab key, it will
expand it to "chmod". In wish, if you hit the tab key, it will expand
"h" to "history". Both environments will print a list of options
matching the command prefix you have typed so far.

The only difference I see is that bash will error out if a command
prefix is not expanded; but wish will run it if there is only one
matching target. Otherwise, you get the exact same behavior.

in wish that's true, but in tclsh when you hit tab key you get a tab in the console (a bunch of spaces) and there's no completion. At least in magicsplat's tclsh

As to why command prefixing/completion does not work when embedded in a deeper level, there is no interactivity there for the user to provide feedback and select an option.

but the tcl_interactive applies to all session or repl, or that should be

% set tcl_interactive
1
% h
1 set tcl_intereractive
2 set tcl_interactive
3 h
% proc p {} { upvar tcl_interactive var; puts "$var"; h }
% p
1
invalid command name "h"

if you set tcl_interactive to 1 that should be applicable to everything you do in the interactive shell, also procs, on the other way there's a high risk to introduce errors that could be hard to identify.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/4/22 5:17 AM, pd wrote:

but the tcl_interactive applies to all session or repl, or that should be

Hello,

While editing your proc, regardless of the nesting level, the tab
completion works as you expect it. You are interacting with the shell
and you have the opportunity to type in the tab. So the shell can
respond back with some useful feedback as you type and it can expand the
"h" to "history" or whatever.

% set tcl_interactive
1
% h
1 set tcl_intereractive
2 set tcl_interactive
3 h
% proc p {} { upvar tcl_interactive var; puts "$var"; h }
% p
1
invalid command name "h"

Because you are no longer in interactive mode when a proc is running. So
the command is executed directly by the tcl interpreter and it finds
that there is no command named "h".

if you set tcl_interactive to 1 that should be applicable to everything you do in the interactive shell, also procs, on the other way there's a high risk to introduce errors that could be hard to identify.

Not really hard to identify given the error message since you can easily
do a simple search by proc name. However, as I mentioned in my first
message in this thread,

It could be quite frustrating the first time you come across it.

By the way, you seem to be using tclsh. I'd suggest using wish or tkcon
for a much better shell experience.

And that is all of my $0.02.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/2/2022 8:59 AM, pd wrote:

% info [info type $s] $s

my point with this email is not only suggesting possible improvements in handling introspection (or showing my lack of knowledge) but pointing out is should be easier for a user to find about defined symbols in tcl

Here's some fun stuff you can do in tcl:

proc infosym {item args} {
# puts "item= |$item| "

if { $args eq "-class" } {
set classes {alnum alpha ascii boolean control digit
double entier false graph integer
list lower print punct space true
upper wideinteger wordchar xdigit}

foreach class $classes {
if { [string is $class -strict $item]} {
puts "[list $item] is a string of class $class"
}
}
} else {
set exists 0
catch {set exists [uplevel "info exists $item"]}
if { $exists } {
puts "$item exists"
}

set exists 0
catch {set exists [uplevel "array exists $item"]}
if { $exists } {
puts "$item is an array"
}

if { [info global $item] eq $item} {
puts "$item is a global variable"
}

if { [info procs $item] eq $item} {
puts "$item is a procedure"
} elseif { [info commands $item] eq $item} {
puts "$item is a command"
}

if { [info functions $item] eq $item} {
puts "$item is a math function"
}
}

}



% infosym env
env exists
env is an array
env is a global variable

% infosym env(PATH)
env(PATH) exists

% infosym xyz

% infosym xyz -class
xyz is a string of class alnum
xyz is a string of class alpha
xyz is a string of class ascii
xyz is a string of class graph
xyz is a string of class list
xyz is a string of class lower
xyz is a string of class print
xyz is a string of class wordchar

% infosym 0 -class
0 is a string of class alnum
0 is a string of class ascii
0 is a string of class boolean
0 is a string of class digit
0 is a string of class double
0 is a string of class entier
0 is a string of class false
0 is a string of class graph
0 is a string of class integer
0 is a string of class list
0 is a string of class print
0 is a string of class wideinteger
0 is a string of class wordchar
0 is a string of class xdigit

% infosym \" -class
{"} is a string of class ascii
{"} is a string of class graph
{"} is a string of class print
{"} is a string of class punct

% infosym foo
% set foo bar
bar

% infosym foo
foo exists
foo is a global variable

% proc foo {} {}

% infosym foo
foo exists
foo is a global variable
foo is a procedure

% infosym {1 2 3} -class
{1 2 3} is a string of class ascii
{1 2 3} is a string of class list
{1 2 3} is a string of class print

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Christian Gollwitzer <auriocus@gmx.de> wrote:

Am 03.04.22 um 07:46 schrieb Rich:

What do you get if you type "h" in the windows command shell (i.e., not
inside the tclsh)?

No, that idea is wrong. As explained in the rest of the thread, "h"
invokes the Tcl command "history" as it allows any unique abbreviation
if you set interactive mode on.

I wouldn't have called it "wrong", even if in the particular case
it likely didn't apply.

Both,
- trying to find shell command of that name
- seeing if it is a unique abbrev for a tcl command(or proc)
are in the repertoire of tcl's unknown proc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)