Skip to content

sc start "my service" returns nothing and doesnt start services #3980

Closed

Description

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.

Activity

  1. mklement0 commented on Jun 9, 2017

    @mklement0
    Contributor

    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.

  2. StingyJack commented on Jan 3, 2018

    @StingyJack
    ContributorAuthor

    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'

  3. SteveL-MSFT commented on Jan 3, 2018

    @SteveL-MSFT
    Member

    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

  4. StingyJack commented on Jan 8, 2018

    @StingyJack
    ContributorAuthor

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

  5. markekraus commented on Jan 8, 2018

    @markekraus
    Contributor

    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.

  6. StingyJack commented on Jan 8, 2018

    @StingyJack
    ContributorAuthor

    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.

  7. mklement0 commented on Jan 8, 2018

    @mklement0
    Contributor

    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.

  8. StingyJack commented on Jan 9, 2018

    @StingyJack
    ContributorAuthor

    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..

  9. SteveL-MSFT commented on Jan 9, 2018

    @SteveL-MSFT
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions