3 ms·

> you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them). This is a pre

by scbrg 6y ago

> you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them). This is a pretty absurd take when the discussion is about alternative shells for writing scripts. Shell scripts are everywhere. A fairly heavily used UNIX box might easily execute hundreds of shell scripts every minute. A startup time of several seconds makes it completely unusable.

majkinetor 6y ago
Not sure what to tell you to break your bubble. I have literary thousands of pwsh scripts running in critical gov projects in production, most of them as part of CI, CD, build and automatic test but some of them serving millions of users. I had dozen of such projects in previous decade on Windows and several on Linux and never had any significant problem with slow startup really. Sometimes it happened that some machines had slow startup but team usually fixed that one way or another. Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. And pwsh is different - it has modules which are encapsulated and you don't have to start another instance of shell to prevent mingle. Parallelism ofc still benefits from faster startup.
- scbrg 6y ago
  > I had dozen of such projects in previous decade on Windows and several on Linux and never had any problem with slow startup really. OK. So then startup time is not slow? Well, then it's of course a non issue - but then I also don't see why a process pool would be required. > Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. Yet, you just did :) Anyway, it was hardly intended as bragging, rather than just stating facts. Lots of stuff are shell scripts. Lots of user facing commands are wrapped in shell scripts. Of the ~3k commands in my $PATH, around 500 are shell scripts. You may not think this is a good state of affairs, but it's still a fact. (And it's quite unclear to me what's so bad about it - an excellent use for scripts is providing environment for other programs.)
  - majkinetor 6y ago
    > OK. So then startup time is not slow? Well, then it's of course a non issue Its not as fast as bash or cmd but I don't start hundreeds of instances of shell > but then I also don't see why a process pool would be required. If you have habit of starting shell every ten seconds or so and equally fast close them, I guess powershell will not be your friend. Bad habit to have anyway IMO, because there are few tools that support that workflow. > Yet, you just did :) I never said I run bunch of instances of pwsh - I usually run couple only and within them, everything happens. Although pwsh starts in 300ms on my machine. > And it's quite unclear to me what's so bad about it The bad about it is jungle of bashizms and next to 90% of statements which have nothing to do with actual business logic but are there for text massage and parsing. You can't really compare bash and pwsh tho - you have entire dotNet ecosystem there compared to bash where you need jungle of tools. You can do almost ANYTHING in pwsh without relying on external tools. That is consistency - on different flavors of linux, some tools are there, some are not, and some are just different, even the basic ones such as stat. I get nightmares from the fact that grep and sed and awk and perl and rg and whatever each use their own flavor of reg ex... Its just insane :) pwsh is more comparable to mainstream languages like go or python. What separates it from them is that it is designed for shell. With that power, I can understand a little bit of slower startup time, but I am sure it will be solved eventually.
    - jen20 6y ago
      > Bad habit to have anyway IMO, because there are few tools that support that workflow. This is absolutely false. Powershell and the Windows console prompt do not support this workflow. Every other shell/terminal emulator combination I can think of supports it fine. Perhaps you can elaborate on why you consider it to be a "bad" habit?

by scbrg 6y ago

majkinetor 6y ago

Not sure what to tell you to break your bubble. I have literary thousands of pwsh scripts running in critical gov projects in production, most of them as part of CI, CD, build and automatic test but some of them serving millions of users. I had dozen of such projects in previous decade on Windows and several on Linux and never had any significant problem with slow startup really. Sometimes it happened that some machines had slow startup but team usually fixed that one way or another. Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. And pwsh is different - it has modules which are encapsulated and you don't have to start another instance of shell to prevent mingle. Parallelism ofc still benefits from faster startup.

scbrg 6y ago
> I had dozen of such projects in previous decade on Windows and several on Linux and never had any problem with slow startup really. OK. So then startup time is not slow? Well, then it's of course a non issue - but then I also don't see why a process pool would be required. > Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. Yet, you just did :) Anyway, it was hardly intended as bragging, rather than just stating facts. Lots of stuff are shell scripts. Lots of user facing commands are wrapped in shell scripts. Of the ~3k commands in my $PATH, around 500 are shell scripts. You may not think this is a good state of affairs, but it's still a fact. (And it's quite unclear to me what's so bad about it - an excellent use for scripts is providing environment for other programs.)
- majkinetor 6y ago
  > OK. So then startup time is not slow? Well, then it's of course a non issue Its not as fast as bash or cmd but I don't start hundreeds of instances of shell > but then I also don't see why a process pool would be required. If you have habit of starting shell every ten seconds or so and equally fast close them, I guess powershell will not be your friend. Bad habit to have anyway IMO, because there are few tools that support that workflow. > Yet, you just did :) I never said I run bunch of instances of pwsh - I usually run couple only and within them, everything happens. Although pwsh starts in 300ms on my machine. > And it's quite unclear to me what's so bad about it The bad about it is jungle of bashizms and next to 90% of statements which have nothing to do with actual business logic but are there for text massage and parsing. You can't really compare bash and pwsh tho - you have entire dotNet ecosystem there compared to bash where you need jungle of tools. You can do almost ANYTHING in pwsh without relying on external tools. That is consistency - on different flavors of linux, some tools are there, some are not, and some are just different, even the basic ones such as stat. I get nightmares from the fact that grep and sed and awk and perl and rg and whatever each use their own flavor of reg ex... Its just insane :) pwsh is more comparable to mainstream languages like go or python. What separates it from them is that it is designed for shell. With that power, I can understand a little bit of slower startup time, but I am sure it will be solved eventually.
  - jen20 6y ago
    > Bad habit to have anyway IMO, because there are few tools that support that workflow. This is absolutely false. Powershell and the Windows console prompt do not support this workflow. Every other shell/terminal emulator combination I can think of supports it fine. Perhaps you can elaborate on why you consider it to be a "bad" habit?