You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sc start "my service" returns nothing and doesnt start services #3980
Please make the title and body of your post more descriptive, given that you've already figured out that the problem is that the scalias (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.
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'
Andrew Stanton (@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
Andrew Stanton (@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.
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.
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.
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..
Andrew Stanton (@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.
Activity
mklement0 commentedon Jun 9, 2017
Please make the title and body of your post more descriptive, given that you've already figured out that the problem is that the
scalias (forSet-Content) is invoked rather than thesc.exeservice-control executable.Yes, it is unfortunate that in this case nothing seems to happen at all (in reality, a file named
startwith contentmy serviceis being created, because, due to positional parameter binding, your command is equivalent toSet-Content -Path start -Value "my service"), making it harder to diagnose the problem.A simple workaround is to invoke the executable with its extension:
Or, better yet, use PowerShell's own
Start-Servicecmdlet.StingyJack commentedon Jan 3, 2018
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 commentedon Jan 3, 2018
Andrew Stanton (@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 commentedon Jan 8, 2018
Writing a warning message would be useful if it can detect that this is happening
markekraus commentedon Jan 8, 2018
Andrew Stanton (@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 commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
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
scshould 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 foodoesn't fail, because - as stated - it is the equivalent ofSet-Content -Path start -Value fooand therefore perfectly valid.Generally, Windows PowerShell users may have gotten used to
scas aSet-Contentaliases and rely on it frequently - they wouldn't want to see a suggestion every time they usesc.Under the circumstances, the best thing you could do is to only emit the suggestion for
Set-Content -Pathvalues that correspond tosc.exesub-command names such asstart- though even then the user may have intended aSet-Contentcall and perceive the suggestion as disruptive.StingyJack commentedon Jan 9, 2018
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 commentedon Jan 9, 2018
Andrew Stanton (@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.