Aliases global vs. local

[vefatica]

There's still something I don't quite get.

There's a global alias list, used by concurrent sessions and with SHRALIAS possibly future sessions as well. Then I say "ALIAS /L". Now the session at hand uses a new alias list (right?) and that new list is populated with what's in the global list (right? ... this may not be what's wanted). Then I make/change some aliases (supposedly in the local list) and later "ALIAS /G". Why is the local list propagated to the global list? Does anyone want that to happen? It seems counter-productive to me.

For me, the global list is something that endures (for years, really) and while I might want to use special aliases for a while I don't want tha global list messed with. Yes, I know there's SETLOCAL but the need to use both SETLOCAL and ALIAS /L (/G) together to prevent aliases changing in concurrent and future sessions is cumbersome and confusing.

I'd be happy with two completely independent lists, a local one and a global one. Global-to-local propagation is OK but I wouldn't need it. Local-to-global propagation (IMHO) should be a no-no. I'd like to be able to (in a batch file)

alias /l

Now i can do batch specific stuff, even load an alias file; later

alias /g

Go back to using the global aliases (as they were).

In a nutshell: Is the local-to-global propagation of aliases necessary or desirable?

 

[Stefano Piccardi]

In a nutshell: Is the local-to-global propagation of aliases necessary or desirable?

Unnecessary and undesirable, if you ask me. Utterly confusing, too.

Btw, to counter global-to-local propagation in a script, this should suffice
setlocal
unalias *
alias /L

without alias /L the script will see any global aliases that another concurrent session creates anew. ?right?

 

[vefatica]

On Thu, 22 Sep 2011 12:30:36 -0400, Stefano Piccardi <>
wrote:

|Btw, to counter global-to-local propagation in a script, this should suffice
|setlocal
|unalias *
|alias /L

No, "SETLOCAL & UNALIAS *" wipes out aliases in concurrent and future sessions.

 

[Stefano Piccardi]

|Btw, to counter global-to-local propagation in a script, this should suffice
|setlocal
|unalias *
|alias /L

No, "SETLOCAL & UNALIAS *" wipes out aliases in concurrent and future sessions.

I took my example from the SETLOCAL help topic, which I interpret as saying that SETLOCAL & UNALIAS * only affects the currently running script, and ENDLOCAL or script end restores the alias list that was in effect before SETLOCAL.

 

[vefatica]

On Thu, 22 Sep 2011 12:56:23 -0400, Stefano Piccardi <>
wrote:

|---Quote (Originally by vefatica)---
||Btw, to counter global-to-local propagation in a script, this should suffice
||setlocal
||unalias *
||alias /L
|
|No, "SETLOCAL & UNALIAS *" wipes out aliases in concurrent and future sessions.
|---End Quote---
|I took my example from the SETLOCAL help topic, which I interpret as saying that SETLOCAL & UNALIAS * only affects the currently running script, and ENDLOCAL or script end restores the alias list that was in effect before SETLOCAL.

That's one of the confusing and unfortunate points. If that alias list is the
global one, the effects are global (until you ENDLOCAL).

 

[Steve Fabian]

From: vefatica
| For me, the global list is something that endures (for years, really)
| and while I might want to use special aliases for a while I don't
| want tha global list messed with. Yes, I know there's SETLOCAL but
| the need to use both SETLOCAL and ALIAS /L (/G) together to prevent
| aliases changing in concurrent and future sessions is cumbersome and
| confusing.
|
| I'd be happy with two completely independent lists, a local one and a
| global one. Global-to-local propagation is OK but I wouldn't need it.
| Local-to-global propagation (IMHO) should be a no-no. I'd like to be
| able to (in a batch file)
|
| alias /l
|
| Now i can do batch specific stuff, even load an alias file; later
|
| alias /g
|
| Go back to using the global aliases (as they were).

This is exactly what I proposed years ago. IMHO the two lists should operate in the same manner as variables defined between matching braces and outside them in code written in C. When a string is parsed to check whether or not it is an alias, the local list is checked first. If found, that's used. If not found, the global list is searched. The current LocalAliases directive, as well as the /L and /G options of the ALIAS command would control the default for the ALIAS and UNALIAS commands when used without an alias definition (just alias name for UNALIAS), or explicitly control which table to modify / examine when an alias name or definition is present.

SETLOCAL's effect should be that changes to the global table are not propagated to other sessions - in other words, the similar to ALIAS /L.

| In a nutshell: Is the local-to-global propagation of aliases
| necessary or desirable?

Neither. The intuitive use of the local table is exactly to prevent propagation.
--
Steve

 

[David Marcus]

When a string is parsed to check whether or not it is an alias, the local list is checked first. If found, that's used. If not found, the global list is searched.

I don't think we want that. We want to be able to clear the alias list (and so know there are no aliases) without messing up other sessions.

 

[Steve Fabian]

From: David Marcus
| Originally Posted by Steve Fabian
|| When a string is parsed to check whether or not it is an alias, the
|| local list is checked first. If found, that's used. If not found, the
|| global list is searched.
|
| I don't think we want that. We want to be able to clear the alias
| list (and so know there are no aliases) without messing up other
| sessions.

That's what SETLOCAL/ENDLOCAL was originally requested to do.
--
Steve

 

[David Marcus]

That's what SETLOCAL/ENDLOCAL was originally requested to do.

If so, then why doesn't it do that?

 

[Steve Fabian]

From: David Marcus
| Originally Posted by Steve Fabian
|| That's what SETLOCAL/ENDLOCAL was originally requested to do.
|
| If so, then why doesn't it do that?

I don't know, but it was a design decision over 18 years ago, when implementation was much different from today, and it may have related to memory usage or execution time. The command was implemented in 4DOS as well as 4NT...
--
Steve

 

[samintz]

Just to toss my two cents in here, I personally
never use global aliases. My alias list is pretty fixed and changes
rarely. I load it in TCSTART using ALIAS /R.

I have not (to best of my recollection)
ever needed to propagate an alias that was not part of my loaded alias
file. So I avoid the whole global issue altogether.

-Scott

Steve Fabian <> wrote on
09/22/2011 01:40:40 PM:

> | In a nutshell: Is the local-to-global propagation of aliases
> | necessary or desirable?
>
> Neither. The intuitive use of the local table is exactly to prevent

> propagation.
> --
> Steve
>
>

 

[David Marcus]

I used to use global aliases, since I generally want to use the same set in all sessions. But, problems with btm files breaking or changing the global aliases made me switch to local aliases. I don't think I'm having any problems now. But, global aliases make more sense to me--if btm files could easily work with a local set.

 

[Jay Sage]

It seems to me that the problem with

setlocal
unalias *
alias /L

is that the order is wrong. The UNALIAS command clears the global
aliases. One should do the following:

setlocal
alias /L
unalias *

That way, one will be clearing the local alias list. Later, one can
issue the commands:

endlocal
alias /G

The ENDLOCAL will restore the aliases to what they were before the
SETLOCAL, and ALIAS /G will copy them to the global buffer.

That being said, I agree entirely with Vince that the command ALIAS /G
should NOT copy the current local alias definitions to the global alias
buffer but should simply switch the current session back to using the
then-existing global definitions (which may have been changed in other
TCC sessions using global aliases). Otherwise, any modifications to the
global definitions that were made during the time while the batch file
was running will be lost.

-- Jay