none
Parsing question? Timeout issue? COMPLETE PS NOOB here....

    Pertanyaan

  • I'm flummoxed.

    I can run these commands, and I get different results than when I pipe them all together.

    get-service | export-clixml c:\temp\46lab1.xml | stop-service bits | get-service | export-clixml c:\temp\46lab11.xml | start-service bits

    Yields one XML file (46lab1.xml @ 11KBytes) and one XML file (46lab11.xml @ 166 bytes).  Of course that's not what I would expect.

    If I enter these commands manually, piping the commands:  get-service | export-clixml c:\temp\thatfile.xml it works as advertised, and I get good data.

    Hope I'm not leaving anything out.  Is there a condition where it's not completing due to a timing issue?  I ran this in the ISE and saw no errors, and got the same results.  Is it a permissions issue?  I'm trying to wrap his head around this one and coming up with no answers.

    Thanks for the help :)

    03 Maret 2012 23:44

Jawaban

  • I don't think the problem is that stop-process doesn't accept pipeline input, but that get-process does.

    get-service | export-clixml c:\temp\46lab1.xml | stop-service bits | get-service | export-clixml c:\temp\46lab11.xml | start-service bits

    You're piping the output of stop-service (which is nothing) to get-service, and get-service is finding all the services by that name (none).  You can't make much of an xml file out of that.

    It broke at export-clixml.  You can't put that in middle of a pipeline because it doesn't output anything to the pipeline, and it doesn't have a -passthru switch to enable it.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "



    04 Maret 2012 2:35
  • If you must code it on one line, some of those | characters should be ; characters.
     
    get-service | export-clixml c:\temp\46lab1.xml ; stop-service bits ; get-service | export-clixml
    c:\temp\46lab11.xml ; start-service bits
     
    04 Maret 2012 3:41

Semua Balasan

  • The idea of piping is that the output of one command becomes the input to the next command in the pipeline.

    That said, your first export-clicml command has no output to pass along to the stop-service command, and the stop service command doesn't seem interested in accepting parameters from the pipeline. So my question to you is what is your purpose in this particular pipe?

    It would seem that the most likely intent is the following:

        get-service | export-clixml c:\temp\46lab1.xml
        stop-service bits
        get-service | export-clixml c:\temp\46lab11.xml
        start-service bits

    I suspect that your unusual piping may indeed be the cause of your problem. It would be interesting to see the content of the second .xml file, as I suspect it might contain a description of exactly one service.


    Al Dunbar

    04 Maret 2012 1:22
  • I don't think the problem is that stop-process doesn't accept pipeline input, but that get-process does.

    get-service | export-clixml c:\temp\46lab1.xml | stop-service bits | get-service | export-clixml c:\temp\46lab11.xml | start-service bits

    You're piping the output of stop-service (which is nothing) to get-service, and get-service is finding all the services by that name (none).  You can't make much of an xml file out of that.

    It broke at export-clixml.  You can't put that in middle of a pipeline because it doesn't output anything to the pipeline, and it doesn't have a -passthru switch to enable it.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "



    04 Maret 2012 2:35
  • If you must code it on one line, some of those | characters should be ; characters.
     
    get-service | export-clixml c:\temp\46lab1.xml ; stop-service bits ; get-service | export-clixml
    c:\temp\46lab11.xml ; start-service bits
     
    04 Maret 2012 3:41
  • I had no idea that piping the commands in the way that I did woudln't work.  My reasons for running this command list was to produce (in one line) the complete set of commands that I'd need to output two clixml files to then diff against in another command.

    My thought (wrongly it seems) is that the get-service would then be the input for the export-clixml command.  The command after that was not one that passed paramenters (incorrect?) and then running through another get-service command, which would then pipe the output to the next expor-clixml command.  Then from your remarks, I'm now thinking that the stop-service command somehow breaks the chain?  Why would stop-service break this chain?

    Why would stop-service break this?

    How would export-clixml pass anything at all to the next command in line?  Doesn't it clear the 'stack' after it writes the output to a file?

    WFIW the first export-clixml does output data to a file.

    Why would export-clixml not be expecting/have data to write to file?  I was not expecting that my export-clixml pass any data to the stop-service command.  I apologize, I'm new.

    04 Maret 2012 4:54
  • I was not aware that I was attempting to pass any parameter data to get-service.  That must be my mistake.  I thought the function (?) get-service would query running services, and not be passed parameters by the stack (?).

    That reading your post and learning that get-service is expecting that its parameters are passed to it (unknown by me - thought that commands to get-service were passed by switches/parameters) makes perfect sense.  Are you certain that this is true?  I'm just asking for understanding.

    04 Maret 2012 4:57
  • I've not gotten through enough of the book to understand the ';' parse - it delimits commands without preserving stack (?) data to that command?
    04 Maret 2012 4:59
  • Used outside of the pipeline, get-service without any arguments will get all of the services.

    When you put the pipe between stop-service and get-service, you were implicitly telling get-service to expect the names of services to get from stop-service.

    [PS] C:\>"alg" | get-service
    Status   Name               DisplayName
    ------   ----               -----------
    Stopped  alg                Application Layer Gateway Service

    stop-service did not give it any thing to look up.

    Trade that pipe for a ; and then get-service won't expect to be getting arguments from the pipeline and will get all the services.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    04 Maret 2012 5:11
  • Used outside of the pipeline, get-service without any arguments will get all of the services.

    When you put the pipe between stop-service and get-service, you were implicitly telling get-service to expect the names of services to get from stop-service.

    [PS] C:\>"alg" | get-service
    Status   Name               DisplayName
    ------   ----               -----------
    Stopped  alg                Application Layer Gateway Service

    stop-service did not give it any thing to look up.

    Trade that pipe for a ; and then get-service won't expect to be getting arguments from the pipeline and will get all the services.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Now I'm understanding - I did not know that get-service would expect data, now that I know that get-service will interpret what is in the pipeline as a parameter, it's no wonder, knowing that, it would not pass anything to the export-clixml command.

    Thank you for that.

    How long does the 'stack' (lack of a better term -?) in the pipeline last?  Is it discarded after a command that can use pipelined data then uses that data?

    04 Maret 2012 5:20
  • Not sure how to answer that last question.  The "stack" lasts as long as there is data for it to process.  When you get your results, its discarded.

     One minor point.  It is not quit correct to say that it is interpreting what is in the pipeline as a parameter. It is interpreting what is in the pipeline as an argument to a parameter.  You can use get-help -full on a cmdlet to see what parameters will accept their arguments from the pipeline and which ones must be provided in the argument list.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    04 Maret 2012 5:37
  • the semicolon is simply a character that flags the end of a statement. It has no effect whatsoever on the following statement on the same line, other than to indicated that it is not simply part of the previous statement.

    Another way to look at it is that it is functionally identical to the newline character. If there is any relationship between the commands separated by either "command delimiter" it is simply that the first one completes before the second one starts.

    These three snippets therefore have behaviours that are completely indistinguishable from each other:


        md ./newfold ; rd ./newfold


        md ./newfold
        rd ./newfold


        md ./newfold;
        rd ./newfold;


    Al Dunbar

    04 Maret 2012 21:34
  • One thing about the semicolon that confused me at first is that, as commands entered at the command
    prompt, the following are not equivalent:
     
    1) the one-liner containing two commands
    gps powershell; gcm powershell;
     
    2) those two commands entered as two lines
    gps powershell;
    gcm powershell;
     
    The one-liner's output formatting is not what I expected.
     
    For some reason, the formatter is called only once in the one-liner case and it confuses the
    formatter to have more than one type of object at a time to format.
      - Larry
     >
     >
     
    On 3/4/2012 3:34 PM, Al Dunbar wrote:
    > the semicolon is simply a character that flags the end of a statement. It has no effect whatsoever
    > on the following statement on the same line, other than to indicated that it is not simply part of
    > the previous statement.
    >
    > Another way to look at it is that it is functionally identical to the newline character. If there
    > is any relationship between the commands separated by either "command delimiter" it is simply that
    > the first one completes before the second one starts.
    > ...
     >
     
    05 Maret 2012 0:04