MemoryStream trouble on Mono

[JonSargent]

Terrific library.

Potentially obscure question... I was just testing input redirection similar to this example:
var cmd = Command.Run("path_to_grep", "some REGEX") < new FileInfo("some path") > lines;
but from a memory stream.

On Windows, when the executable I'm running fails, it fails beautifully -- the expected exit code is returned, and stderr gets stored in cmd.StandardError.

However, on Ubuntu using mono, I get a FileStream.Write exception instead. Any idea what might be causing this, and whether there's a workaround?

Thanks! Exception details below.

Jon

System.IO.IOException: Write fault on path /opt/myfolder/[Unknown]
at System.IO.FileStream.WriteInternal (System.Byte[] src, Int32 offset, Int32 count) [0x00000] in :0
at System.IO.FileStream.Write (System.Byte[] array, Int32 offset, Int32 count) [0x00000] in :0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in :0
at Medallion.Shell.Streams.ProcessStreamWriter+<>c__DisplayClass2+<b__0>d__4.MoveNext () [0x00000] in :0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in :0
at Medallion.Shell.Streams.PipeHelpers+d__a.MoveNext () [0x00000] in :0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00000] in :0
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in :0
at Medallion.Shell.IoCommand+d__0.MoveNext () [0x00000] in :0
Void ThrowIfExceptional(Boolean)

[madelson]

Hi @JonSargent, thanks for reporting this.

I haven't tested on Mono so I haven't encountered this issue.

Can you post a complete program which reproduces the error including any setup notes for external executables/files? Also, do you know whether this is reproducible when running Mono on Windows? I ask because I don't currently have a Linux environment readily available for testing.

[madelson]

@JonSargent having researched this a bit it seems like this might be Mono's behavior for writing to Standard Input after the process exits. See http://stackoverflow.com/questions/15399234/cant-write-input-to-process-c-sharp-mono.

[JonSargent]

Hi @madelson, thanks for the responses. And apologies for not getting back to you sooner. I suspected a somewhat indelible issue, and it wasn't too hard for me to avoid using stdin, so I did. :)

Your hypothesis sounds plausible, though.

[madelson]

@JonSargent I realize this is long past where you originally hit this, but I finally had time to install Mono and reproduce the issue. I believe it should be fixed in the 1.4 release of the package (basically using a hack to swallow these errors on Mono specifically).