Powershell: sc start "my service" returns nothing and doesnt start services

[StingyJack]

Steps to reproduce

type command above in for any service

Expected behavior

service is started or at least an error

Actual behavior

nothing is written to the screen.

Environment data

whenever that terrible Set-Content alias was added.

[mklement0]

Please make the title and body of your post more descriptive, given that you've already figured out that the problem is that the sc _alias_ (for Set-Content) is invoked rather than the sc.exe service-control _executable_.

Yes, it is unfortunate that in this case nothing _seems_ to happen at all (in reality, a file named start with content my service is being created, because, due to positional parameter binding, your command is equivalent to Set-Content -Path start -Value "my service"), making it harder to diagnose the problem.

A simple workaround is to invoke the executable with its extension:

sc.exe start "my service"

Or, better yet, use PowerShell's own Start-Service cmdlet.

[StingyJack]

The problem is someone picked a poor alias name for a lesser used powershell command that overrides a longer lived and more used windows command, and it tells noone this by error or informational message.

Instead of thinking of this as 'the user discovered their error', consider it as 'we made something confusing that wastes peoples time, we should probably address that'

[SteveL-MSFT]

@StingyJack agree that a poor alias was chosen, but it was chosen a long time back so now we have a risk of breaking someone the other way

[StingyJack]

Writing a warning message would be useful if it can detect that this is happening

[markekraus]

@StingyJack That would be something probably better suited for a PSScriptAanalyzer Rule to detect during coding rather than burden the command resolution at run-time, IMO.

[StingyJack]

PSScriptAnalyzer... you mean that thing that _still_ isnt baked into Microsoft's Premier IDE? I would love that, but its not happened yet. I barely get intellisense and they havent even bothered to make format document work and it prevents editing while comparing.

I'm not sure that would help in this specific use case though. a sysadmin is going to generally be typing this into a console window, probably ad-hoc, and probably with some kind of immediate issue they are trying to resolve. And they are going to be left scratching their heads wondering why the ancient and venerable service controller executable doesn't seem to work anymore. Maybe the production server needs a reboot, maybe its time to restore from tape, because its very bad when this happens.

FUD aside, this should at least have the decency to report that its probably not the tool the user is probably expecting when presented with a specific set of parameters, or at least never report _nothing_ when executed. It would decrease a lot of panic and stress and undo a bit of the damage of a bad design/naming choice.

[mklement0]

As an aside: At this point, with respect to PowerShell, it is Visual Studio _Code_ that is the premier IDE - and it does have PSScriptAnalyzer.

PowerShell _Core_ has generally adopted a - sensible - policy of _not_ shadowing ships-with-the-OS external utilities (executables) and has removed many of the aliases present in _Windows_ PowerShell (which would clash with many a _Unix_ utility).

Therefore, I agree that alias sc should be _removed_ from PowerShell _Core_ (a change that should be acceptable, given that there hasn't been a _production_ release yet).

In _Windows_ PowerShell, however, removing the alias is not an option lest backward compatibility be broken - _Windows_ PowerShell may not see updates beyond bug fixes, however.

---

From the DoH (Department of Hypotheticals):

Were something to be implemented, it could be patterned after the _suggestion_ that is displayed when you try to execute an executable in the current location without prefixing its name with ./.

That said, the tricky aspect here is that sc start foo doesn't _fail_, because - as stated - it is the equivalent of Set-Content -Path start -Value foo and therefore perfectly valid.

Generally, Windows PowerShell users may have gotten used to sc as a Set-Content aliases and rely on it frequently - they wouldn't want to see a suggestion every time they use sc.

Under the circumstances, the best thing you could do is to only emit the suggestion for Set-Content -Path values that correspond to sc.exe sub-command names such as start - though even then the user may have intended a Set-Content call and perceive the suggestion as disruptive.

[StingyJack]

As an aside: At this point, with respect to PowerShell, it is Visual Studio Code that is the premier IDE - and it does have PSScriptAnalyzer.

But it cant load a VS Solution with multiple projects and other loose but related scripts and content. The last few times I've tried to use VSC its "lost" the powershell host while debugging, and it generally doesn't feel like its not going to delete my code due to some weird-ass bug.

We also didn't pay in the neighborhood of $$$$$ for Enterprise MSDN VS to have MSFT not put those tools in VS first. Not that it hasnt felt like a total ripoff already - I'm closing in on 300 issues reported since Jan 2017 =/

I'll take the removal from "core" as the first real win from MSFT in a year, but I probably wont get the chance to use any of the "core" stuff except for personal projects unless it outright replaces what ships with windows..

[SteveL-MSFT]

@StingyJack the fact that PSCore6 works side-by-side with Windows PowerShell means you can use it. Certainly enterprise policy may not allow actual deployment of PSCore6, but that's a different problem.

Removing any alias from Windows PowerShell is too big a breaking change to even be considered.

VSC is the premier cross platform IDE. It still a work in progress and will improve over time. VS has features that will never show up in VSC. The PowerShell Team focused on VSC because of it is cross platform and the major feature of PSCore6 is cross platform. VS support of PowerShell will improve.