Hi,
We had this issue since PowerShell v1. The < character is always reserved for future use, but that future never arrives.
< and > are using by many command line utilities, such as mysql and mysqldump for example. But can never use it with powershell.
Have you try using the stop-parsing symbol --%?
mysql.exe --% < backup.sql
Gives me the error: Couldn't find table: ">"
@ThomasNieto the issue here isn't that PowerShell is swallowing <, it's that PowerShell doesn't support input redirection (setting the stdin of a native command to be from a file), so the stop parsing symbol won't help.
Given the token has been labeled as reserved for several versions, I'd be inclined to assume that if someone wanted to implement the feature it would probably be largely welcomed.
It's probably just a matter of priorities and having the time to implement it; the number of binaries that _require_ that form of input aren't huge, at least on Windows, and many of them can work with the output provided with a more standard input pipe, though that requires manually pulling the content from the relevant file manually if you want to pass file contents in...
The broader question would simply be what is the expected behaviour if you use < on a cmdlet, pipeline, or expression. Sensible behaviour for a first implementation might just be to throw an error in those cases, and only allow it to be used when invoking native commands.
The broader question would simply be what is the expected behaviour if you use
<on a cmdlet, pipeline, or expression. Sensible behaviour for a first implementation might just be to throw an error in those cases, and only allow it to be used when invoking native commands.
IMO the intuitive behavior there would be that cmdlet < file would be semantically equivalent to Get-Content file | cmdlet. I don't think it would make sense for an expression, or in the middle of a pipeline.
So, what I am hearing (or reading), is that MySQL tools are the issue here and not powershell. I mean there is a workaround to wrap the commands with cmd /c "...", but its sad that it has to be done that way :(
@lebartha no the issue really is ultimately PowerShell, in that it doesn't support input redirection.
Most helpful comment
@lebartha no the issue really is ultimately PowerShell, in that it doesn't support input redirection.