Is it safe to use ALIASES in scripts?

In our newsgroup (Microsoft.Public.Windows.Server.Scripting) , Mark Ayers asked the question:> Shouldn’t best practice for scripts be full command name?

The answer is YES, NO, and MAYBE.

YES – Full names provide the most readable experience for scripts. This is very important. People often throw the rock at Perl saying that it is a “write-only language” meaning that after you write a script, you can’t read it or understand what it does. We believe that Monad scripts will be widely shared and will be used in environments where it is really important to know exactly what is going on. As such, script readability has always been a strong focus for us. This is one of the key reasons why we support both a pithy and verbose invocation model (pithy for high-speed interactive use, verbose for scripting).

NO – Not all aliases are the same. There are a special class of aliases that are READONLY and ALLSCOPE. You can find these with the following command:

In previous drops, these aliases where CONSTANT which meant that users could not delete or remove them. They exist because they are very predictable and pithy short hands for the long names. We made them constant so that you could feel safe using them in any script and that you could share that script with other people knowing that you were guaranteed that those aliases would exist everywhere and mean the same thing so your scripts would not break. The community provided strong feedback that MSFT should not ship any CONSTANT aliases so we made them READONLY and ALLSCOPE. This means that you can remove them (using the -FORCE flag) and create your own definitions but it is strongly discouraged.

So in the end, you are pretty safe using the aliases that are READONLY and CONSTANT. You might argue that this is less safe then using the full command name. This would not be correct. Token resolution works by first expanding aliases then binding to a function, then a cmdlet, lastly as an external executable. When you type “Get-Process” – it could have been aliased to any other command or there could be a function with this name. So in the end, the READONLY ALLSCOPE aliases are just about as safe as the full command names.

MAYBE. The other thing you can do in your script is to set up the aliases you’ll use yourself. Aliases are scoped so this is generally a safe operation and will not contaminate the users environment. Let me demonstrate using a one of my favorite functions that I define in my profile file, Start-NewScope and its alias sans

Excellent discussion. It sheds light on many useful elements including teh question of how to catch the script "exit" for cleanup tasks.

It would be useful to have a "built-in" export converter for scripts that would convert all aliases for portability. This would allow for efficient typing without the need to find and converrt temporary or non-portable aliases. It would also accomplish eliminating the worry over aliases.

We’ve talked about this from about day 2 of the project. It has never risen to the top of the to-do list for V1. I’m not sure whether it will for V2 or not – it all depends on customer feedback – e.g. is this a REAL problem or a POTENTIAL problem. That said, what is more likely to occur is that we’ve been discussing the benefits of publishing our parse tree (the results of our parser) using public classes or exporting it to XML. This would enable a whole range of community supplied utilities functions like the one mentioned here.

As always, there is no promise that this will be coming but I thought I would share the current state-of-thought.

>we’ve been discussing the benefits of publishing our parse tree (the results of our parser) using public classes or exporting it to XML

That would work.

It’s probably not a REAL problem and with fore-knowledge it shouldn’t be a POTENTIAL problem. Anyway, we can build an external script parser that will work for now as everything needed is already in MSH.