Use PowerShell as default shell for Windows machines

for using PowerShell

I haven't bothered yet to learn PowerShell, so that will be something drastically affecting me at least. For me it looks overly complicated for simple things that batch is being used for usually.

I do agree though that it has a lot of issues that you need to be aware of and work around (passing arguments with spaces for example is one hell of a major pain)

If you're able to give me some documentation of a "batch vs. powershell" with common tasks like running a simple command like "git submodule update --init", which I can do directly inside batch without something like system() on C then I'm willing to learn it and of course support this endeavour where I can.

PS: I'm totally fine with being able to use bash on windows, though I'm not sure how that'll work exactly.

If I am allowed to drop my 2 cents to second what @neico said. Powershell is amazingly complicated. I tried to learn and use the language, and all I did had to be done in very unintuitive and complex way. On the surface it looks shiny and new, and losing the apparent baggage of cmd scripts. However, getting any practical results in it is enormously burdensome. Many StackOverflow answers to PowerShell questions include disclaimers to the effect of "yes, this is weird and strange, but this is how you do it in PowerShell." I have dismissed it completely as a failed and botched attempt at an improvement of Windows command shell. Please think very very carefully before embracing it. It is certainly not what it seems on the surface!

I have to disagree with @kkm - PowerShell is a very intuitive and powerful scripting language and ships with all Windows versions starting with Windows Vista. It's the defacto standard scripting language on Windows and the successor to the now deprecated cmd. PS becomes more and more important on Windows with syntax highlighting, package management and PS module repositories.

It makes sense to natively support PowerShell in favour of cmd/bash simply because it's become the go-to cli on Windows operating systems.

@megamorf I see the benefit, but you still can use powershell. It's hard to have support for everything in Bash and in PowerShell. I'll definitely drop Windows Batch support. It's old and have a lot of problems.

Milestone changed to v0.7.0

Reassigned to @ayufan

@megamorf: This is certainly a matter of personal preference, and nothing can be said except for the usual advocacy arguments (e.g. why Linux is better than Windows, or the other way round). My argument was about heeding caution in the decision to adopt Powershell, not jumping headlong into it because it is new, or for other irrational reasons. FWIW, bash is older than cmd, so what?

Here's one example: http://stackoverflow.com/a/3890440/1149924. Note that the answer given essentially is "it is impossible to do, and this is not a bug but a feature". This is not to say that cmd quoting is consistent and lovable, but I could get it working after some aggravated tweaking; with PS I spent hours before finding the SO answer declaring it impossible. There are many issues with a similar "impossible by design" conclusion, not only quoting. This is another example from our production code. May God help us, we got a workaround for this case.

# Neither return nor exit do in PowerShell what you think they do.
# This function is from http://weblogs.asp.net/soever/returning-an-exit-code-from-a-powershell-script
function ExitWithCode {
    param($exitcode)
    $host.SetShouldExit($exitcode)
    exit
}

This is a function one needs to write to simulate cmd or sh exit keyword. You must write your own exit keyword, for God's sake! This is an indication of a design that is a bit unusual for something many people in the community assume to be a shell--you would think that returning an exit code to the calling process is pretty much a basic function, but in Powershell it is not.

So when I find it hard to perform the two of a set of most basic shell functions in a programming language (invoking a process and returning an exit code), and when one of these begets a whole research adventure and a large blog post, I begin to doubt that this language is actually a good fit for a shell scripting tool. YMMV, indeed: again, one may love what they love and hate what they hate, and PS does have many good and useful features. My argument here is that forcing users into a technology that has a lot of known issues (some of which do not have even a workaround) must not be done is haste. I do not understand the rationale behind your disagreement with that--a similar argument applies almost to any decision in our field.

On the third hand, Powershell can still launch most batch files (unless one runs into argument quoting issues, indeed), so this probably a moot point...

My point is it makes no sense to support a deprecated shell in the medium-term, this has nothing to do with preference. Bash (or posix shells in general) and PowerShell have two completely different scripting approaches (text vs object orientation) which is reflected in the respective shell's syntax.

I understand that batch might be more familiar due to it being around for a long time but that's no argument for it's continued support when when its superior successor has been around for almost 10 years by now. A thing that speaks for PowerShell is its 3rd party support - it can directly interface with Active Directory, Storage Arrays, Hypervisors, Servers, Switches, Web Services and much more while having a coherent and consistent syntax across all these resources.

Not all commands can be run in PowerShell directly, that is true, but there's a start-process and --% operator that allow you to run your code.

As for your problems with exit codes - they work fine. Your referenced link just shows how a person is trying to work against scoping and the right parameters.

While I'm personally not a big fan of PowerShell, I do feel that it should be set as the default for Windows -- as long as it's clearly documented in the installation guide, so that Windows XP and Server 2003 users know they need to install Windows Management Framework in order to use gitlab-ci-multi-runner.

As much as I love bash, it shouldn't be setup as the default for Windows just for the fact that it's not included by default. If an advanced user wants to install bash on Windows and use it for their builds they should be allowed to -- but I think moving forward it shouldn't be the default for Windows.

I'm also personally iffy about the removal of Windows Batch support, just because Windows XP/Server 2003 does not have PowerShell installed by default, however, I understand the reason for it. I'd rather have the gitlab-org team focused on adding new features vs fighting old scripting environments.

-robodude666

@robodude666:

so that Windows XP and Server 2003 users know they need to install Windows Management Framework

Windows XP and Server 2003 are past sunset. Their users should better know not to run these operating system because they no longer receive security patches, and therefore are high on the security crack target list. Supporting outdated OSes generally understood as encouragement of their users to continue using the unsafe software, and I do not think GitLab should be encouraging that. Therefore, I think the concern about their missing PowerShell by default is not, fortunately, valid.

@kkm In some cases users are forced to use Windows XP/Server 2003 due to supporting legacy software.

@robodude666: Well, too bad for them. What if they are "forced" to support Windows 2000? Windows 98? NT 4.0? There is a reasonable limit on what GitLab should support. GitLab EE is a supported commercial product, and the runner is part of the EE. The only rational thing here is to follow the OS manufacturer support guidelines; anything else is an arbitrary decision, and extending the range of supported OSes is a burden on GitLab. I believe the right thing to do in this case is say you are on your own, GitLab does not support it, but (wink, wink) try to install PowerShell, and it may work for you. If not, sorry.

How do you load the VS2015 tools into power shell? I see the batch files in the start menu for the cmd environment but there don't appear to be any corresponding files for power shell. That environment is basically required for builds with visual studio.

@kjeremy: Tell that to @ayufan. He already went for the nuclear option, and we the customers are to catch the fallout, however big it is. Does GitLab care about their paying customers? “We'll kill a huge feature in a month, not stuff that in your pipe and smoke it.” Which means not a piss. The hastiness of the decision without any technical explanation to the customers is a quite unexpected and in-your-face decision. No wonder we "supported" customers are pissed.

You'll come up with an unsimple weave of batch files to support multiple VS environments. Or better yet fork your own multirunner code. Supporting cmd is no big deal at all (look at https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/shells/cmd.go), it's just someone does not fancy it...

@ayufan: Here's the deal. You do not drop cmd, and I'll support it. Would you accept that?

@kkm Windows Batch is still default shell. We will change it to PowerShell. I don't plan to drop support. However, some of the features will not be accessible in Batch, because it's hard to build them into it :(

@ayufan If the Visual Studio environment doesn't support PowerShell out of the box then we shouldn't switch away from cmd without a big fat section on the wiki/readme about how to enable this. It's the number 1 supported environment on windows.

@kkm You can run .cmd/.bat files in PowerShell.

@megamorf: Thank you Capt. Obvious!

@ayufan, @kjeremy, everyone interested: cmd/batch files by default leave behind the environment variables (just like a shell script invoked with the source/. command). This is the feature used when setting up environments for different Visual Studios, and different environments in each. Run ...Visual Studio 14.0\VC\vcvarsall.bat x86, and you are in VS2015 native (Intel) 32-bit environment. Invoke vcvarsall.bat from another VS with different arguments, and you have different environment. We are using currently only two, but if you are releasing a 32/64 bit library, I think I'd test it with VS11, 12, 14 at the very least, 6 environments (and I still cannot find how to run matrix builds in GitLab CI!).

Indeed, there is source in bash and . in PowerShell; the problem is that the file vcvarsall.bat is already a .bat file as supplied by Microsoft, and they are not hurrying up to provide a PowerShell version of it. Indeed, you cannot simply source a bat file into powershell without some really heavy machinery--and keep in mind the solution on SO is wrong, as it will break on multiline environment variables; I am providing it as an example of the simplest and incorrect solution. A correct one would probably involve writing a cmdlet extension in C#.

Now, it seems not very hard to write a batch file that takes the visual studio directory, environment name and the rest of arguments to execute, like in

runwithenv 14.0 x86 msbuild integration.xml -m -v:m -t:test

but I did run into argument quotation issues trying to generalize the tool. There is not an analog of "$@" in cmd, unfortunately.

@ayufan: I did not really want to be as harsh as I sounded. Thank you for reversing the decision to drop batch support. Please understand me too: as a GitLab customer, I started scrambling for a quick solution with PowerShell, and I have a lot on my plate already.

If you do not mind, can you explain what are the technical problems and the features that would not be available in batch? I may have some ideas how to overcome them. My offer to support batch scripts in still in force! :)

@kkm You should stop being so offensive. It thwarts all of your arguments when people are fed up with listening to you because all you've done is attack them.

Just because PowerShell becomes the default CI runner Shell doesn't mean that cmd stops working automagically. @ayufan only said that he doesn't want to support new stuff in cmd because "It's old and have a lot of problems".

As for quotation issues, have a look at here-strings and parameter substitution ("{0}" -f $myvar.value)

The inital issue is, as the issue title states, to remove batch support, which as you can clearly observe will upset quite a few.

I however have nothing against changing the default shell from cmd to PowerShell as it's encouraging new people to the newer language while keeping support for the older environments, and of course fallbacks for when something doesn't end up working.

For @ayufan not wanting to bother much with cmd support, I can understand it, even though I still prefer cmd over powershell. But that's what the community and Merge Requests are for, no?

So here's the deal: drop the "drop" part and let the community handle compliance with cmd. Then everyone's happy.

PS: having bash as optional option on windows would be a very cool thing, making ci scripts more unified and such~

Title changed from Drop Windows Batch and use Bash also on Windows to Use PowerShell as default shell for Windows machines

I changed the title.

Let me guys reiterate this is not something "one personally likes/dislikes" or "one has nothing against changing the default shell". This is not a personal preference issue. A technical problem (it bear repeating: technical, not a personal like/dislike) is the possible need to "dot-source" scripts provided by the manufacturer of the development kit. When the said development kit is Visual Studio, then the script is a toolkit-provided batch file.

I do not "like" or "hate" software, I just use it. Dropping batch support does not exactly mean dropping support for Visual Studio, but comes pretty close to that in more advanced than very basic scenarios. Obviously such a decision not to be made casually to say the very least, and God forbid for advocacy/ideology reasons. Ergo, I'll continue to be very offensive to anyone who says “PowerShell is cooler, and you still can do X in PowerShell, while at the same juggling sabers and playing four violins at once,” unless X is relevant to an unsolved problem logged here.

I propose to restrict this discussion to (1) things you cannot do in PowerShell (and at least the VS show-stopper is pretty much covered) and possible ways to work around these; and (2) the problems that exist in supporting the cmd batch script as a runner's shell and ways to solve them. Solving either (1) or (2) (or both indeed) will resolve the bigger issue of the @ayufan's cost of supporting the cmd shell.

For example: looking at these microsoft batch files, they are not amazingly complex: they just look at environment variables and registry values and create other environment variables. Equivalent replacements might be easier to maintain than CMD in the runner to @ayufan (but keep in mind they must be supported by GitLab for EE customers!). Or some of many PowerShell gurus in this discussion comes with a robust way to dot-source these batch files into PowerShell (with tests that support multiline environment variables, please). That's is for (1). For (2), maybe @kkm will find a way to support fancy new features in cmd, when he understands what problems @ayufan is facing. Perhaps there other ways to solve it--please just use this space for a constructive exchange of ideas.

I don't know how much relevant and helpful is for the discussion, but I came across http://cmder.net/ today and it seems a pretty powerful tool for windows.

Milestone changed to v1.0

Milestone changed to v1.1

Assignee removed

Milestone changed to v1.2

I see that a long discussion has already occurred, and I have read it all.

I see the reason why we need the dos batch default. What would be great is if the .yml syntax would let me specify that a line is directed to CMD or BASH or POWERSHELL by some simple syntax inside the gitlab ci yaml.

Someone really should ping Scott Guthrie and Scott Hanselman and get them to provide powershell environment setters in the next visual studio.

I want to build all my orchestration for windows CI around powershell, and yet the Windows platform and the Visual Studio Tools for this are still in their infancy.

I am half thinking that neither one is ready for me, and I'll just write my own stuff 100% from scratch, in Python.

Milestone changed to v1.3

Milestone changed to %Backlog

Use PowerShell as default shell for Windows machines

Designs

Child items ...

Activity

Admin message

Admin message

Use PowerShell as default shell for Windows machines

Activity