Open naturallymitchell opened 5 years ago
Stdio::null() is used to ignore any io sent to a child process created by Command
. This doesnt really allow direct usage to /dev/null. You would want to open /dev/null or just have a handler to open it directly and use that for whatever is being nullified/ignored/etc.
I did reread what is said in that issue and I do believe that he is not referring to using /dev/null
directly but to just replace the file if it doesnt exist with /dev/null
(which is more dependent on unix-like systems) so I am going to close this for the time being.
Yes, the whole point is to specify a non-existent file. /dev/null
suits well, as Windows OSes doesn't have similar file. Also, IIRC, git does it exactly this way.
It is possible to specify an empty file some other way, but this may break original patch/diff support.
This is probably related to https://github.com/foundpatterns/diff-rs/issues/6
/dev/null suits well, as Windows OSes doesn't have similar file
https://superuser.com/questions/134214/is-there-an-equivalent-to-dev-null-in-windows
but regardless, Cmder is basically "Linux"
(which is more dependent on unix-like systems)
that's everything afaict. win and droid aren't on any major departure, given Cmder and Termux
You would want to open /dev/null or just have a handler to open it directly and use that for whatever is being nullified/ignored/etc.
Yes, the whole point is to specify a non-existent file.
this makes a lot of sense..
I think it should go in sys/null or something rather than fs
I think it should go in sys/null or something rather than fs
This will be much cleaner, than using something like /dev/null
.
But filenames in diff must be actual filenames or the original patch
program might not work.
But it's clear we don't need the bindings for null device. It can be handled within diff bindings interface: ability to specify non-existent file and its proper handling.
k. renamed
https://doc.rust-lang.org/std/process/struct.Stdio.html#method.null
from https://github.com/foundpatterns/torchbear/issues/174
//cc @sineemore