misunderstanding of how to encode enums
new-object System.IO.FileStream "c:\wut.txt", [System.IO.FileMode]::Open
yields
New-Object : Cannot convert argument "1", with value: "[System.IO.FileMode]::Open", for ".ctor" to type "System.IO.FileMode": "Cannot convert value "[System.IO.FileMode]::Open" to type "System.IO.FileMode" due to invalid enumeration values. Specify one of the following enumeration values and try again. The possible enumeration values are "CreateNew, Create, Open, OpenOrCreate, Truncate, Append"."
At line:1 char:11
+ new-object <<<< System.IO.FileStream "c:\wut.txt", [System.IO.FileMode]::Open
This works — why no error on the bad enum (
Sytem instead of
System)?
$sr = new-object System.IO.StreamReader $fs, [Sytem.Text.Encoding]::UTF32
parentheses are required:
$sr = new-object System.IO.StreamReader $fs, ([System.Text.Encoding]::Default)
short questions
- can we have an
Explain-Tokenization cmdlet?
- How can I let the second argument be a script block or int, easily, in Execute-Every? Ideally, the first int/string is the delay between executions/piped outputs, the second int (if any) is the number of iterations, and the first script block (if any) is the lambda. How do I do this? In effect, I want positional arguments that can also be specifically named.
blog questions
For tracking them until I build myself a little website monitor...
Have you thought of making a PowerShell suggestions wiki and hire an intern to admin it? It strikes me that you could make the suggestions come to you, but perhaps you have tried this? I'd even be willing to give it a shot on my
kind-of-wiki. Or maybe I should just put out enough PS info to become an MVP, then become known as the guy who organizes suggetions, etc. Hmmm...
Grep is such a powerful and oft-used tool that I should think excellent support in v1 would be at the top of people's list. I guess the focus was just on management more than processing text, but please note that processing text will be VERY IMPORTANT until everything is PS. Until then, please give us a nice transition story. I'll echo
--only-matches,
--max-count,
--no-filename,
--count, and
--invert-match. Most of the features of grep are useful and I don't think supporting them would cost much in terms of benefit.
As an aside, is there discussion somewhere of the poor performance when, say, tailing the last million lines of a file and piping it to grep? I've resorted to
cmd /c "tail ... | grep ...", but that's kludgy, due to nesting of escapes and all that fun. I tried a
hack with lambdas, but it has two problems: it doesn't do string interpolation and some unknown problem I have yet to fully characterize. Do you guys have any story for this?
[Not in the comment:
here are some performance numbers]
I will have to say, it was disappointing that you released such a great v1 with a host window that is no better than cmd.exe:
- width is not resizable except via annoying dialog
- copying an invocation that goes onto multiple lines is tedious, because you can only block-copy
- no clipboard cmdlets (the PS community extensions have them, but this is kind of core functionality, I would think)
- no Unicode support in the shell window
I get that PS can be hosted in different places, but I still think it would have behooved you to include a host at least slightly better than the cmd.exe shell. Could you provide some enlightenment here? Would it really have required that much developer time to do this? (Compared to the impact upon the community.)
I know you have the ISE for v2 and I hope it kicks ass so that I and others can forget the host for v1.
@luke - I hear you.
I think you'll like the V2 ISE (you should get it soon). That said, I think that 3rd parties are going to be the best providers of hosts for the forseeable future. If you haven't checked them out you should - they are wonderful!
jps
It would be nice if Get-Help were to specifically list enum values. Or is there a way to reflect upon a cmdlet and find the types of its parameters, and then use the static method on System.Enum to pull the values? I would rather not have to inject strings into Get-Help contents, but you PowerShell folks haven't seem to have thought of this (or if you have, it is not clear to the public).