Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Powershell bug, MS refuses to fix.

140 views
Skip to first unread message

James Gentile

unread,
Sep 19, 2009, 5:25:26 PM9/19/09
to
This code does not work in a script, but it works at the command line:

$d = dir
$d
cls
while($true)
{
cls
$d | ft -a
sleep 1
}

The error is:
out-lineoutput : The object of type
"Microsoft.PowerShell.Commands.Internal.Format.FormatStartData" is not valid
or not
in the correct sequence. This is likely caused by a user-specified
"format-table" command which is conflicting with th
e default formatting.
+ CategoryInfo : InvalidData: (:) [out-lineoutput],
InvalidOperationException
+ FullyQualifiedErrorId :
ConsoleLineOutputOutOfSequencePacket,Microsoft.PowerShell.Commands.OutLineOutputCommand

I've filed this bug on the connect site, MS closed it with "resolved (won't
fix)" - so I refiled the bug, and attempted to point out how severe it is,
the topic got deleted from connect.
Why the hell won't MS fix this, is this by design? I asked about this bug a
long time ago and someone gave a description of what was happening,
unfortunately I can't find it anymore. So does anyone else think this is a
big deal besides me? Is there a work-around?

Bob Landau

unread,
Sep 20, 2009, 12:44:01 PM9/20/09
to
If this is the first bug that they've refused to fix consider yourself lucky.

1) Many bugs in a customers eyes aren't
2) Bugs take time and money to fix so must be prioritized by

Severaity
Likelihood that customers will encounter it
While this benefit other internal and external customers
Likelihood that this fix will break _anyones_ code
etc

3) Not all bugs will be fixed several ones I sent up came back as "will not
fix" . Doesn't mean they don't appreciate that they're more important bugs to
fix and oh yes version 3.

In general when one writes up a bug report it should be clear, simple as
possible, state any step or perquisites, expected results, observered
results, build #, and so on.


What you've presented is overly complex; there's no reason that you need to
use a variable for DIR. Nor does resemble a situation many of us are likely
to encounter.

What this looks like to me is you took one of your scripts and pasted into
the bug report rather than try to clean up any irrelevent stuff.

Here is a simpler example which I suspect may have more of a change getting
fixed.

bug#XXX.ps1
gci
gci | ft
## end of script.

Expectations: bug#XXX should work similary as it does at the command line
which is to print out the current directory twice.

Observation: Second line returned this error


out-lineoutput : The object of type
"Microsoft.PowerShell.Commands.Internal.Format.FormatStartData" is not valid
or not
in the correct sequence. This is likely caused by a user-specified
"format-table" command which is conflicting with th
e default formatting.
+ CategoryInfo : InvalidData: (:) [out-lineoutput],
InvalidOperationException
+ FullyQualifiedErrorId :
ConsoleLineOutputOutOfSequencePacket,Microsoft.PowerShell.Commands.OutLineOutputCommand


Consider your bug report like a resume which in terms of number of bugs vs
resumes MS gets; I suspect is actually a valid comparison. You have 10
seconds to hold they're attention and you likely lost it prior to that.

The script doesn't look like one many of us would encounter

bob

Larry__Weiss

unread,
Sep 21, 2009, 10:38:23 AM9/21/09
to

I experimented with this and can describe it without respect to scripting.

At the command line, contrast the output of

PS C:> gci
PS C:> gci | ft
to
PS C:> gci; gci | ft

cgi can be replaced by ps or gcm with similar results.

PS C:> ps; ps | ft
PS C:> gcm; gcm | ft

- Larry

James Gentile

unread,
Sep 21, 2009, 11:31:14 AM9/21/09
to
Yes, I understand all that. But I'm not a powershell expert, and since the
bug doesn't make sense to me, I wasn't sure how to best present it or
reproduce it in the best way, the script I gave seemed obvious. Although
the exact script has no use, it should demostrate how severe it is because
there are a number of situations where you would do something similar. So
what about the bug itself, this seems pretty broken. Should I refile again?

Larry__Weiss

unread,
Sep 21, 2009, 11:53:34 AM9/21/09
to

Since this one seems so easy to discover, I would first try to see how many
times it has already been disclosed in the database of issues before adding it
yet again.

- Larry

tojo2000

unread,
Sep 21, 2009, 6:10:07 PM9/21/09
to

About the closest to an official answer I've found is here (from Don
Jones himself): http://www.minasi.com/forum/topic.asp?TOPIC_ID=20456#103477

Larry__Weiss

unread,
Sep 21, 2009, 6:42:02 PM9/21/09
to
tojo2000 wrote:
> About the closest to an official answer I've found is here (from Don
> Jones himself): http://www.minasi.com/forum/topic.asp?TOPIC_ID=20456#103477

So, we have to be mindful that each command line of commands creates a pipeline
of output objects just like a script does, and if some are going to be formatted
explicitly then we have to format each one explicitly and not mix implicit and
explicit formating?

Like

PS C:> gci | ft; gci | ft

not

PS C:> gci; gci | ft

- Larry

Larry__Weiss

unread,
Sep 21, 2009, 6:59:47 PM9/21/09
to

The following version of your script will not throw errors:

$d = dir
$d | ft -a # <-- this line is changed


cls
while($true)
{
cls
$d | ft -a
sleep 1
}

See other discussion on this topic for the reason why.

- Larry

0 new messages