$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?
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
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
- Larry
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
$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