none
PowerShell documentation: Where is it? RRS feed

  • General discussion

  • I have been looking at PowerShell now for a few months and looks like it could be useful. I have tried to find the documentation but it seem like Microsoft have stopped documenting stuff in a good, useful and productive way.

    The documentation provided by the Get-Help CmdLet is kind of equivalent to the intellisense help you get in Visual Studio and nowhere close to a classic reference documentation. Often datatypes are missing or it is only specified as System.Object which is of no or very little help. Many things I can't find at at all, like for example the reference documentation for a calculated column (@{name="Heading"; expression={$_.StringValue -as [int]}}).

    Also I can't find any real in depth documentation on the runtime environment of PowerShell...what makes it "tick"?

    I am looking for the following documentation

    1. The PowerShell Language Specification 
      The documentation that in detail specifies all aspects of the PowerShell programming language, including things like lexical structure, types, variables, conversions, expressions, operators, parameters. It should be the equivalent C# Language Specification 5.0 found here.

    2. The PowerShell operation and Runtime environment documentation
      This would be the documentation that describes how PowerShell integrates with Windows. Which paths are used, what are the prerequisites, relevant and used Registry Keys, security and how it works (integrate) both in an AD environment as well as in a workgroup, environment variables, version management, how to do a reset of PowerShell as well as a COMPLETE and manual uninstall, relevant events and logs to monitor for PowerShell related problems, best practice guides for simplicity and robustness for PowerShell in a domain as well as for a workgroup and and a single computer,  any differences in functionality based on the OS and so on.  In short, everything that you need to know to fully understand how PowerShell is intended to be used and all it's dependencies and prerequisites, so you don't run into problems because you are using it the wrong way and does something that might lead to problems in future versions.

    3. PowerShell Architecture and Strategy Guide
      The documentation that describes, elaborate and discuss the use of PowerShell in different situations and circumstances. Documentation that discuss when PowerShell is appropriate and when something else is probably a better tool/technology for the task at hand. Documentation that problematize different solutions to the same problem and gives pros and cons for the different solutions.

    4. Powershell Reference Documentation
      A classic reference documentation for PowerShell for everything that is part of the OS. Documentation that include exact syntax, data types, parameters, return values (with type) and any exceptions that might occur and where there are clickable and working links to all relevant information all the way down to the The PowerShell Language Specification (1), relevant classes in the .NET Framework, PowerShell Programmer's User Guide (5) and all other relevant sources.

    5. PowerShell Programmer's User Guide
      Documentation that describe the usage of CmdLet:s and other PowerShell functions, statements,  and features. With fully working examples where all aspects of functionality is exemplified and not only the simple and obvious use cases and where the context of the examples are relevant (any variables used in the example should have their value assigned in the example).

    PS A blog is not documentation, it is the subjective view of a single individual


    Friday, January 1, 2016 9:24 AM

All replies

  • Start here: https://technet.microsoft.com/en-us/scriptcenter/dd793612.aspx

    Nearly all ocumentation is online in either mteh Net docs on MSDN or in the technet library.\

    User Guide: https://technet.microsoft.com/en-us/library/cc196356.aspx

    The same is true for the remainder. Just use your search engine to find them.

    There is no "Programmers Reference" as this is a scripting system aimed and Admins and technicians.  There are many reference materials for the subsystems accessed by the PowerShell system.

    Example:

    WMI is a WIndows subsystem.  It is documented in the Wjndows technical documentation here: https://msdn.microsoft.com/en-us/library/windows/desktop/ee309379(v=vs.85).aspx

    The SQLServer  and Exchange componenets wil be documented with Exchange and  SQLServer..

    The Net Framework classes are documented in the MSDN Library: https://msdn.microsoft.com/en-us/library/gg145045(v=vs.110).aspx

    PowerShell is not a stand alone product and is distributed as the main tool for WMF. 

    PowerShell is 10 years old. Its documentation is extensive and targeted to the end use.

    PowerShell is not a development tool.  It is a scripting environment that is intended to be used for al management functions in Windows.

    PowerShell can be extended by developers or hosted in a custom product. THe reference material for this is in the "Platform SDK": https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx


    \_(ツ)_/

    Friday, January 1, 2016 10:43 AM
  • I hope you are not referring to the "Owner's manual", since it is kind of useless.

    Are you joking about using a search engine to find the documentation? Are you really saying that there are no real documentation for PowerShell?  Even VBA, VBScript and JScript have better documentation than PowerShell.

    But if it is as bad as you suggest I guess we will stick to our VBScripts.

    Friday, January 1, 2016 11:04 AM
  • None of the rest of us are having any issues with the documentation.  It is complex and very technical and requires careful reading. It is not a programmers handbook or a learn basic in an afternoon.  It requires good technical background in Windows and technology.  If this is unacceptable then you will just have to fo without PowerShell although, from what I understand, it will be a requirement for all future products.


    \_(ツ)_/

    Friday, January 1, 2016 11:15 AM
  • Reading what?  there are only very basic stuff documented.  Take, for example, a calculated property @{name=<PropertyName>; expression=<PowerShellExpression>}, where do you find the official Microsoft  documentation for this?

    Or a very simple and basic CmdLet like Get-Date. The first thing you notice is basic information like which module it is in, and which assembly/dll/"package" contain the CmdLet is missing.  When you continue to read the documentation you will find out that the most important and essential information is spread out all over the page. Instead of giving me a condensed "active" and clickable summary at the top of the page with parameters, data types and return value and it's datatype, I get 25% of the page telling me that it is about Get-Date (twice), the PowerShell version, page update time and short description telling me that this CmdLet will give me the current date and time, and it puts all of this in a single narrow column, making 80% of these top 25% of the visible page on my 24" screen completely blank.

    The syntax section contains some kind of semi reference documentation for the CmdLet, but leaves out important stuff like return value and fully qualified data types for parameters.

    To find out the return value and its data type you have to manually scroll down and find the "Outputs" section, where you will learn that you can get both a System.String and a System.DateTime depending on the use of -Format/-UFormat parameter.

    Nowhere does it mention what Time Zone is the returned Date in? Does it matter which user runs the CmdLet? Does it matter which OS it runs on? How would I make sure that dates are handled the same way in a distributed, multi cultural, multi time zone environment with a mix of server OS and client OS where different users executes Get-Date in all kinds of uncontrolled situations. How do you handle one script that is to run on machines with different culture for "system local"? Or is it a requirement for powershell that all machines have the same culture for the system local account?  If so where can I read about this? If not, then how do I go about specifying a date that I can be sure of is interpreted the same way no matter where it is run? Can I change the culture for the current thread to get the correct parsing (like I would do if I used System.DateTime directly) or do i really need to change the system local profile, as the -Date parameter indicates, to ensure correct parsing of date?

    And when you continue to look at the "Documentation" for Get-Dateit tells you that there are two different ways of using the CmdLet (two parameter sets), but there is no information on the difference of the two parameter sets. To get some kind of clue what the different parameter sets are about and why they are called "net" and "UFormat" you first need to thoroughly examine the parameters for each set (because they are basically identical). One has -Format the other -UFormat. Then you need to manually scroll and find the the detailed description for -Format and -UFormat to figure out that there are two! parameters doing exactly the same thing, to format the output. In the "documentation" for -Format you get an unclickable! URL to the MSDN documentation for "DateTimeFormatInfo Class". How the hek can you put an URL in a web page and not make it clickable? You also are made aware of that when you use -Format you "only the properties of the DateTime object that it needs to display the date in the format that you specify. As a result, some of the properties and methods of DateTime objects might not be available." This is clearly written by someone who has no clue what he is talking about, first of all System.DateTime is a .NET struct and you cannot have only some parts of it, secondly the whole point of classes and objects in OOP is to encapsulate data and put an abstraction layer between the user of a class/object and its inner working, and finally, the reason you can't use any of the properties or methods of System.DateTime on the result when you use -Format is because Get-Date returns a string when this parameter is used!!

    Nowhere in the documentation of Get-Date is any information on what happens if you try to parse an invalid date (2016-02-31), of if the string to parse is null or empty?  Or what happens if there is an error in the format-string for the -Format parameter?


    Get-Date was just an example of a very basic CmdLet, don't start to answer the questions and stuff I pointed out there, because you have the same problem with just about any CmdLet you look at.

    Anything and everything that is undocumented can be changed in the next version of PowerShell, so in order to use something that seems so simple like Get-Date will force you to write a lot of plumbing code just to make sure your script will work a month from now when Microsoft has released new updates.

    Testing what happens is not enough, perhaps it uses the culture of the current thread in the version I have on my machine, or that it uses the timezone of the current user,  but Microsoft can very well change their implementation to really use the configured culture for system local, which is what the documentation for the -Date parameter say.

    If you write a small script that you are going to run on 10 computers in your local office this is not a problem, but when you work as a consultant and you are hired to architecture and develop an infrastructure for running arbitrary script on tens of thousands of computers and servers in a huge global company, it is not acceptable that everything breaks down just because you have to guess how stuff work, and a customer won't pay for the time it will take to test and investigate exactly how each and every CmdLet work and behave, especially when they have heard the sales pitch from Microsoft and seen demos where they do stuff in l5 minutes with just a few lines of code. And to tell a customer that there is no documentation because PowerShell "is a scripting system aimed and [sic] Admins and technicians" is not really the way to go.

    I am starting to feel that PowerShell is something Microsoft developed to solve their own internal needs, perhaps to manage Azure, and made it public without really committing to it, and only provide the most basic documentation for the public, because if they were serious about it, there should at least be a reference documentation worth the name....it reminds me a little bit of BITS, which also lacked any real serious documentation for many, many years, but which has gotten a bit better now lately.

    //---

    PS I have worked with just about all microsoft technologies since the early 90-ies, including low level win32 programming in C, so I know what happens when people don't read the documentation and then tries to port their win16 code to win32. Been there, done that, not interested in doing it again.

    Friday, January 1, 2016 2:15 PM
  • As I have noted, you have to learn how to use "help".  Calculated properties are defined in the help topics and are pretty easy to understand.

    "Calculated properties" are not part of PowerShell spec but are defined by the CmdLet.  They are specific to and limited the CmdLet that defines them.  Below aare two examples.  YU can design you own CmdLet and define you own version of a "calculated property".

    A calculated property as used in the Select-Object command is a hash of a name and a scriptblock.  It is that simple.

    @{Name='somename';Expression={... some code ...}}

    help select-Object -full

    Which can also be stated this way.

    dir | select @{n='MyFunnyName';e={$_.Name+'__Wabbits'}} -first 5

    or this:

    dir | select @{l='MyFunnyName';e={$_.Name+'__Wabbits'}} -first 5

    or we can look at the help for Format-Table and discover this: HELP Format-Table -full which shows us the this CmdLet defines the "Properies" parameter as taking a totally different type of "hash" definition.  If yu try to use this on any other CmdLet it will fail.

    dir | format-table @{L='MyFunnyName';e={$_.Name+'__Wabbits'};width=10}

    To get a better understanding of how t use the many help options just type -

    help help -full

    or

    help  help -online

    or

    help help -show

    By the time you actually learn how to use PowerShell most of yur questions will either be answered or you will realize that they do not apply to the PowerShell Scripting System of WMF.

    "Old thinking always makes new technologies appear to be either difficult or broken." - Windsor Spence III


    \_(ツ)_/

    Friday, January 1, 2016 2:52 PM
  • Nowhere does it mention what Time Zone is the returned Date in?

    Why would you say that.  Once you actually complete a course in basic PowerShell it will become clear that culture is an intimate part of the Net Framework.  PowerShell respects and adjust for culture depending on how you choose to option your session.

    Type the following:

    Get-Culture

    help culture

    You will see all of the components needed to manage culture.


    \_(ツ)_/

    Friday, January 1, 2016 2:59 PM
  • First, .NET, by default, uses the culture of the current thread. in Get-Date is say it uses "system local".

    second, the time zone has nothing to do with culture, the time can be in UTC or it can be in a local timezone, which mean you will have to manually check the DateTime.Kind for every date to figure out if it is UTC or local time. When Get-Date don't define which is returned you can't go around making assumptions on what you happen to get on your machine.  There is not even a mention of the problems around dates, cultures, time zones and how to handle dates in a in a complex environment.

    Friday, January 1, 2016 3:16 PM
  • To get some kind of clue what the different parameter sets are about and why they are called "net" and "UFormat" you first need to thoroughly examine the parameters for each set (because they are basically identical). One has -Format the other -UFormat. Then you need to manually scroll and find the the detailed description for -Format and -UFormat

    Here again this is because you have not taken the time to learn how to use help.

    help get-date -parameter uformat
    or
    help get-date -parameter *format

    I have taught many to write 'C/C++/C#' code in legacy OSs, Unix flavors and Windows.  Some come to the table like you looking to learn from a spec.  I tell them that they need to first learn the language and its basic usage before the technical spec is useful.  First learn to use the builtin documentation then,, in modern system, learn the online components. 

    The issue with PowerShell is that it is not a developers language.  It I not designed or deployed as a developers language or system.  It is a scripting environment designed to primarily assist Admins and techs in working to configure and maintain large systems. It is currently deployed aggressively in very large corporations and is the primary tool used to manage Azure, ExchangeOnline, SharePoint and other large deployments of MS and other subsystems.  Companies like IBM and Oracle are adding more support for Net and PowerShell/WMF.

    I have been using PowerShell for ten years now and have not seen a need to complain.  Every product that I have ever worked with has had its issues.  I built systems with Orcle on Banyan Vines and on Sun/HP/DEC Unix before Windows was conceived in some cases.  Oracle has and is horrible at concise, accurate and current documentation. This answers are always there but new features are always hard to find.  This is the nature of the computer industry. 

    It may be interesting to note that I get paid as a consultant because I can find the answers to these issues wher admins, techs and developers tend to be too narrowly focused to get the information they need.  Their time is generally more effectively spent writing code and let the enginers find the correct set of rules.

    A consultant researches given issues and environments and develops a set of solutions that can be deployed.  The toolbox and resources are seldom, if ever, perfect.


    \_(ツ)_/

    Friday, January 1, 2016 3:19 PM
  • The PowerShell language specification is, indeed, available via search:

    http://www.google.com/search?&q=powershell+language+specification

    This is the first search result when I run this query.

    As far as the other details: I don't know whether Microsoft has produced the exact documents you are looking for in the exact form you're looking for. As Raymond Chen has colorfully noted, wishful thinking does not cause features to spring into existence. (In this case, the "feature" in question is a laundry list of the exact documentation you're looking for.)


    -- Bill Stewart [Bill_Stewart]

    Friday, January 1, 2016 3:27 PM
    Moderator
  • If you build on a behaviour that is undocumented, it's like asking for problem.   As long as I can't even find the PowerShell formal language specification that clearly outlines the language, it's lexical structure, how it handles types and casting, how it prioritize operations, what evaluated and in which order and so on I will keep being very skeptical...
    Friday, January 1, 2016 3:28 PM
  • First, .NET, by default, uses the culture of the current thread. in Get-Date is say it uses "system local".

    second, the time zone has nothing to do with culture, the time can be in UTC or it can be in a local timezone, which mean you will have to manually check the DateTime.Kind for every date to figure out if it is UTC or local time. When Get-Date don't define which is returned you can't go around making assumptions on what you happen to get on your machine.  There is not even a mention of the problems around dates, cultures, time zones and how to handle dates in a in a complex environment.

    You miss the point. It is there and documented. If you had a specific issue then there might be an answer. Your statements are in the negative and in general so it is not possible to understand what you need to do or what it is that cannot be done with Net.

    Also note the Net is Windows and PowerShell uses Net.

    In all of Windows the date is given as local.  In Net it is stored as a system datetime structure which can be read out in any timezone or as UTC.  The format will be according to culture and the timezone according to locale.  Why is this an issue?

    Get-Culture

    (get-date).ToUniversalTime()

    gwmi Win32_TimeZone

    But none of this is PowerShell. These are just utility commands that we can use in PowerShell  How to use them is about the user/tech.  You must know things outside ot PowerShell to understand how to use these tools.  None of this is defined in PowerShell.  All of this is defined in the system and is in some way tied to the larger universe.


    \_(ツ)_/


    • Edited by jrv Friday, January 1, 2016 3:29 PM
    Friday, January 1, 2016 3:29 PM
  •  There is not even a mention of the problems around dates, cultures, time zones and how to handle dates in a in a complex environment.

    Here, again, is where many non-systems techs get lost.  PowerShell is not responsible for any of this.  PowerShell is just a tool like a 'C' compiler.  It just does what you tell it. 'C' knows nothing about time or culture.  A specific implementation of 'C" will have a library of time and culture functions which are specific to a system. Outside of the default time calls any adjustments of culture nd locale will be system dependent (although this is slowly being standardized by the DMTF)

    PowerShell, like C, is designed to work across platforms. It now runs on *nix flavors and other systems and should eventually be everywhere as it is an open spec (the language design can be used with no licensing).

    How to handle dates is an issue that I have heard from o many developers over the years.  THis is nearly always because of a lack of understanding of how thelocal system manges dates and what calls or libraries are available to work with time.

    Windows NT has always had the same underlying datetime structure since the first beta of the Win32 API. It I snow wrapped in Net and most functionality is delivered as paer of the System.DateTime  structure.

    Documented here: https://msdn.microsoft.com/en-us/library/system.datetime%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

    Get-Date is just a convenience wrapper around this object.


    \_(ツ)_/

    Friday, January 1, 2016 3:41 PM
  • Thanx, it's for PowerShell 3.0 and the latest version is 5.0. But it is better than nothing....but the fact that it is for version 3.0 and that is no one available for v4 and v5 kind of strengthen my belief that this is something that is not a very High Priority thing for Microsoft. Because they obviously have them but didn't bother publish them...and then the fact that the only way of finding them is to use google....especially when you do a search for pages containing a link to the PowerShell language specification download page and no pages at microsoft.com links there....
    Friday, January 1, 2016 3:44 PM
  • If you build on a behaviour that is undocumented, it's like asking for problem.   As long as I can't even find the PowerShell formal language specification that clearly outlines the language, it's lexical structure, how it handles types and casting, how it prioritize operations, what evaluated and in which order and so on I will keep being very skeptical...

    The PowerShell language specification is available.  Why do you keep acting like it isn't?


    \_(ツ)_/

    Friday, January 1, 2016 3:47 PM
  • How about enrolling in some PowerShell courses?

    Basics + Advanced

    5.0 will be released with Windows Server 2016 and then a new course will be published. It has always been like that.

    Friday, January 1, 2016 3:54 PM
  • for example, no mention of what exceptions could occur.

    And the fact that it does not specify if it returns a UTC date or a local date forces you to check the return value after each call.

    On the other hand, in .NET youy have DateTime.Now and Date.Time.UtcNow to get exactly what you want and you don't have to check what you got. It would be so easy for GetDate to just specify it always return UTC time and all issues there would go away.

    And remember, Get-Date was just a random CmdLet I picked....the same ambiguity are all over the place making it very problematic to use PowerShell where it really need to work all the time.

    Friday, January 1, 2016 3:54 PM
  • Unfortunately, they only hold courses during the daytime when i work  :)

    And new stuff is constantly released and updated so a course becomes "old" very fast.  A solid documentation is what is needed.

    Friday, January 1, 2016 3:57 PM
  • for example, no mention of what exceptions could occur.

    And the fact that it does not specify if it returns a UTC date or a local date forces you to check the return value after each call.

    On the other hand, in .NET youy have DateTime.Now and Date.Time.UtcNow to get exactly what you want and you don't have to check what you got. It would be so easy for GetDate to just specify it always return UTC time and all issues there would go away.

    And remember, Get-Date was just a random CmdLet I picked....the same ambiguity are all over the place making it very problematic to use PowerShell where it really need to work all the time.

    It always returns a local date.  It is in the docs.  Yu have to ask for Utc.


    \_(ツ)_/

    Friday, January 1, 2016 3:58 PM
  • Yes but there is no telling what Get-Date does with the date before it is returned to me.  If they said you get what we get from DateTime.Now it would be ok, but they does not say anything about it at all...
    Friday, January 1, 2016 3:59 PM
  • I agree with Vadim.  You should start by doing the courses.  Many of you issues will disappear once you actually dsort out what is PowerSHell, what is Net and what is system.

    You should also change the type of this thread to "Discussion" as there is really no specific question here.


    \_(ツ)_/

    Friday, January 1, 2016 4:00 PM
  • local time according to which profile?  System Local?  Current user?
    Friday, January 1, 2016 4:00 PM
  • A list of complaints about lack of documentation (perceived or otherwise) isn't really a question.

    I don't think anyone will be able to satisfy your list of complaints in this forum. We're not Microsoft employees, and there is no service-level agreement that guarantees that someone has the time to research all of these for you.

    However, I would suggest studying the .NET framework and the CLR. (PowerShell is based on the .NET framework, after all.)


    -- Bill Stewart [Bill_Stewart]

    Friday, January 1, 2016 4:04 PM
    Moderator
  • Thanx, it's for PowerShell 3.0 and the latest version is 5.0. But it is better than nothing....but the fact that it is for version 3.0 and that is no one available for v4 and v5 kind of strengthen my belief that this is something that is not a very High Priority thing for Microsoft. Because they obviously have them but didn't bother publish them...and then the fact that the only way of finding them is to use google....especially when you do a search for pages containing a link to the PowerShell language specification download page and no pages at microsoft.com links there....

    All versions of PowerShell are backwards comparable as a language.

    V3 is the latest and most complete spec.  V4 and V5 have  not change the language. They have only added some capabilities.

    V3 is now the only version supported on all current platforms. 

    To find the new capabilities look at the release notes.  Language and feature changes are documented there.

    V4 and V5 have extensions that are not truly language additions but are added subsystems and providers such as DSC.  These are documented in their own documentation.


    \_(ツ)_/

    Friday, January 1, 2016 4:05 PM
  • When I read your second post, I had to take a walk to calm myself and collect my thoughts. But I feel I must reply. There has been back and forth since that post which I have not reviewed. What follows may surprise many.

    First, I feel your pain. I have had many similar experiences. PowerShell is opaque by design, to shield you from the complexities of what it is doing for you under the covers. This makes some things convenient (like automatically converting AD LargeInteger values into date times in the local time zone).

    I learned VBScript in two weeks many years ago, and occasionally need to reference a slim book documenting about 200 functions for syntax, but I can basically code it in my sleep. By contrast, with PowerShell I am severely limited by having maybe only 8 years experience (and a poor memory). There are thousands of PowerShell cmdlets, and it is impossible to be cognizant of so many. I am constantly amazed at how difficult the simplest tasks can become. When people say the language is self documenting, I understand it is, but it seldom answers my questions. The examples in the help are often next to worthless.

    I was excited when PowerShell was first introduced and I saw a demo in Redmond. I waited until I had about 2 years experience with it before I converted one of my VBScripts. The original script took 2 days thinking about the concepts, then 30 minutes to write the code, and 30 minutes testing and troubleshooting. When I later converted to PowerShell, I thought it would be a snap. I already had puzzled out how to tackle the problem conceptually. Plus I had the VBScript in front of me. It took me 2 weeks. Part of my problem is that I was a VB developer, and found a lot of synergy with VBScript. PowerShell is based on .NET and C#.

    I now do all (or most) of my work in PowerShell, because it is what people want. And more and more there is no longer a VBScript solution. Recently I have been working on a complex PowerShell script. Twice I had situations in the script where I retrieve the same value, but in different places I need to use different code. The objects I am dealing with look the same, but are different under the covers, and I spend time with Get-Member and research to reinvent how to do what worked flawlessly earlier in the script. I am also annoyed by the differences PowerShell versions can make.

    In VBScript I always use "Option Explicit" and Dim all variables. I never use "On Error Resume Next", except for single statements where I handle the possible error, then use "On Error GoTo 0" to restore normal error handling. This makes troubleshooting a snap. In PowerShell, one annoyance is that many syntax mistakes do not raise an error. It can help to use "Set-StrictMode", but it is seldom used.

    Sorry, I cannot defend PowerShell. It is opaque by design. The purpose is to allow people with little knowledge of a technology to quickly use a canned script given to them to achieve a single task. Learning all the quirks can take years.


    Richard Mueller - MVP Enterprise Mobility (Directory Services)

    Friday, January 1, 2016 4:08 PM
    Moderator
  • Still, no reason not to document it so I can focus on solving real world problem and not reverse engineer PowerShell to get stuff working.
    Friday, January 1, 2016 4:11 PM
  • Richards commentarty is very enlightening and should give you some idea of what/how PowerShell.

    I disagree with some of it.  I think because of a long background in Net/C$ and systems coding PowerShell eems to me to be the ultimate tool.  I seldom have an issue with quirks and I have written a fair amount of PowerShell code over the years.  I also learned to use it very quickly as it fits my background in declarative programming.

    It is my strong sense that, if you are not a very experience systems programmer, yu shud start with a traing course or one of the good training books before you even rty to assess PowerShell.  As I have noted earlier, PowerSHell should not be judged by older srtandards withut fully understandin hw it is different from other systems.


    \_(ツ)_/

    Friday, January 1, 2016 4:18 PM
  • local time according to which profile?  System Local?  Current user?

    If  you look at the clock on your desktop so you ask that question?

    \_(ツ)_/

    Friday, January 1, 2016 4:19 PM
  • Unfortunately, they only hold courses during the daytime when i work  :)

    And new stuff is constantly released and updated so a course becomes "old" very fast.  A solid documentation is what is needed.

    That reminds me of this: https://www.youtube.com/watch?v=DtMV44yoXZ0


    \_(ツ)_/

    Friday, January 1, 2016 4:22 PM
  • This is what the documentation say:

    -Date<DateTime>

    Specifies a date and time. By default, Get-Date gets the current system date and time.

    Type the date in a format that is standard for the system locale, such as dd-MM-yyyy (German [Germany]) or MM/dd/yyyy (English [United States]).

    System local is not what is shown on my Desktop, also it is not what .NET uses (.NET defaults to the culture of the current thread), also it say "format", so does it mean that only the format from system local is used or at the other properties of that environment used but just not mentioned? And what about the format, wasn't the -Format parameter supposed to handle formatting? It just doesn't make sense and it like this all over the place, Get-Date was just an example to point out that it is not really a useful documentation at all.

    Friday, January 1, 2016 4:26 PM
  • I disagree with a simple comparison between VBScript and PowerShell - IMO this is comparing apples and oranges. VBScript is merely an interpreted language that, in WSH, can access COM objects to manage the system. PowerShell is based on .NET, so two completely different things.

    But in any case, as I noted, a list of complaints about a lack of documentation for PowerShell (perceived or otherwise) doesn't constitute a question, and therefore I have changed this thread from question to discussion.


    -- Bill Stewart [Bill_Stewart]

    Friday, January 1, 2016 4:31 PM
    Moderator
  • This is what the documentation say:

    -Date<DateTime>

    Specifies a date and time. By default, Get-Date gets the current system date and time.

    Type the date in a format that is standard for the system locale, such as dd-MM-yyyy (German [Germany]) or MM/dd/yyyy (English [United States]).

    System local is not what is shown on my Desktop, also it is not what .NET uses (.NET defaults to the culture of the current thread), also it say "format", so does it mean that only the format from system local is used or at the other properties of that environment used but just not mentioned? And what about the format, wasn't the -Format parameter supposed to handle formatting? It just doesn't make sense and it like this all over the place, Get-Date was just an example to point out that it is not really a useful documentation at all.

    The locale is what you are using currently on your desktop except if you have changed it in your session.  If yu are working with a cross local/culture script then you have to code for that.  It is never automatic in any language.

    A way to declare a date in code with Get-Date is built in just like in C#

    Get-Date -Day 1 -Month 1 -Year 2016 -Hour 12 ...

    This will work in all cultures/locales.

    Mostly your isses are due to a lack of fundamental technical knowledge about how t work in a multi-culture environment.  That is beyond the scope of the PowerShell documentation.  The tools are nearly always ther and work.  You just have to know how to recognize them.

    As  a consultant I have no issues with using PowerShell inn large environments.  It will certainly work better then batch files and VBScript.

    I would not recommend using PowerShell as a replacement for a compiled and tested program for user interaction with a database or other complex application solutions.  PowerShell is not an application development tool.  It is an admin and maintenance tool designed t be used by technicians.


    \_(ツ)_/

    Friday, January 1, 2016 4:40 PM